From brad.king at kitware.com Wed Apr 1 09:31:39 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 01 Apr 2015 09:31:39 -0400 Subject: [vtk-developers] Merging a topic In-Reply-To: <20150331224228.GA26695@megas.kitwarein.com> References: <20150331224228.GA26695@megas.kitwarein.com> Message-ID: <551BF33B.3080204@kitware.com> On 03/31/2015 06:42 PM, Ben Boeckel wrote: > Sorry for this, the GitLab docs[2] missed that 'reopened' is a valid > state for merge requests, so it is ignored because it isn't 'opened'. > The robot will be restarted in the morning when Brad gets in; a comment > should get kwrobot to look at the MR and merge it. The fix to support 'reopened' has been deployed. You should be able to "Do: merge" now. -Brad From A.Buykx at tnodiana.com Wed Apr 1 09:51:24 2015 From: A.Buykx at tnodiana.com (Andreas Buykx) Date: Wed, 1 Apr 2015 13:51:24 +0000 Subject: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter Message-ID: <65D987BE62E58141AA480A59A8B5BBEA6DEAF624@srv-mail.diana.local> Hi, To detect if coinciding faces of neighbouring 3D cells are connected, vtkUnstructuredGridGeometryFilter walks the points of these faces in opposite directions and expects the point ids to match. This fails for vtkWedge attached to e.g. vtkTetra and vtkHexahedron as demonstrated by the python script I attach. The root cause is that the vtkWedge::GetFaceArray and vtkWedge::GetFace return the face points in an ordering that makes the face normal point into the 3D cell instead of out of the 3D cell, like all other 3D cells do. The two other algorithms that generate surface cells (vtkDataSetSurfaceFilter and vtkGeometryFilter) don't suffer from this ordering because the former checks point ordering but explicitly allows both loop directions, and the latter only takes cell connectivity into account without checking point-ordering at all. I don't know what the reason is to have a different face-point ordering for the vtkWedge, but one of the other consequences is that the outer surface will have inconsistent cell normals as can easily be seen when loading the xml files produced by the tests in paraview, and showing the cell normals. So I would prefer to change the face-point ordering in vtkWedge. If that is not possible for some reason then I propose to make/update the case-blocks in the surface filters cell-type switches to re-order the face-points for the wedge faces. As long as this is not dealt with our FEA models will show edges where they should not be so I will have to solve this issue one way or another, and I'd like to contribute it to VTK as well. Shall I make a mantis issue for this? Who can help me with the git/gerrit stuff? Thanks a lot, Andreas Buykx ____________________________________________________________ TNO DIANA BV is a limited liability company registered in the trade register of the Chamber of Commerce as TNO DIANA BV with registered number 27252655. ____________________________________________________________ This e-mail and its contents are subject to the DISCLAIMER at http://tnodiana.com/content/Disclaimer ____________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wedge_test.py Type: application/octet-stream Size: 5422 bytes Desc: wedge_test.py URL: From david.gobbi at gmail.com Wed Apr 1 11:35:06 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 1 Apr 2015 09:35:06 -0600 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: I thought of a simpler solution for the vtkBoundingBox issue. The discussion we've had so far has focused on getting vtkWrapTcl to deal with the vtkBoundingBox type. But that can be avoided if we instead just focus on the ComputeBoundingBox method. Here's how it would work: In vtkWrapTcl, it's pretty easy to see how the AddObserver method was added for vtkObject. Just search for "AddObserver" and it comes up in exactly two places. Likewise, the code for ComputeBoundingBox could be added for vtkAbstractMapper3D. Adding it to this base class will automatically make it available in all the wrapped subclasses. - David On Tue, Mar 31, 2015 at 5:54 AM, David Lonie wrote: > On Mon, Mar 30, 2015 at 10:31 AM, Jorge Perez > wrote: > >> I'm experimenting with this idea: implement new Tcl_ObjType to wrap >> vtkVariant and vtkBoundingBox. >> > > This would be great! I'll keep pushing forward on my vtkBoundingBox --> > double[6] implementation since I need something very soon, but this > solution sounds better. Looking forward to it. > > Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Wed Apr 1 11:37:26 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 1 Apr 2015 11:37:26 -0400 Subject: [vtk-developers] Workflow suggestion #1 In-Reply-To: References: Message-ID: Sounds good to me. -berk On Tue, Mar 31, 2015 at 6:16 PM, Bill Lorensen wrote: > I suggest that the title and description for a topic be the commit > message and the commit description respectively. > > Otherwise, the commit message is at least another click away. > > Bill > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From ben.boeckel at kitware.com Wed Apr 1 11:38:08 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 1 Apr 2015 11:38:08 -0400 Subject: [vtk-developers] Workflow suggestion #1 In-Reply-To: References: <20150331224715.GB26695@megas.kitwarein.com> Message-ID: <20150401153808.GA4725@megas.kitwarein.com> On Tue, Mar 31, 2015 at 15:58:53 -0700, Bill Lorensen wrote: > I'm suggesting that we recommend this. Not automating it. Ah, I'm all for that. --Ben From berk.geveci at kitware.com Wed Apr 1 11:42:14 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 1 Apr 2015 11:42:14 -0400 Subject: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter In-Reply-To: <65D987BE62E58141AA480A59A8B5BBEA6DEAF624@srv-mail.diana.local> References: <65D987BE62E58141AA480A59A8B5BBEA6DEAF624@srv-mail.diana.local> Message-ID: Hi Andreas, Changing the ordering of vtkWedge would be a very large undertaking given that there is years of documentation, file formats (in VTK and 3rd party), code etc. that depend on a certain ordering. One less intrusive way would be to change any vtkWedge methods that returns faces to return them in a different order. I suspect this option is doable but I'd like to hear from the community. The least intrusive options is to fix the few filters that have this issue but I feel like it is a band-aid. Best, -berk On Wed, Apr 1, 2015 at 9:51 AM, Andreas Buykx wrote: > Hi, > > > > To detect if coinciding faces of neighbouring 3D cells are connected, > vtkUnstructuredGridGeometryFilter walks the points of these faces in > opposite directions and expects the point ids to match. This fails for > vtkWedge attached to e.g. vtkTetra and vtkHexahedron as demonstrated by the > python script I attach. The root cause is that the vtkWedge::GetFaceArray > and vtkWedge::GetFace return the face points in an ordering that makes the > face normal point into the 3D cell instead of out of the 3D cell, like all > other 3D cells do. The two other algorithms that generate surface cells > (vtkDataSetSurfaceFilter and vtkGeometryFilter) don?t suffer from this > ordering because the former checks point ordering but explicitly allows both > loop directions, and the latter only takes cell connectivity into account > without checking point-ordering at all. > > > > I don?t know what the reason is to have a different face-point ordering for > the vtkWedge, but one of the other consequences is that the outer surface > will have inconsistent cell normals as can easily be seen when loading the > xml files produced by the tests in paraview, and showing the cell normals. > So I would prefer to change the face-point ordering in vtkWedge. If that is > not possible for some reason then I propose to make/update the case-blocks > in the surface filters cell-type switches to re-order the face-points for > the wedge faces. As long as this is not dealt with our FEA models will show > edges where they should not be so I will have to solve this issue one way or > another, and I?d like to contribute it to VTK as well. > > > > Shall I make a mantis issue for this? Who can help me with the git/gerrit > stuff? > > > > Thanks a lot, > > Andreas Buykx > > ____________________________________________________________ > TNO DIANA BV is a limited liability company registered in the trade register > of the Chamber of Commerce as TNO DIANA BV with registered number 27252655. > ____________________________________________________________ > This e-mail and its contents are subject to the DISCLAIMER at > http://tnodiana.com/content/Disclaimer > ____________________________________________________________ > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 berk.geveci at kitware.com Wed Apr 1 11:42:51 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 1 Apr 2015 11:42:51 -0400 Subject: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter In-Reply-To: References: <65D987BE62E58141AA480A59A8B5BBEA6DEAF624@srv-mail.diana.local> Message-ID: Oh I forgot to mention that I am happy to work with you on code reviews etc. We now use Gitlab not Gerrit btw. Utkarsh sent out some messages about this. Best, -berk On Wed, Apr 1, 2015 at 11:42 AM, Berk Geveci wrote: > Hi Andreas, > > Changing the ordering of vtkWedge would be a very large undertaking > given that there is years of documentation, file formats (in VTK and > 3rd party), code etc. that depend on a certain ordering. One less > intrusive way would be to change any vtkWedge methods that returns > faces to return them in a different order. I suspect this option is > doable but I'd like to hear from the community. The least intrusive > options is to fix the few filters that have this issue but I feel like > it is a band-aid. > > Best, > -berk > > On Wed, Apr 1, 2015 at 9:51 AM, Andreas Buykx wrote: >> Hi, >> >> >> >> To detect if coinciding faces of neighbouring 3D cells are connected, >> vtkUnstructuredGridGeometryFilter walks the points of these faces in >> opposite directions and expects the point ids to match. This fails for >> vtkWedge attached to e.g. vtkTetra and vtkHexahedron as demonstrated by the >> python script I attach. The root cause is that the vtkWedge::GetFaceArray >> and vtkWedge::GetFace return the face points in an ordering that makes the >> face normal point into the 3D cell instead of out of the 3D cell, like all >> other 3D cells do. The two other algorithms that generate surface cells >> (vtkDataSetSurfaceFilter and vtkGeometryFilter) don?t suffer from this >> ordering because the former checks point ordering but explicitly allows both >> loop directions, and the latter only takes cell connectivity into account >> without checking point-ordering at all. >> >> >> >> I don?t know what the reason is to have a different face-point ordering for >> the vtkWedge, but one of the other consequences is that the outer surface >> will have inconsistent cell normals as can easily be seen when loading the >> xml files produced by the tests in paraview, and showing the cell normals. >> So I would prefer to change the face-point ordering in vtkWedge. If that is >> not possible for some reason then I propose to make/update the case-blocks >> in the surface filters cell-type switches to re-order the face-points for >> the wedge faces. As long as this is not dealt with our FEA models will show >> edges where they should not be so I will have to solve this issue one way or >> another, and I?d like to contribute it to VTK as well. >> >> >> >> Shall I make a mantis issue for this? Who can help me with the git/gerrit >> stuff? >> >> >> >> Thanks a lot, >> >> Andreas Buykx >> >> ____________________________________________________________ >> TNO DIANA BV is a limited liability company registered in the trade register >> of the Chamber of Commerce as TNO DIANA BV with registered number 27252655. >> ____________________________________________________________ >> This e-mail and its contents are subject to the DISCLAIMER at >> http://tnodiana.com/content/Disclaimer >> ____________________________________________________________ >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the 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 david.lonie at kitware.com Wed Apr 1 11:46:07 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 1 Apr 2015 11:46:07 -0400 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: On Wed, Apr 1, 2015 at 11:35 AM, David Gobbi wrote: > I thought of a simpler solution for the vtkBoundingBox issue. The > discussion we've had so far has focused on getting vtkWrapTcl to deal with > the vtkBoundingBox type. But that can be avoided if we instead just focus > on the ComputeBoundingBox method. Here's how it would work: > > In vtkWrapTcl, it's pretty easy to see how the AddObserver method was > added for vtkObject. Just search for "AddObserver" and it comes up in > exactly two places. Likewise, the code for ComputeBoundingBox could be > added for vtkAbstractMapper3D. Adding it to this base class will > automatically make it available in all the wrapped subclasses. > Thanks for the suggestion, but it was actually fairly easy to just add support for any method returning vtkBoundingBox: https://gitlab.kitware.com/dlonie/vtk/commit/bdd4c1e1a3f357338334b6cb83fb3c5076e8c001?force_show_diff=true#diff-200 The wrapping code turned out to be much easier to work with than I thought it would! Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Apr 1 11:58:21 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 1 Apr 2015 09:58:21 -0600 Subject: [vtk-developers] Tcl wrapping and output array arguments In-Reply-To: References: Message-ID: Aha, I didn't see that. And Java too. Nice! On Wed, Apr 1, 2015 at 9:46 AM, David Lonie wrote: > On Wed, Apr 1, 2015 at 11:35 AM, David Gobbi > wrote: > >> I thought of a simpler solution for the vtkBoundingBox issue. The >> discussion we've had so far has focused on getting vtkWrapTcl to deal with >> the vtkBoundingBox type. But that can be avoided if we instead just focus >> on the ComputeBoundingBox method. Here's how it would work: >> >> In vtkWrapTcl, it's pretty easy to see how the AddObserver method was >> added for vtkObject. Just search for "AddObserver" and it comes up in >> exactly two places. Likewise, the code for ComputeBoundingBox could be >> added for vtkAbstractMapper3D. Adding it to this base class will >> automatically make it available in all the wrapped subclasses. >> > > Thanks for the suggestion, but it was actually fairly easy to just add > support for any method returning vtkBoundingBox: > > > https://gitlab.kitware.com/dlonie/vtk/commit/bdd4c1e1a3f357338334b6cb83fb3c5076e8c001?force_show_diff=true#diff-200 > > The wrapping code turned out to be much easier to work with than I thought > it would! > > Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Wed Apr 1 12:50:53 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 1 Apr 2015 12:50:53 -0400 Subject: [vtk-developers] vtkResliceCursorWidget tests Message-ID: Is anyone familiar with these tests? vtkInteractionWidgetsCxx-TestResliceCursorWidget2 vtkInteractionWidgetsCxx-TestResliceCursorWidget3 They're both failing on my GetBounds refactoring branch, and the more I look, the more it seems like the current baselines are invalid. Here are the failures: https://open.cdash.org/testDetails.php?test=323957914&build=3752775 https://open.cdash.org/testDetails.php?test=323957866&build=3752775 The valid images just show the background with no data for 3 of the renderers, while the "invalid" images show data and the cursor crosshairs. Digging way, way back into the old VTKData repository turns up a third version -- one with data and crosshairs, but the crosshairs are style differently (attached). I suspect this broke at some point and the bounds refactoring fixed something along the way. Any insights? Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TestResliceCursorWidget2.png Type: image/png Size: 51243 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: TestResliceCursorWidget3.png Type: image/png Size: 54126 bytes Desc: not available URL: From ken.martin at kitware.com Wed Apr 1 13:28:04 2015 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 1 Apr 2015 13:28:04 -0400 Subject: [vtk-developers] Java Build failures Message-ID: <6878fd59b698ef0173d6b6afd8bda9a0@mail.gmail.com> A few systems are failing their builds with some sort of Java error. Is someone looking into these? Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From shawn.waldon at kitware.com Wed Apr 1 13:30:32 2015 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Wed, 1 Apr 2015 13:30:32 -0400 Subject: [vtk-developers] Java Build failures In-Reply-To: <6878fd59b698ef0173d6b6afd8bda9a0@mail.gmail.com> References: <6878fd59b698ef0173d6b6afd8bda9a0@mail.gmail.com> Message-ID: This should be fixed for branches based on the current master. The branch 'add-missing-java-files' that was merged this morning fixes it. Shawn On Wed, Apr 1, 2015 at 1:28 PM, Ken Martin wrote: > A few systems are failing their builds with some sort of Java error. Is > someone looking into these? > > > > Thanks > > Ken > > > > Ken Martin PhD > > Chairman & CFO > > Kitware Inc. > > 28 Corporate Drive > > Clifton Park NY 12065 > > ken.martin at kitware.com > > 518 881-4901 (w) > > 518 371-4573 (f) > > > > This communication, including all attachments, contains confidential and > legally privileged information, and it is intended only for the use of the > addressee. Access to this email by anyone else is unauthorized. If you are > not the intended recipient, any disclosure, copying, distribution or any > action taken in reliance on it is prohibited and may be unlawful. If you > received this communication in error please notify us immediately and > destroy the original message. Thank you. > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Wed Apr 1 13:32:04 2015 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 1 Apr 2015 13:32:04 -0400 Subject: [vtk-developers] Java Build failures In-Reply-To: References: <6878fd59b698ef0173d6b6afd8bda9a0@mail.gmail.com> Message-ID: Awesome! Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) 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:* Wednesday, April 1, 2015 1:31 PM *To:* Ken Martin *Cc:* VTK Developers *Subject:* Re: [vtk-developers] Java Build failures This should be fixed for branches based on the current master. The branch 'add-missing-java-files' that was merged this morning fixes it. Shawn On Wed, Apr 1, 2015 at 1:28 PM, Ken Martin wrote: A few systems are failing their builds with some sort of Java error. Is someone looking into these? Thanks Ken Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) This communication, including all attachments, contains confidential and legally privileged information, and it is intended only for the use of the addressee. Access to this email by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, distribution or any action taken in reliance on it is prohibited and may be unlawful. If you received this communication in error please notify us immediately and destroy the original message. Thank you. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -------------- next part -------------- An HTML attachment was scrubbed... URL: From jcplatt at dsl.pipex.com Wed Apr 1 16:09:57 2015 From: jcplatt at dsl.pipex.com (John Platt) Date: Wed, 01 Apr 2015 21:09:57 +0100 Subject: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter In-Reply-To: References: <65D987BE62E58141AA480A59A8B5BBEA6DEAF624@srv-mail.diana.local> Message-ID: <551C5095.7050700@dsl.pipex.com> Hi, I think this is also a problem for vtkDataSetSurfaceFilter when mixing quadratic hex's & wedges. If the actor opacity is reduced, the internal faces between the hex's & wedges are visible. This can be fixed by turning the wedge inside-out i.e. swapping points 1 & 2 and 4 & 5. The FE system I work with allows both right and left handed elements so the topology of each element must be checked and inverted if necessary. I agree that the order of the nodes in the face arrays should be changed to be consistent with the other cells. I suspect this would largely go unnoticed given the time this inconsistency has been present and the number of reports on the behaviour. Thanks, John. On 01/04/2015 16:42, Berk Geveci wrote: > Hi Andreas, > > Changing the ordering of vtkWedge would be a very large undertaking > given that there is years of documentation, file formats (in VTK and > 3rd party), code etc. that depend on a certain ordering. One less > intrusive way would be to change any vtkWedge methods that returns > faces to return them in a different order. I suspect this option is > doable but I'd like to hear from the community. The least intrusive > options is to fix the few filters that have this issue but I feel like > it is a band-aid. > > Best, > -berk > > On Wed, Apr 1, 2015 at 9:51 AM, Andreas Buykx wrote: >> Hi, >> >> >> >> To detect if coinciding faces of neighbouring 3D cells are connected, >> vtkUnstructuredGridGeometryFilter walks the points of these faces in >> opposite directions and expects the point ids to match. This fails for >> vtkWedge attached to e.g. vtkTetra and vtkHexahedron as demonstrated by the >> python script I attach. The root cause is that the vtkWedge::GetFaceArray >> and vtkWedge::GetFace return the face points in an ordering that makes the >> face normal point into the 3D cell instead of out of the 3D cell, like all >> other 3D cells do. The two other algorithms that generate surface cells >> (vtkDataSetSurfaceFilter and vtkGeometryFilter) don?t suffer from this >> ordering because the former checks point ordering but explicitly allows both >> loop directions, and the latter only takes cell connectivity into account >> without checking point-ordering at all. >> >> >> >> I don?t know what the reason is to have a different face-point ordering for >> the vtkWedge, but one of the other consequences is that the outer surface >> will have inconsistent cell normals as can easily be seen when loading the >> xml files produced by the tests in paraview, and showing the cell normals. >> So I would prefer to change the face-point ordering in vtkWedge. If that is >> not possible for some reason then I propose to make/update the case-blocks >> in the surface filters cell-type switches to re-order the face-points for >> the wedge faces. As long as this is not dealt with our FEA models will show >> edges where they should not be so I will have to solve this issue one way or >> another, and I?d like to contribute it to VTK as well. >> >> >> >> Shall I make a mantis issue for this? Who can help me with the git/gerrit >> stuff? >> >> >> >> Thanks a lot, >> >> Andreas Buykx >> >> ____________________________________________________________ >> TNO DIANA BV is a limited liability company registered in the trade register >> of the Chamber of Commerce as TNO DIANA BV with registered number 27252655. >> ____________________________________________________________ >> This e-mail and its contents are subject to the DISCLAIMER at >> http://tnodiana.com/content/Disclaimer >> ____________________________________________________________ >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From dan.lipsa at kitware.com Thu Apr 2 10:54:16 2015 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Thu, 2 Apr 2015 10:54:16 -0400 Subject: [vtk-developers] Ghost and Blanking (Visibility) Changes Message-ID: Dear VTK and ParaView developers, We would like to draw your attention to the following updates to VTK/ParaView that change the way one interfaces to Ghost and Blanking cells and points. These changes have just been merged into master repositories for VTK/ParaView. http://www.kitware.com/blog/home/post/856 We welcome suggestions and/or bug reports on these changes. Best regards, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Thu Apr 2 15:37:40 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 2 Apr 2015 12:37:40 -0700 Subject: [vtk-developers] ANN: New RenderMan support Message-ID: Folks, The vtkRIBExporter has been updated to work with the recently released, free for non-commercial use RenderMan. https://renderman.pixar.com/view/renderman There is an example here: http://www.vtk.org/Wiki/VTK/Examples/Cxx/RenderMan/PolyDataRIB and sample results here: http://www.vtk.org/Wiki/images/1/14/VTK_Examples_RenderMan1.png http://www.vtk.org/Wiki/images/3/3c/VTK_Examples_RenderMan2.png To try it out, you will need to pull the latest head from the vtk repo. Enjoy, Bill FYI: All of the color plates in the original VTK books were rendered with BMRT, a free RenderMan clone that is no longer available. From A.Buykx at tnodiana.com Fri Apr 3 08:06:28 2015 From: A.Buykx at tnodiana.com (Andreas Buykx) Date: Fri, 3 Apr 2015 12:06:28 +0000 Subject: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter In-Reply-To: <551C5095.7050700@dsl.pipex.com> References: <65D987BE62E58141AA480A59A8B5BBEA6DEAF624@srv-mail.diana.local> , <551C5095.7050700@dsl.pipex.com> Message-ID: <65D987BE62E58141AA480A59A8B5BBEA6DEB1705@srv-mail.diana.local> Hi, All non-linear wedges have the same ordering of face points, causing their normal to point inward. Creating the wedge inside-out seems to work for the vtkUnstructuredGridGeometryFilter (UGGF) issue, but wouldn't this have side effects in routines in vtkCell or vtkCell3D, e.g. when interpolating, contouring, etc? >From code inspection I found out that for all wedges, the only method that uses the face point ordering array is the method IntersectWithLine, and that method seems to be independent of the orientation of the face. Changing the three methods that return the face points (GetFace and GetFaceArray) to return properly ordered faces would therefore have the same net result as changing the order of the points in the faces array. In both cases all direct and indirect clients (including UGGF) of these methods may produce different results. However, these differences in results, if any, are for the better I would say. For example it may not be necessary anymore to correct normals since they are already oriented consistently ;-). As for documentation, the documentation of vtkWedge does not mention anything specific about the orientation of face points or face normals, nor does the vtkCell3D or vtkCell. Also, I couldn't find any definitions of how face normal are supposed to be oriented in the books (toolkit ed.4, user's guide ed.11). I created a topic in my repository and made the necessary changes in all wedge classes. The tests that are mentioned for these classes succeed (cells.py fails because I have no VTKData, and TestCellCentersPointPlacer spits out some xml related to DartMeasurement which seems not related to the wedge test). Note that TestCellCentersPointPlacer creates an inverted wedge. How do we proceed? Kind regards, Andreas ________________________________________ From: John Platt [jcplatt at dsl.pipex.com] Sent: Wednesday, April 01, 2015 10:09 PM To: Berk Geveci; Andreas Buykx Cc: vtk-developers at vtk.org Subject: Re: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter Hi, I think this is also a problem for vtkDataSetSurfaceFilter when mixing quadratic hex's & wedges. If the actor opacity is reduced, the internal faces between the hex's & wedges are visible. This can be fixed by turning the wedge inside-out i.e. swapping points 1 & 2 and 4 & 5. The FE system I work with allows both right and left handed elements so the topology of each element must be checked and inverted if necessary. I agree that the order of the nodes in the face arrays should be changed to be consistent with the other cells. I suspect this would largely go unnoticed given the time this inconsistency has been present and the number of reports on the behaviour. Thanks, John. On 01/04/2015 16:42, Berk Geveci wrote: > Hi Andreas, > > Changing the ordering of vtkWedge would be a very large undertaking > given that there is years of documentation, file formats (in VTK and > 3rd party), code etc. that depend on a certain ordering. One less > intrusive way would be to change any vtkWedge methods that returns > faces to return them in a different order. I suspect this option is > doable but I'd like to hear from the community. The least intrusive > options is to fix the few filters that have this issue but I feel like > it is a band-aid. > > Best, > -berk > > On Wed, Apr 1, 2015 at 9:51 AM, Andreas Buykx wrote: >> Hi, >> >> >> >> To detect if coinciding faces of neighbouring 3D cells are connected, >> vtkUnstructuredGridGeometryFilter walks the points of these faces in >> opposite directions and expects the point ids to match. This fails for >> vtkWedge attached to e.g. vtkTetra and vtkHexahedron as demonstrated by the >> python script I attach. The root cause is that the vtkWedge::GetFaceArray >> and vtkWedge::GetFace return the face points in an ordering that makes the >> face normal point into the 3D cell instead of out of the 3D cell, like all >> other 3D cells do. The two other algorithms that generate surface cells >> (vtkDataSetSurfaceFilter and vtkGeometryFilter) don't suffer from this >> ordering because the former checks point ordering but explicitly allows both >> loop directions, and the latter only takes cell connectivity into account >> without checking point-ordering at all. >> >> >> >> I don't know what the reason is to have a different face-point ordering for >> the vtkWedge, but one of the other consequences is that the outer surface >> will have inconsistent cell normals as can easily be seen when loading the >> xml files produced by the tests in paraview, and showing the cell normals. >> So I would prefer to change the face-point ordering in vtkWedge. If that is >> not possible for some reason then I propose to make/update the case-blocks >> in the surface filters cell-type switches to re-order the face-points for >> the wedge faces. As long as this is not dealt with our FEA models will show >> edges where they should not be so I will have to solve this issue one way or >> another, and I'd like to contribute it to VTK as well. >> >> >> >> Shall I make a mantis issue for this? Who can help me with the git/gerrit >> stuff? >> >> >> >> Thanks a lot, >> >> Andreas Buykx >> >> ____________________________________________________________ >> TNO DIANA BV is a limited liability company registered in the trade register >> of the Chamber of Commerce as TNO DIANA BV with registered number 27252655. >> ____________________________________________________________ >> This e-mail and its contents are subject to the DISCLAIMER at >> http://tnodiana.com/content/Disclaimer >> ____________________________________________________________ >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > ____________________________________________________________ TNO DIANA BV is a limited liability company registered in the trade register of the Chamber of Commerce as TNO DIANA BV with registered number 27252655. ____________________________________________________________ This e-mail and its contents are subject to the DISCLAIMER at http://tnodiana.com/content/Disclaimer ____________________________________________________________ From majcjc at gmail.com Fri Apr 3 12:33:39 2015 From: majcjc at gmail.com (Lin M) Date: Fri, 3 Apr 2015 12:33:39 -0400 Subject: [vtk-developers] Class design for spline visualizations Message-ID: Hi all, My name is Lin. I'm interested in the project idea about spline visualizations from VTK/GSoC2015. I hope I can do some works on this topic and I understand that many preliminary discussions are needed for a new set of classes in VTK. This mail will contain the conversations about class design for this project. Any ideas and suggestions are very welcomed. Thank you all! BTW, here is the link to my proposal if anyone is interested about that. https://docs.google.com/document/d/1b8OHxb49jpx2qH_-KnK7VYB-HAGquXgXREkPnIzdHGM/edit?usp=sharing Best, Lin -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri Apr 3 12:56:12 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 3 Apr 2015 12:56:12 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: Message-ID: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> > My name is Lin. I'm interested in the project idea about spline visualizations from VTK/GSoC2015. I hope I can make some works on this topic and I understand that many preliminary discussions are needed for a new set of classes in VTK. This mail will contain the conversations about class design for this project. Hi Lin, One of the first things we should discuss is notation so we can be consistent and avoid confusion. Notation -------- One of the first steps will be interpolating points on B?zier patches given control points, P_i, and parametric coordinates, r. Note that i and r may be 1-, 2-, or 3-vectors depending on whether the patch is a curve, surface, or volumetric region. Because VTK assumes points always have 3-D coordinates, each control point will always have 4 coordinates (3 spatial coordinates plus a denominator because we are interested in rational functions). So, a simple bilinear surface patch might be defined by P_{0,0} = (0,0,0,1) P_{1,0} = (1,0,2,1) P_{1,1} = (1,1,0,1) P_{0,1} = (0,1,1,1) and for r = (0.5, 0.5), P(r) = (0.5, 0.5, 0.75, 1). P(r) can be projected to a 3-D point by dividing the first 3 coordinates by the fourth. Let's call the projected version P'(r) = (0.5/1, 0.5/1, 0.75/1). As the degree increases, more control points will be required. The example above is for a rectangular patch. B?zier patches may also be triangular or tetrahedral by using barycentric coordinates. https://en.wikipedia.org/wiki/B%C3%A9zier_triangle VTK background -------------- Because we are dealing with rational patches, one of the first issues will be how control points are represented. The vtkPoints class assumes that points always have 3 coordinates (not 4 like our control points). We can 1. Assume that control points are specified with 2 things: a vtkPoints instance plus a vtkDataArray holding the denominators. 2. Create a new vtkControlPoints class that inherits from vtkPoints and allows for an extra coordinate. 3. Not use vtkPoints instances at all and store control points in a vtkDataArray with 4 components per tuple. I am leaning toward option 2. Note that these classes do not force a particular memory layout because of recent changes to the VTK array classes. So, another related issue is how the interpolation techniques can be written to allow alternative memory layouts so that isogeometric finite element simulations can specify the memory layout instead of forcing the simulation to adopt VTK's. It would be a good idea to read this wiki page: http://www.vtk.org/Wiki/VTK/InSituDataStructures (especially the "Mapped vtkDataArrays" section) to understand how the array classes have changed recent to allow different memory layouts. A good first step would be to write a few tests to perform interpolation of some simple 1-, 2-, and 3-D patches given control points in a vtkDataArray and using the vtkDataArrayIteratorMacro to access control point coordinates. I can provide some control points, parametric coordinates, and the correct interpolated point values if you provide a function like void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, double* r); that interpolates P_i(r) and stores the result in outputPt by calling outputPt->InsertNextTuple(). David From bill.lorensen at gmail.com Fri Apr 3 16:20:10 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 3 Apr 2015 13:20:10 -0700 Subject: [vtk-developers] New instructions in gitlab merge info Message-ID: I like the new fetch instructions on the gitlab merge page. If Fetch the branch with git fetch https://gitlab.kitware.com/lorensen/vtk.git TestRIBExporter I think if this was changed to Fetch the branch and create a topic with git fetch https://gitlab.kitware.com/lorensen/vtk.git TestRIBExporter && git checkout FETCH_HEAD -b TestRIBExporter a topic with the proper name would be created. Also if the git command is on a separate line, one can double click and copy it. Bill -- Unpaid intern in the Santa Cruz OfficeBills at noware dot com From brad.king at kitware.com Fri Apr 3 16:33:47 2015 From: brad.king at kitware.com (Brad King) Date: Fri, 03 Apr 2015 16:33:47 -0400 Subject: [vtk-developers] New instructions in gitlab merge info In-Reply-To: References: Message-ID: <551EF92B.80005@kitware.com> On 04/03/2015 04:20 PM, Bill Lorensen wrote: > I think if this was changed to > > Fetch the branch and create a topic with git fetch > https://gitlab.kitware.com/lorensen/vtk.git TestRIBExporter && git > checkout FETCH_HEAD -b TestRIBExporter > > a topic with the proper name would be created. As explained in the discussion here: https://gitlab.kitware.com/vtk/vtk/merge_requests/15#note_9263 I don't think we should put the post-fetch part of the command line on the page. How a developer looks at the changes after fetching is a personal workflow choice. Furthermore, there is no single command one can put there that will always work without risking loss of work. Checkout with "-b" will fail if the branch exists. Checkout with "-B" will work but may lose work. Also there is no reason the reviewer has to use the same branch name. This is a change we're trying to get upstreamed to GitLab, and GitLab should not endorse a particular post-fetch workflow. The reviewer instructions have already been updated to show a few options for checking out the changes: https://gitlab.kitware.com/vtk/vtk/blob/22bcdc7c/Documentation/dev/git/develop.md#fetching-changes including your preferred cherry-pick approach. -Brad From bill.lorensen at gmail.com Fri Apr 3 16:41:52 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Fri, 3 Apr 2015 13:41:52 -0700 Subject: [vtk-developers] New instructions in gitlab merge info In-Reply-To: <551EF92B.80005@kitware.com> References: <551EF92B.80005@kitware.com> Message-ID: No problem. Just a suggestion. I do have my own workflow now. I find the best thing for me is: download the email patch from the download drop down git checkout -b topic-name git am the-email-patch On Fri, Apr 3, 2015 at 1:33 PM, Brad King wrote: > On 04/03/2015 04:20 PM, Bill Lorensen wrote: >> I think if this was changed to >> >> Fetch the branch and create a topic with git fetch >> https://gitlab.kitware.com/lorensen/vtk.git TestRIBExporter && git >> checkout FETCH_HEAD -b TestRIBExporter >> >> a topic with the proper name would be created. > > As explained in the discussion here: > > https://gitlab.kitware.com/vtk/vtk/merge_requests/15#note_9263 > > I don't think we should put the post-fetch part of the command > line on the page. How a developer looks at the changes after > fetching is a personal workflow choice. Furthermore, there is > no single command one can put there that will always work without > risking loss of work. Checkout with "-b" will fail if the branch > exists. Checkout with "-B" will work but may lose work. Also > there is no reason the reviewer has to use the same branch name. > > This is a change we're trying to get upstreamed to GitLab, and > GitLab should not endorse a particular post-fetch workflow. > > The reviewer instructions have already been updated to show a few > options for checking out the changes: > > https://gitlab.kitware.com/vtk/vtk/blob/22bcdc7c/Documentation/dev/git/develop.md#fetching-changes > > including your preferred cherry-pick approach. > > -Brad > -- Unpaid intern in BillsBasement at noware dot com From sebastien.jourdain at kitware.com Sat Apr 4 13:02:58 2015 From: sebastien.jourdain at kitware.com (Sebastien Jourdain) Date: Sat, 4 Apr 2015 11:02:58 -0600 Subject: [vtk-developers] Selecting libraries In-Reply-To: References: Message-ID: 1) Yes, just make sure you load all the needed libraries. 2) Modules create libraries and each module describe its dependencies (look at the files named: module.cmake) For each class from VTK you use find the module it belongs to and keep track of each dependencies. From that you should be able to create a list of library that you need. There might be an "automatic/better" way using CMake but I'm not aware of it. But I kind of recall some talk a long time ago (years) on the mailing list on how to build a VTK application without CMake and how to know which library you need to link against. Dave Cole and Bill Lorensen may have contributed to that topic as well as Marcus Hanwell. But that is just a memory that might be good to look into. (You may have to fake a C++ file to describe the dependencies.) 3) Might be lighter in memory. In case you only need half of VTK, your application can only embed those libs and be smaller on disk (and memory). Seb On Tue, Mar 31, 2015 at 11:47 AM, CSharpdotcom . wrote: > Hello, > > I've just been trying another Java example of VTK, as listed in > http://www.vtk.org/Wiki/VTK/Examples/Java/Cylinder, which I put into > NetBeans. When I use the code in the static block: > > static { > System.loadLibrary("vtkCommonCoreJava"); > System.loadLibrary("vtkFiltersSourcesJava"); > System.loadLibrary("vtkInteractionStyleJava"); > System.loadLibrary("vtkRenderingOpenGLJava"); > } > > as given in the listing, the application fails with the error message: > > Exception in thread "main" java.lang.UnsatisfiedLinkError: > vtk.vtkPolyDataMapper.VTKInit()J > .......... > > and I found that VTKInit() is called right at the very end of the > vtkPolyData class in vtk.jar. However, if I replace loading the > specified libraries in the static block above by loading all the > libraries using: > > static { > if (!vtkNativeLibrary.LoadAllNativeLibraries()) { > for (vtkNativeLibrary lib : vtkNativeLibrary.values()) { > if (!lib.IsLoaded()) > System.out.println(lib.GetLibraryName() + " not loaded"); > } > System.out.println("Make sure the search path is correct: "); > System.out.println(System.getProperty("java.library.path")); > } > vtkNativeLibrary.DisableOutputWindow(null); > } > > as copied from the code I got working last week, then the application > works correctly. > > My questions are: > > 1) Is there a way of fixing the error without loading all the libraries? > > 2) Related to that, is there a way of determining which libraries to > load, without having to load them all? > > 3) Is it better to load only the libraries you need rather than > loading them all? This of course will depend on knowing which > libraries to load from (2). > > At your convenience I would be grateful to have some help on this. > > Christopher Sharp > -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Sat Apr 4 21:00:57 2015 From: majcjc at gmail.com (Lin M) Date: Sat, 4 Apr 2015 21:00:57 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> Message-ID: Hi Dr. Thompson, Sorry for late reply. I have some questions here. In the function: void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, double* r); 1. Do I assume that i and r are both a 3-vectors here? If not, how do I determine the dimension of that? 2. Do I assume the highest degree of each polynomial dimension is equal to each other, thus the maximum of (i,j,k) for P_{i,j,k} can be calculated by max(i)=max(j)=max(k)=P_i->GetNumberOfTuples()/3? 3. Even I know the maximum of (i,j,k), what's the order of storage for the P_i in memory? Best, Lin On Fri, Apr 3, 2015 at 12:56 PM, David Thompson wrote: > > My name is Lin. I'm interested in the project idea about spline > visualizations from VTK/GSoC2015. I hope I can make some works on this > topic and I understand that many preliminary discussions are needed for a > new set of classes in VTK. This mail will contain the conversations about > class design for this project. > > Hi Lin, > > One of the first things we should discuss is notation so we can be > consistent and avoid confusion. > > Notation > -------- > > One of the first steps will be interpolating points on B?zier patches > given control points, P_i, and parametric coordinates, r. Note that i and r > may be 1-, 2-, or 3-vectors depending on whether the patch is a curve, > surface, or volumetric region. Because VTK assumes points always have 3-D > coordinates, each control point will always have 4 coordinates (3 spatial > coordinates plus a denominator because we are interested in rational > functions). So, a simple bilinear surface patch might be defined by > > P_{0,0} = (0,0,0,1) > P_{1,0} = (1,0,2,1) > P_{1,1} = (1,1,0,1) > P_{0,1} = (0,1,1,1) > > and for r = (0.5, 0.5), P(r) = (0.5, 0.5, 0.75, 1). P(r) can be projected > to a 3-D point by dividing the first 3 coordinates by the fourth. Let's > call the projected version P'(r) = (0.5/1, 0.5/1, 0.75/1). > > As the degree increases, more control points will be required. The example > above is for a rectangular patch. B?zier patches may also be triangular or > tetrahedral by using barycentric coordinates. > https://en.wikipedia.org/wiki/B%C3%A9zier_triangle > > VTK background > -------------- > > Because we are dealing with rational patches, one of the first issues will > be how control points are represented. The vtkPoints class assumes that > points always have 3 coordinates (not 4 like our control points). We can > > 1. Assume that control points are specified with 2 things: a vtkPoints > instance plus a vtkDataArray holding the denominators. > 2. Create a new vtkControlPoints class that inherits from vtkPoints and > allows for an extra coordinate. > 3. Not use vtkPoints instances at all and store control points in a > vtkDataArray with 4 components per tuple. > > I am leaning toward option 2. Note that these classes do not force a > particular memory layout because of recent changes to the VTK array > classes. So, another related issue is how the interpolation techniques can > be written to allow alternative memory layouts so that isogeometric finite > element simulations can specify the memory layout instead of forcing the > simulation to adopt VTK's. > > It would be a good idea to read this wiki page: > http://www.vtk.org/Wiki/VTK/InSituDataStructures (especially the "Mapped > vtkDataArrays" section) to understand how the array classes have changed > recent to allow different memory layouts. > > A good first step would be to write a few tests to perform interpolation > of some simple 1-, 2-, and 3-D patches given control points in a > vtkDataArray and using the vtkDataArrayIteratorMacro to access control > point coordinates. I can provide some control points, parametric > coordinates, and the correct interpolated point values if you provide a > function like > > void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, > double* r); > > that interpolates P_i(r) and stores the result in outputPt by calling > outputPt->InsertNextTuple(). > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon Apr 6 10:53:59 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 6 Apr 2015 10:53:59 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> Message-ID: <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> > In the function: > void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, double* r); Sorry, I see that I did not specify quite enough information. In addition to P_i, you will also need to know how the control points are arranged. So, a proper signature could be void InterpolateOnPatch(vtkDataArray* outputPt, int dim, vtkDataArray* P_i, int* degree, double* r); where outputPt is a VTK data array to hold interpolated points. It will have 3 components; you should use InsertNextPoint() to add the 3-D coordinates mapped from r by the patch. dim is the dimension of the parameter-space. This is the size of the arrays named r and degree. P_i is a VTK data array of control point coordinates. It will have 3 components per tuple. The number of tuples will be the product of the entries in degree + 1. For example, if dim == 3, then P_i should have (degree[0] + 1)*(degree[1] + 1)*(degree[2] + 1) tuples. degree is an array of integer values specifying the degree of along each parametric coordinate in the patch. When dim == 1, degree has a single entry specifying the degree of a curve (degree[0] == 1 -> linear, degree[0] == 3 -> cubic). r is an array of parametric coordinates specifying a single point on the patch. It is of length dim. I am working on a test that will pass this function curve, surface, and volume patches of different degree including some well-known test cases like this biquartic sphere of parametric dimension 2 (dim == 2): http://content.lib.utah.edu/utils/getfile/collection/uspace/id/3043/filename/2155.pdf Does this make more sense? David > 1. Do I assume that i and r are both a 3-vectors here? If not, how do I determine the dimension of that? > 2. Do I assume the highest degree of each polynomial dimension is equal to each other, thus the maximum of (i,j,k) for P_{i,j,k} can be calculated by max(i)=max(j)=max(k)=P_i->GetNumberOfTuples()/3? > 3. Even I know the maximum of (i,j,k), what's the order of storage for the P_i in memory? > > Best, > Lin > > > On Fri, Apr 3, 2015 at 12:56 PM, David Thompson wrote: > > My name is Lin. I'm interested in the project idea about spline visualizations from VTK/GSoC2015. I hope I can make some works on this topic and I understand that many preliminary discussions are needed for a new set of classes in VTK. This mail will contain the conversations about class design for this project. > > Hi Lin, > > One of the first things we should discuss is notation so we can be consistent and avoid confusion. > > Notation > -------- > > One of the first steps will be interpolating points on B?zier patches given control points, P_i, and parametric coordinates, r. Note that i and r may be 1-, 2-, or 3-vectors depending on whether the patch is a curve, surface, or volumetric region. Because VTK assumes points always have 3-D coordinates, each control point will always have 4 coordinates (3 spatial coordinates plus a denominator because we are interested in rational functions). So, a simple bilinear surface patch might be defined by > > P_{0,0} = (0,0,0,1) > P_{1,0} = (1,0,2,1) > P_{1,1} = (1,1,0,1) > P_{0,1} = (0,1,1,1) > > and for r = (0.5, 0.5), P(r) = (0.5, 0.5, 0.75, 1). P(r) can be projected to a 3-D point by dividing the first 3 coordinates by the fourth. Let's call the projected version P'(r) = (0.5/1, 0.5/1, 0.75/1). > > As the degree increases, more control points will be required. The example above is for a rectangular patch. B?zier patches may also be triangular or tetrahedral by using barycentric coordinates. https://en.wikipedia.org/wiki/B%C3%A9zier_triangle > > VTK background > -------------- > > Because we are dealing with rational patches, one of the first issues will be how control points are represented. The vtkPoints class assumes that points always have 3 coordinates (not 4 like our control points). We can > > 1. Assume that control points are specified with 2 things: a vtkPoints instance plus a vtkDataArray holding the denominators. > 2. Create a new vtkControlPoints class that inherits from vtkPoints and allows for an extra coordinate. > 3. Not use vtkPoints instances at all and store control points in a vtkDataArray with 4 components per tuple. > > I am leaning toward option 2. Note that these classes do not force a particular memory layout because of recent changes to the VTK array classes. So, another related issue is how the interpolation techniques can be written to allow alternative memory layouts so that isogeometric finite element simulations can specify the memory layout instead of forcing the simulation to adopt VTK's. > > It would be a good idea to read this wiki page: http://www.vtk.org/Wiki/VTK/InSituDataStructures (especially the "Mapped vtkDataArrays" section) to understand how the array classes have changed recent to allow different memory layouts. > > A good first step would be to write a few tests to perform interpolation of some simple 1-, 2-, and 3-D patches given control points in a vtkDataArray and using the vtkDataArrayIteratorMacro to access control point coordinates. I can provide some control points, parametric coordinates, and the correct interpolated point values if you provide a function like > > void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, double* r); > > that interpolates P_i(r) and stores the result in outputPt by calling outputPt->InsertNextTuple(). > > David > From david.thompson at kitware.com Mon Apr 6 10:55:23 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 6 Apr 2015 10:55:23 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> Message-ID: <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> Hi Lin, One last correction: P_i will have 4 components per tuple. The outputPt array may have either 3 or 4 components per tuple (depending on whether you perform the projection division operation or not). David On Apr 6, 2015, at 10:53 AM, David Thompson wrote: >> In the function: >> void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, double* r); > > Sorry, I see that I did not specify quite enough information. In addition to P_i, you will also need to know how the control points are arranged. So, a proper signature could be > > void InterpolateOnPatch(vtkDataArray* outputPt, int dim, vtkDataArray* P_i, int* degree, double* r); > > where > > outputPt is a VTK data array to hold interpolated points. > It will have 3 components; you should use InsertNextPoint() > to add the 3-D coordinates mapped from r by the patch. > dim is the dimension of the parameter-space. > This is the size of the arrays named r and degree. > P_i is a VTK data array of control point coordinates. > It will have 3 components per tuple. > The number of tuples will be the product of the entries > in degree + 1. For example, if dim == 3, then P_i should > have (degree[0] + 1)*(degree[1] + 1)*(degree[2] + 1) tuples. > degree is an array of integer values specifying the degree > of along each parametric coordinate in the patch. > When dim == 1, degree has a single entry specifying the > degree of a curve (degree[0] == 1 -> linear, degree[0] == 3 -> cubic). > r is an array of parametric coordinates specifying a single point > on the patch. It is of length dim. > > I am working on a test that will pass this function curve, surface, and volume patches of different degree including some well-known test cases like this biquartic sphere of parametric dimension 2 (dim == 2): > > http://content.lib.utah.edu/utils/getfile/collection/uspace/id/3043/filename/2155.pdf > > Does this make more sense? > > David > >> 1. Do I assume that i and r are both a 3-vectors here? If not, how do I determine the dimension of that? >> 2. Do I assume the highest degree of each polynomial dimension is equal to each other, thus the maximum of (i,j,k) for P_{i,j,k} can be calculated by max(i)=max(j)=max(k)=P_i->GetNumberOfTuples()/3? >> 3. Even I know the maximum of (i,j,k), what's the order of storage for the P_i in memory? >> >> Best, >> Lin >> >> >> On Fri, Apr 3, 2015 at 12:56 PM, David Thompson wrote: >>> My name is Lin. I'm interested in the project idea about spline visualizations from VTK/GSoC2015. I hope I can make some works on this topic and I understand that many preliminary discussions are needed for a new set of classes in VTK. This mail will contain the conversations about class design for this project. >> >> Hi Lin, >> >> One of the first things we should discuss is notation so we can be consistent and avoid confusion. >> >> Notation >> -------- >> >> One of the first steps will be interpolating points on B?zier patches given control points, P_i, and parametric coordinates, r. Note that i and r may be 1-, 2-, or 3-vectors depending on whether the patch is a curve, surface, or volumetric region. Because VTK assumes points always have 3-D coordinates, each control point will always have 4 coordinates (3 spatial coordinates plus a denominator because we are interested in rational functions). So, a simple bilinear surface patch might be defined by >> >> P_{0,0} = (0,0,0,1) >> P_{1,0} = (1,0,2,1) >> P_{1,1} = (1,1,0,1) >> P_{0,1} = (0,1,1,1) >> >> and for r = (0.5, 0.5), P(r) = (0.5, 0.5, 0.75, 1). P(r) can be projected to a 3-D point by dividing the first 3 coordinates by the fourth. Let's call the projected version P'(r) = (0.5/1, 0.5/1, 0.75/1). >> >> As the degree increases, more control points will be required. The example above is for a rectangular patch. B?zier patches may also be triangular or tetrahedral by using barycentric coordinates. https://en.wikipedia.org/wiki/B%C3%A9zier_triangle >> >> VTK background >> -------------- >> >> Because we are dealing with rational patches, one of the first issues will be how control points are represented. The vtkPoints class assumes that points always have 3 coordinates (not 4 like our control points). We can >> >> 1. Assume that control points are specified with 2 things: a vtkPoints instance plus a vtkDataArray holding the denominators. >> 2. Create a new vtkControlPoints class that inherits from vtkPoints and allows for an extra coordinate. >> 3. Not use vtkPoints instances at all and store control points in a vtkDataArray with 4 components per tuple. >> >> I am leaning toward option 2. Note that these classes do not force a particular memory layout because of recent changes to the VTK array classes. So, another related issue is how the interpolation techniques can be written to allow alternative memory layouts so that isogeometric finite element simulations can specify the memory layout instead of forcing the simulation to adopt VTK's. >> >> It would be a good idea to read this wiki page: http://www.vtk.org/Wiki/VTK/InSituDataStructures (especially the "Mapped vtkDataArrays" section) to understand how the array classes have changed recent to allow different memory layouts. >> >> A good first step would be to write a few tests to perform interpolation of some simple 1-, 2-, and 3-D patches given control points in a vtkDataArray and using the vtkDataArrayIteratorMacro to access control point coordinates. I can provide some control points, parametric coordinates, and the correct interpolated point values if you provide a function like >> >> void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, double* r); >> >> that interpolates P_i(r) and stores the result in outputPt by calling outputPt->InsertNextTuple(). >> >> David >> > From david.gobbi at gmail.com Mon Apr 6 11:07:34 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 6 Apr 2015 09:07:34 -0600 Subject: [vtk-developers] Gitlab and interdiffs Message-ID: Hi All, One problem that I've had with gitlab is that "Changes since last check:" doesn't work as advertised. It always shows the diff versus master. Locally, I can generate an interdiff for a revised branch, using the SHA of the old and new revision of the branch. This is nice, because it works regardless of whether the branch was rebased, amended, or added to: git show origin/master..1e0a5ac > /tmp/diff1.txt git show origin/master..d9ec645 > /tmp/diff2.txt interdiff /tmp/diff1.txt /tmp/diff1.txt Is there any possibility that Gitlab can show an interdiff? - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Mon Apr 6 11:17:35 2015 From: majcjc at gmail.com (Lin M) Date: Mon, 6 Apr 2015 11:17:35 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> Message-ID: Yes, I got it now. :-) The only left thing is a presumption that how control points are arranged. My opinion is that the control points are stored in this order: P_{0, 0, 0};P_{1, 0, 0};...;P_{degree[0], 0, 0}; P_{0, 1, 0};P_{1, 1, 0};...;P_{degree[0], 1, 0}; ... P_{0, degree[1], 0};P_{1, degree[1], 0};...;P_{degree[0], degree[1], 0}; P_{0, 0, 1};P_{1, 0, 1};...;P_{degree[0], 0, 1}; ... P_{0, degree[1], degree[2]};P_{1, degree[1], degree[2]};...;P_{degree[0], degree[1], degree[2]}; On Mon, Apr 6, 2015 at 10:55 AM, David Thompson wrote: > Hi Lin, > > One last correction: P_i will have 4 components per tuple. The outputPt > array may have either 3 or 4 components per tuple (depending on whether you > perform the projection division operation or not). > > David > > On Apr 6, 2015, at 10:53 AM, David Thompson > wrote: > > >> In the function: > >> void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, > double* r); > > > > Sorry, I see that I did not specify quite enough information. In > addition to P_i, you will also need to know how the control points are > arranged. So, a proper signature could be > > > > void InterpolateOnPatch(vtkDataArray* outputPt, int dim, vtkDataArray* > P_i, int* degree, double* r); > > > > where > > > > outputPt is a VTK data array to hold interpolated points. > > It will have 3 components; you should use InsertNextPoint() > > to add the 3-D coordinates mapped from r by the patch. > > dim is the dimension of the parameter-space. > > This is the size of the arrays named r and degree. > > P_i is a VTK data array of control point coordinates. > > It will have 3 components per tuple. > > The number of tuples will be the product of the entries > > in degree + 1. For example, if dim == 3, then P_i should > > have (degree[0] + 1)*(degree[1] + 1)*(degree[2] + 1) tuples. > > degree is an array of integer values specifying the degree > > of along each parametric coordinate in the patch. > > When dim == 1, degree has a single entry specifying the > > degree of a curve (degree[0] == 1 -> linear, degree[0] == 3 -> > cubic). > > r is an array of parametric coordinates specifying a single point > > on the patch. It is of length dim. > > > > I am working on a test that will pass this function curve, surface, and > volume patches of different degree including some well-known test cases > like this biquartic sphere of parametric dimension 2 (dim == 2): > > > > > http://content.lib.utah.edu/utils/getfile/collection/uspace/id/3043/filename/2155.pdf > > > > Does this make more sense? > > > > David > > > >> 1. Do I assume that i and r are both a 3-vectors here? If not, how do I > determine the dimension of that? > >> 2. Do I assume the highest degree of each polynomial dimension is equal > to each other, thus the maximum of (i,j,k) for P_{i,j,k} can be calculated > by max(i)=max(j)=max(k)=P_i->GetNumberOfTuples()/3? > >> 3. Even I know the maximum of (i,j,k), what's the order of storage for > the P_i in memory? > >> > >> Best, > >> Lin > >> > >> > >> On Fri, Apr 3, 2015 at 12:56 PM, David Thompson < > david.thompson at kitware.com> wrote: > >>> My name is Lin. I'm interested in the project idea about spline > visualizations from VTK/GSoC2015. I hope I can make some works on this > topic and I understand that many preliminary discussions are needed for a > new set of classes in VTK. This mail will contain the conversations about > class design for this project. > >> > >> Hi Lin, > >> > >> One of the first things we should discuss is notation so we can be > consistent and avoid confusion. > >> > >> Notation > >> -------- > >> > >> One of the first steps will be interpolating points on B?zier patches > given control points, P_i, and parametric coordinates, r. Note that i and r > may be 1-, 2-, or 3-vectors depending on whether the patch is a curve, > surface, or volumetric region. Because VTK assumes points always have 3-D > coordinates, each control point will always have 4 coordinates (3 spatial > coordinates plus a denominator because we are interested in rational > functions). So, a simple bilinear surface patch might be defined by > >> > >> P_{0,0} = (0,0,0,1) > >> P_{1,0} = (1,0,2,1) > >> P_{1,1} = (1,1,0,1) > >> P_{0,1} = (0,1,1,1) > >> > >> and for r = (0.5, 0.5), P(r) = (0.5, 0.5, 0.75, 1). P(r) can be > projected to a 3-D point by dividing the first 3 coordinates by the fourth. > Let's call the projected version P'(r) = (0.5/1, 0.5/1, 0.75/1). > >> > >> As the degree increases, more control points will be required. The > example above is for a rectangular patch. B?zier patches may also be > triangular or tetrahedral by using barycentric coordinates. > https://en.wikipedia.org/wiki/B%C3%A9zier_triangle > >> > >> VTK background > >> -------------- > >> > >> Because we are dealing with rational patches, one of the first issues > will be how control points are represented. The vtkPoints class assumes > that points always have 3 coordinates (not 4 like our control points). We > can > >> > >> 1. Assume that control points are specified with 2 things: a vtkPoints > instance plus a vtkDataArray holding the denominators. > >> 2. Create a new vtkControlPoints class that inherits from vtkPoints and > allows for an extra coordinate. > >> 3. Not use vtkPoints instances at all and store control points in a > vtkDataArray with 4 components per tuple. > >> > >> I am leaning toward option 2. Note that these classes do not force a > particular memory layout because of recent changes to the VTK array > classes. So, another related issue is how the interpolation techniques can > be written to allow alternative memory layouts so that isogeometric finite > element simulations can specify the memory layout instead of forcing the > simulation to adopt VTK's. > >> > >> It would be a good idea to read this wiki page: > http://www.vtk.org/Wiki/VTK/InSituDataStructures (especially the "Mapped > vtkDataArrays" section) to understand how the array classes have changed > recent to allow different memory layouts. > >> > >> A good first step would be to write a few tests to perform > interpolation of some simple 1-, 2-, and 3-D patches given control points > in a vtkDataArray and using the vtkDataArrayIteratorMacro to access control > point coordinates. I can provide some control points, parametric > coordinates, and the correct interpolated point values if you provide a > function like > >> > >> void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, > double* r); > >> > >> that interpolates P_i(r) and stores the result in outputPt by calling > outputPt->InsertNextTuple(). > >> > >> David > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Apr 6 11:54:52 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 6 Apr 2015 08:54:52 -0700 Subject: [vtk-developers] Gitlab and interdiffs In-Reply-To: References: Message-ID: I agree that this is bothersome. Makes it more difficult to review a patch. On Mon, Apr 6, 2015 at 8:07 AM, David Gobbi wrote: > Hi All, > > One problem that I've had with gitlab is that "Changes since last check:" > doesn't work as advertised. It always shows the diff versus master. > > Locally, I can generate an interdiff for a revised branch, using the SHA > of the old and new revision of the branch. This is nice, because it works > regardless of whether the branch was rebased, amended, or added to: > > git show origin/master..1e0a5ac > /tmp/diff1.txt > git show origin/master..d9ec645 > /tmp/diff2.txt > interdiff /tmp/diff1.txt /tmp/diff1.txt > > Is there any possibility that Gitlab can show an interdiff? > > - David > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 utkarsh.ayachit at kitware.com Mon Apr 6 12:12:26 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 6 Apr 2015 12:12:26 -0400 Subject: [vtk-developers] Gitlab and interdiffs In-Reply-To: References: Message-ID: Yup, that's a known issue. Ben has strategy in mind to get that working. On Mon, Apr 6, 2015 at 11:54 AM, Bill Lorensen wrote: > I agree that this is bothersome. Makes it more difficult to review a patch. > > On Mon, Apr 6, 2015 at 8:07 AM, David Gobbi wrote: >> Hi All, >> >> One problem that I've had with gitlab is that "Changes since last check:" >> doesn't work as advertised. It always shows the diff versus master. >> >> Locally, I can generate an interdiff for a revised branch, using the SHA >> of the old and new revision of the branch. This is nice, because it works >> regardless of whether the branch was rebased, amended, or added to: >> >> git show origin/master..1e0a5ac > /tmp/diff1.txt >> git show origin/master..d9ec645 > /tmp/diff2.txt >> interdiff /tmp/diff1.txt /tmp/diff1.txt >> >> Is there any possibility that Gitlab can show an interdiff? >> >> - David >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From ben.boeckel at kitware.com Mon Apr 6 13:26:13 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 6 Apr 2015 13:26:13 -0400 Subject: [vtk-developers] Gitlab and interdiffs In-Reply-To: References: Message-ID: <20150406172613.GA18934@megas.kitware.com> On Mon, Apr 06, 2015 at 12:12:26 -0400, Utkarsh Ayachit wrote: > Yup, that's a known issue. Ben has strategy in mind to get that working. Basically the problem is that the 'compare' page always does 'git diff a...b' which shows the commits in b not in a. What we need is a way to do arbitrary diffs. A quick look at the gitlab code, it appears changes will be necessary to: https://github.com/gitlabhq/gitlab_git/blob/master/lib/gitlab_git/diff.rb#L14-25 to offer a "straight diff" mode. --Ben From kevin.dean at decisionsciencescorp.com Mon Apr 6 13:29:50 2015 From: kevin.dean at decisionsciencescorp.com (Kevin Dean) Date: Mon, 6 Apr 2015 10:29:50 -0700 Subject: [vtk-developers] libvtkCommonCore-6.3.so build error Message-ID: Hey, my name is Kevin. I am recently going through trying to the VTK build process. However, I have changed the *CMAKE_INSTALL_PREFIX* location. For some reason, I get a few complaints when trying to do this. The first and foremost error is this: * [100%] Built target vtkViewsInfovisInstall the project...-- Install configuration: "Debug"CMake Error at cmake_install.cmake:36 (FILE): file INSTALL cannot find "/home/kdean/install_vtk/CMakeFiles/VTKConfig.cmake".* the *VTKConfig.cmake* file is still within the build directory. Upon opening the file, I found the locations of the modules were correct. So I guess my first question, is there a location in the CMakeLists (or other lists) that specifies where this file gets dumped? I will keep sifting through it too. So, the cheat way until I get that figured out was just to copy it to the specified location. Then I ran into my next error: *CMake Error at /home/kdean/install_vtk/Common/Core/cmake_install.cmake:47 (FILE): file INSTALL cannot find "/home/kdean/install_vtk/lib/libvtkCommonCore-6.3.so.1".Call Stack (most recent call first): cmake_install.cmake:99 (INCLUDE)* after doing an [ *ls -l* ] on the lib directory within my install path, I found that the *libvtkCommonCore-6.3.so * file was in fact there, but there must have been a problem with linking this correctly. Are there any suggestions of where to go from here or how to debug this issue? Any help is appreciated, thank you very much! Kevin E. Dean -- This email and its contents are confidential. If you are not the intended recipient, please do not disclose or use the information within this email or its attachments. If you have received this email in error, please report the error to the sender by return email and delete this communication from your records. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kevin.dean at decisionsciencescorp.com Mon Apr 6 13:41:02 2015 From: kevin.dean at decisionsciencescorp.com (Kevin Dean) Date: Mon, 6 Apr 2015 10:41:02 -0700 Subject: [vtk-developers] libvtkCommonCore-6.3.so build error In-Reply-To: References: Message-ID: sorry, should have said that I set the *VTK_BINARY_DIR* to the *CMAKE_INSTALL_PREFIX* On Mon, Apr 6, 2015 at 10:29 AM, Kevin Dean < kevin.dean at decisionsciencescorp.com> wrote: > Hey, my name is Kevin. > > I am recently going through trying to the VTK build process. However, I > have changed the *CMAKE_INSTALL_PREFIX* location. For some reason, I get > a few complaints when trying to do this. The first and foremost error is > this: > > > > > > > * [100%] Built target vtkViewsInfovisInstall the project...-- Install > configuration: "Debug"CMake Error at cmake_install.cmake:36 (FILE): file > INSTALL cannot find "/home/kdean/install_vtk/CMakeFiles/VTKConfig.cmake".* > > the *VTKConfig.cmake* file is still within the build directory. Upon > opening the file, I found the locations of the modules were correct. So I > guess my first question, is there a location in the CMakeLists (or other > lists) that specifies where this file gets dumped? I will keep sifting > through it too. > > So, the cheat way until I get that figured out was just to copy it to the > specified location. Then I ran into my next error: > > > > > > *CMake Error at /home/kdean/install_vtk/Common/Core/cmake_install.cmake:47 > (FILE): file INSTALL cannot find > "/home/kdean/install_vtk/lib/libvtkCommonCore-6.3.so.1".Call Stack (most > recent call first): cmake_install.cmake:99 (INCLUDE)* > > after doing an [ *ls -l* ] on the lib directory within my install path, I > found that the *libvtkCommonCore-6.3.so * > file was in fact there, but there must have been a problem with linking > this correctly. Are there any suggestions of where to go from here or how > to debug this issue? Any help is appreciated, thank you very much! > > Kevin E. Dean > -- This email and its contents are confidential. If you are not the intended recipient, please do not disclose or use the information within this email or its attachments. If you have received this email in error, please report the error to the sender by return email and delete this communication from your records. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Mon Apr 6 13:47:05 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Mon, 6 Apr 2015 11:47:05 -0600 Subject: [vtk-developers] Gitlab and interdiffs In-Reply-To: <20150406172613.GA18934@megas.kitware.com> References: <20150406172613.GA18934@megas.kitware.com> Message-ID: On Mon, Apr 6, 2015 at 11:26 AM, Ben Boeckel wrote: > > > Basically the problem is that the 'compare' page always does 'git diff > a...b' which shows the commits in b not in a. What we need is a way to > do arbitrary diffs. A quick look at the gitlab code, it appears changes > will be necessary to: > > > https://github.com/gitlabhq/gitlab_git/blob/master/lib/gitlab_git/diff.rb#L14-25 > > to offer a "straight diff" mode. > A straight diff will be an improvement (and it's too bad that gitlab's compare tool doesn't provide it as an option). But that still won't give nice results if the branch is rebased. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Mon Apr 6 14:02:24 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 6 Apr 2015 14:02:24 -0400 Subject: [vtk-developers] Gitlab and interdiffs In-Reply-To: References: <20150406172613.GA18934@megas.kitware.com> Message-ID: <20150406180224.GA26299@megas.kitware.com> On Mon, Apr 06, 2015 at 11:47:05 -0600, David Gobbi wrote: > A straight diff will be an improvement (and it's too bad that gitlab's > compare tool > doesn't provide it as an option). But that still won't give nice results > if the branch > is rebased. True, but this is also good for "what changed" reasons anyways, so I think having at least the `a b` link is good even if there's a better one availble. Is there a generic diff we could use to handle all the cases? Or would "the shorter of `a...b` and `a b`" be a good heuristic? I think ReviewBoard does it by diffing: base...a base...b and generating a diff view from that. --Ben From bill.lorensen at gmail.com Mon Apr 6 14:04:15 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 6 Apr 2015 11:04:15 -0700 Subject: [vtk-developers] Gitlab and interdiffs In-Reply-To: <20150406180224.GA26299@megas.kitware.com> References: <20150406172613.GA18934@megas.kitware.com> <20150406180224.GA26299@megas.kitware.com> Message-ID: What did gerrit do? There you could select which patches to diff. Very convenient while reviewing. On Mon, Apr 6, 2015 at 11:02 AM, Ben Boeckel wrote: > On Mon, Apr 06, 2015 at 11:47:05 -0600, David Gobbi wrote: >> A straight diff will be an improvement (and it's too bad that gitlab's >> compare tool >> doesn't provide it as an option). But that still won't give nice results >> if the branch >> is rebased. > > True, but this is also good for "what changed" reasons anyways, so I > think having at least the `a b` link is good even if there's a better > one availble. Is there a generic diff we could use to handle all the > cases? Or would "the shorter of `a...b` and `a b`" be a good heuristic? > I think ReviewBoard does it by diffing: > > base...a > base...b > > and generating a diff view from that. > > --Ben > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > -- Unpaid intern in BillsBasement at noware dot com From ben.boeckel at kitware.com Mon Apr 6 14:05:06 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 6 Apr 2015 14:05:06 -0400 Subject: [vtk-developers] libvtkCommonCore-6.3.so build error In-Reply-To: References: Message-ID: <20150406180506.GB26299@megas.kitware.com> On Mon, Apr 06, 2015 at 10:41:02 -0700, Kevin Dean wrote: > sorry, should have said that I set the *VTK_BINARY_DIR* to the > *CMAKE_INSTALL_PREFIX* You shouldn't set VTK_BINARY_DIR manually. It is derived from where the build tree is. I'm also going to guess that no one has ever tried CMAKE_INSTALL_PREFIX == VTK_BINARY_DIR ever and I wouldn't be surprised that things don't quite work since "make install" will be overwriting files with themselves. It certainly won't work on Windows at least. --Ben From sean at rogue-research.com Mon Apr 6 14:12:23 2015 From: sean at rogue-research.com (Sean McBride) Date: Mon, 6 Apr 2015 14:12:23 -0400 Subject: [vtk-developers] vtkFiltersAMRCxx-TestImageToAMR failure Message-ID: <20150406181223.1439473454@mail.rogue-research.com> Utkarsh, git blame suggests you know this test. It's one of the few still failing on my torture dashboard. I debugged it a bit, but of course it's tricky not knowing any of this stuff. :) In TestImageToAMR.cxx line 120 (currently) is: vtkUniformGrid* grid = amr->GetDataSet(level,id); The very first time that line is hit, 'grid' has an x spacing of zero. From there things go bad, with divide by zero giving nan, and nan getting cast into int (which is undefined). The source of the zero is vtkImageToAMR.cxx line 282: spacing0[d] = 0.0; It looks a bit like an arbitrary placeholder, and if I change it to 666 the test then passes... Is it indeed an arbitrary placeholder? Could it be changed to 1.0? Other solution? Thanks, -- ____________________________________________________________ Sean McBride, B. Eng sean at rogue-research.com Rogue Research www.rogue-research.com Mac Software Developer Montr?al, Qu?bec, Canada From brad.king at kitware.com Mon Apr 6 14:15:45 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 06 Apr 2015 14:15:45 -0400 Subject: [vtk-developers] Gitlab and interdiffs In-Reply-To: References: <20150406172613.GA18934@megas.kitware.com> <20150406180224.GA26299@megas.kitware.com> Message-ID: <5522CD51.5010200@kitware.com> On 04/06/2015 02:04 PM, Bill Lorensen wrote: > What did gerrit do? There you could select which patches to diff. > Very convenient while reviewing. At one time Gerrit did the same thing GitLab is doing and was not good for rebased changes either. More recently I think it learned to compute a "smart" choice for the base version, including the possibility of temporary merges. I don't know exactly what they do. This would sometimes shows conflict markers in this kind of diff, but that just indicates a conflict was resolved by the rebase operation. -Brad From majcjc at gmail.com Mon Apr 6 16:25:12 2015 From: majcjc at gmail.com (Lin M) Date: Mon, 6 Apr 2015 16:25:12 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> Message-ID: Hi Dr. Thompson, I have written a simple class to evaluate interpolated coordinates. How can I submit the code for test? Best, Lin On Mon, Apr 6, 2015 at 11:17 AM, Lin M wrote: > Yes, I got it now. :-) > > The only left thing is a presumption that how control points are arranged. > My opinion is that the control points are stored in this order: > > P_{0, 0, 0};P_{1, 0, 0};...;P_{degree[0], 0, 0}; > P_{0, 1, 0};P_{1, 1, 0};...;P_{degree[0], 1, 0}; > ... > P_{0, degree[1], 0};P_{1, degree[1], 0};...;P_{degree[0], degree[1], 0}; > P_{0, 0, 1};P_{1, 0, 1};...;P_{degree[0], 0, 1}; > ... > P_{0, degree[1], degree[2]};P_{1, degree[1], degree[2]};...;P_{degree[0], > degree[1], degree[2]}; > > On Mon, Apr 6, 2015 at 10:55 AM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hi Lin, >> >> One last correction: P_i will have 4 components per tuple. The outputPt >> array may have either 3 or 4 components per tuple (depending on whether you >> perform the projection division operation or not). >> >> David >> >> On Apr 6, 2015, at 10:53 AM, David Thompson >> wrote: >> >> >> In the function: >> >> void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, >> double* r); >> > >> > Sorry, I see that I did not specify quite enough information. In >> addition to P_i, you will also need to know how the control points are >> arranged. So, a proper signature could be >> > >> > void InterpolateOnPatch(vtkDataArray* outputPt, int dim, vtkDataArray* >> P_i, int* degree, double* r); >> > >> > where >> > >> > outputPt is a VTK data array to hold interpolated points. >> > It will have 3 components; you should use InsertNextPoint() >> > to add the 3-D coordinates mapped from r by the patch. >> > dim is the dimension of the parameter-space. >> > This is the size of the arrays named r and degree. >> > P_i is a VTK data array of control point coordinates. >> > It will have 3 components per tuple. >> > The number of tuples will be the product of the entries >> > in degree + 1. For example, if dim == 3, then P_i should >> > have (degree[0] + 1)*(degree[1] + 1)*(degree[2] + 1) tuples. >> > degree is an array of integer values specifying the degree >> > of along each parametric coordinate in the patch. >> > When dim == 1, degree has a single entry specifying the >> > degree of a curve (degree[0] == 1 -> linear, degree[0] == 3 >> -> cubic). >> > r is an array of parametric coordinates specifying a single >> point >> > on the patch. It is of length dim. >> > >> > I am working on a test that will pass this function curve, surface, and >> volume patches of different degree including some well-known test cases >> like this biquartic sphere of parametric dimension 2 (dim == 2): >> > >> > >> http://content.lib.utah.edu/utils/getfile/collection/uspace/id/3043/filename/2155.pdf >> > >> > Does this make more sense? >> > >> > David >> > >> >> 1. Do I assume that i and r are both a 3-vectors here? If not, how do >> I determine the dimension of that? >> >> 2. Do I assume the highest degree of each polynomial dimension is >> equal to each other, thus the maximum of (i,j,k) for P_{i,j,k} can be >> calculated by max(i)=max(j)=max(k)=P_i->GetNumberOfTuples()/3? >> >> 3. Even I know the maximum of (i,j,k), what's the order of storage for >> the P_i in memory? >> >> >> >> Best, >> >> Lin >> >> >> >> >> >> On Fri, Apr 3, 2015 at 12:56 PM, David Thompson < >> david.thompson at kitware.com> wrote: >> >>> My name is Lin. I'm interested in the project idea about spline >> visualizations from VTK/GSoC2015. I hope I can make some works on this >> topic and I understand that many preliminary discussions are needed for a >> new set of classes in VTK. This mail will contain the conversations about >> class design for this project. >> >> >> >> Hi Lin, >> >> >> >> One of the first things we should discuss is notation so we can be >> consistent and avoid confusion. >> >> >> >> Notation >> >> -------- >> >> >> >> One of the first steps will be interpolating points on B?zier patches >> given control points, P_i, and parametric coordinates, r. Note that i and r >> may be 1-, 2-, or 3-vectors depending on whether the patch is a curve, >> surface, or volumetric region. Because VTK assumes points always have 3-D >> coordinates, each control point will always have 4 coordinates (3 spatial >> coordinates plus a denominator because we are interested in rational >> functions). So, a simple bilinear surface patch might be defined by >> >> >> >> P_{0,0} = (0,0,0,1) >> >> P_{1,0} = (1,0,2,1) >> >> P_{1,1} = (1,1,0,1) >> >> P_{0,1} = (0,1,1,1) >> >> >> >> and for r = (0.5, 0.5), P(r) = (0.5, 0.5, 0.75, 1). P(r) can be >> projected to a 3-D point by dividing the first 3 coordinates by the fourth. >> Let's call the projected version P'(r) = (0.5/1, 0.5/1, 0.75/1). >> >> >> >> As the degree increases, more control points will be required. The >> example above is for a rectangular patch. B?zier patches may also be >> triangular or tetrahedral by using barycentric coordinates. >> https://en.wikipedia.org/wiki/B%C3%A9zier_triangle >> >> >> >> VTK background >> >> -------------- >> >> >> >> Because we are dealing with rational patches, one of the first issues >> will be how control points are represented. The vtkPoints class assumes >> that points always have 3 coordinates (not 4 like our control points). We >> can >> >> >> >> 1. Assume that control points are specified with 2 things: a vtkPoints >> instance plus a vtkDataArray holding the denominators. >> >> 2. Create a new vtkControlPoints class that inherits from vtkPoints >> and allows for an extra coordinate. >> >> 3. Not use vtkPoints instances at all and store control points in a >> vtkDataArray with 4 components per tuple. >> >> >> >> I am leaning toward option 2. Note that these classes do not force a >> particular memory layout because of recent changes to the VTK array >> classes. So, another related issue is how the interpolation techniques can >> be written to allow alternative memory layouts so that isogeometric finite >> element simulations can specify the memory layout instead of forcing the >> simulation to adopt VTK's. >> >> >> >> It would be a good idea to read this wiki page: >> http://www.vtk.org/Wiki/VTK/InSituDataStructures (especially the "Mapped >> vtkDataArrays" section) to understand how the array classes have changed >> recent to allow different memory layouts. >> >> >> >> A good first step would be to write a few tests to perform >> interpolation of some simple 1-, 2-, and 3-D patches given control points >> in a vtkDataArray and using the vtkDataArrayIteratorMacro to access control >> point coordinates. I can provide some control points, parametric >> coordinates, and the correct interpolated point values if you provide a >> function like >> >> >> >> void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, >> double* r); >> >> >> >> that interpolates P_i(r) and stores the result in outputPt by calling >> outputPt->InsertNextTuple(). >> >> >> >> David >> >> >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon Apr 6 16:28:12 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 6 Apr 2015 16:28:12 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> Message-ID: <54647355-DFD4-489D-A282-1994902CB6E3@kitware.com> Hi Lin, > I have written a simple class to evaluate interpolated coordinates. How can I submit the code for test? Please create an account on https://gitlab.kitware.com/ . You can then fork the VTK repository https://gitlab.kitware.com/vtk/vtk and push branches to your fork of VTK for me and others on the mailing list to examine. Thanks, David > On Mon, Apr 6, 2015 at 11:17 AM, Lin M wrote: > Yes, I got it now. :-) > > The only left thing is a presumption that how control points are arranged. > My opinion is that the control points are stored in this order: > > P_{0, 0, 0};P_{1, 0, 0};...;P_{degree[0], 0, 0}; > P_{0, 1, 0};P_{1, 1, 0};...;P_{degree[0], 1, 0}; > ... > P_{0, degree[1], 0};P_{1, degree[1], 0};...;P_{degree[0], degree[1], 0}; > P_{0, 0, 1};P_{1, 0, 1};...;P_{degree[0], 0, 1}; > ... > P_{0, degree[1], degree[2]};P_{1, degree[1], degree[2]};...;P_{degree[0], degree[1], degree[2]}; > > On Mon, Apr 6, 2015 at 10:55 AM, David Thompson wrote: > Hi Lin, > > One last correction: P_i will have 4 components per tuple. The outputPt array may have either 3 or 4 components per tuple (depending on whether you perform the projection division operation or not). > > David > > On Apr 6, 2015, at 10:53 AM, David Thompson wrote: > > >> In the function: > >> void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, double* r); > > > > Sorry, I see that I did not specify quite enough information. In addition to P_i, you will also need to know how the control points are arranged. So, a proper signature could be > > > > void InterpolateOnPatch(vtkDataArray* outputPt, int dim, vtkDataArray* P_i, int* degree, double* r); > > > > where > > > > outputPt is a VTK data array to hold interpolated points. > > It will have 3 components; you should use InsertNextPoint() > > to add the 3-D coordinates mapped from r by the patch. > > dim is the dimension of the parameter-space. > > This is the size of the arrays named r and degree. > > P_i is a VTK data array of control point coordinates. > > It will have 3 components per tuple. > > The number of tuples will be the product of the entries > > in degree + 1. For example, if dim == 3, then P_i should > > have (degree[0] + 1)*(degree[1] + 1)*(degree[2] + 1) tuples. > > degree is an array of integer values specifying the degree > > of along each parametric coordinate in the patch. > > When dim == 1, degree has a single entry specifying the > > degree of a curve (degree[0] == 1 -> linear, degree[0] == 3 -> cubic). > > r is an array of parametric coordinates specifying a single point > > on the patch. It is of length dim. > > > > I am working on a test that will pass this function curve, surface, and volume patches of different degree including some well-known test cases like this biquartic sphere of parametric dimension 2 (dim == 2): > > > > http://content.lib.utah.edu/utils/getfile/collection/uspace/id/3043/filename/2155.pdf > > > > Does this make more sense? > > > > David > > > >> 1. Do I assume that i and r are both a 3-vectors here? If not, how do I determine the dimension of that? > >> 2. Do I assume the highest degree of each polynomial dimension is equal to each other, thus the maximum of (i,j,k) for P_{i,j,k} can be calculated by max(i)=max(j)=max(k)=P_i->GetNumberOfTuples()/3? > >> 3. Even I know the maximum of (i,j,k), what's the order of storage for the P_i in memory? > >> > >> Best, > >> Lin > >> > >> > >> On Fri, Apr 3, 2015 at 12:56 PM, David Thompson wrote: > >>> My name is Lin. I'm interested in the project idea about spline visualizations from VTK/GSoC2015. I hope I can make some works on this topic and I understand that many preliminary discussions are needed for a new set of classes in VTK. This mail will contain the conversations about class design for this project. > >> > >> Hi Lin, > >> > >> One of the first things we should discuss is notation so we can be consistent and avoid confusion. > >> > >> Notation > >> -------- > >> > >> One of the first steps will be interpolating points on B?zier patches given control points, P_i, and parametric coordinates, r. Note that i and r may be 1-, 2-, or 3-vectors depending on whether the patch is a curve, surface, or volumetric region. Because VTK assumes points always have 3-D coordinates, each control point will always have 4 coordinates (3 spatial coordinates plus a denominator because we are interested in rational functions). So, a simple bilinear surface patch might be defined by > >> > >> P_{0,0} = (0,0,0,1) > >> P_{1,0} = (1,0,2,1) > >> P_{1,1} = (1,1,0,1) > >> P_{0,1} = (0,1,1,1) > >> > >> and for r = (0.5, 0.5), P(r) = (0.5, 0.5, 0.75, 1). P(r) can be projected to a 3-D point by dividing the first 3 coordinates by the fourth. Let's call the projected version P'(r) = (0.5/1, 0.5/1, 0.75/1). > >> > >> As the degree increases, more control points will be required. The example above is for a rectangular patch. B?zier patches may also be triangular or tetrahedral by using barycentric coordinates. https://en.wikipedia.org/wiki/B%C3%A9zier_triangle > >> > >> VTK background > >> -------------- > >> > >> Because we are dealing with rational patches, one of the first issues will be how control points are represented. The vtkPoints class assumes that points always have 3 coordinates (not 4 like our control points). We can > >> > >> 1. Assume that control points are specified with 2 things: a vtkPoints instance plus a vtkDataArray holding the denominators. > >> 2. Create a new vtkControlPoints class that inherits from vtkPoints and allows for an extra coordinate. > >> 3. Not use vtkPoints instances at all and store control points in a vtkDataArray with 4 components per tuple. > >> > >> I am leaning toward option 2. Note that these classes do not force a particular memory layout because of recent changes to the VTK array classes. So, another related issue is how the interpolation techniques can be written to allow alternative memory layouts so that isogeometric finite element simulations can specify the memory layout instead of forcing the simulation to adopt VTK's. > >> > >> It would be a good idea to read this wiki page: http://www.vtk.org/Wiki/VTK/InSituDataStructures (especially the "Mapped vtkDataArrays" section) to understand how the array classes have changed recent to allow different memory layouts. > >> > >> A good first step would be to write a few tests to perform interpolation of some simple 1-, 2-, and 3-D patches given control points in a vtkDataArray and using the vtkDataArrayIteratorMacro to access control point coordinates. I can provide some control points, parametric coordinates, and the correct interpolated point values if you provide a function like > >> > >> void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, double* r); > >> > >> that interpolates P_i(r) and stores the result in outputPt by calling outputPt->InsertNextTuple(). > >> > >> David > >> > > > > > From david.thompson at kitware.com Mon Apr 6 16:39:44 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 6 Apr 2015 16:39:44 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <54647355-DFD4-489D-A282-1994902CB6E3@kitware.com> References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> <54647355-DFD4-489D-A282-1994902CB6E3@kitware.com> Message-ID: <664F50F1-D75E-4F50-97CD-351813F224AE@kitware.com> Hi Lin, If you are not familiar with git or the gitlab workflow for submitting branches, a project that would be an easy first step is to memoize[1] the vtkMath::Factorial function (which along with vtkMath::Binomial) could be used to compute coefficients for the Bernstein-Bezier polynomial. 1. cd /src git clone git at gitlab.kitware.com:yourAccount/VTK.git cd VTK 2. git checkout -b memoize-factorial 3. Modify vtkMath.{h,cxx} to memoize the factorial function and test it. 4. git commit -a 5. Assuming your fork of VTK is the remote named "origin", run git push origin memoize-factorial 6. In a browser, visit https://gitlab.kitware.com/VTK/VTK and submit a merge request (which indicates you want us to merge your memoize-factorial branch into VTK's master branch). David [1]: http://en.wikipedia.org/wiki/Memoize >> I have written a simple class to evaluate interpolated coordinates. How can I submit the code for test? > > Please create an account on https://gitlab.kitware.com/ . You can then fork the VTK repository https://gitlab.kitware.com/vtk/vtk and push branches to your fork of VTK for me and others on the mailing list to examine. > > Thanks, > David > > >> On Mon, Apr 6, 2015 at 11:17 AM, Lin M wrote: >> Yes, I got it now. :-) >> >> The only left thing is a presumption that how control points are arranged. >> My opinion is that the control points are stored in this order: >> >> P_{0, 0, 0};P_{1, 0, 0};...;P_{degree[0], 0, 0}; >> P_{0, 1, 0};P_{1, 1, 0};...;P_{degree[0], 1, 0}; >> ... >> P_{0, degree[1], 0};P_{1, degree[1], 0};...;P_{degree[0], degree[1], 0}; >> P_{0, 0, 1};P_{1, 0, 1};...;P_{degree[0], 0, 1}; >> ... >> P_{0, degree[1], degree[2]};P_{1, degree[1], degree[2]};...;P_{degree[0], degree[1], degree[2]}; >> >> On Mon, Apr 6, 2015 at 10:55 AM, David Thompson wrote: >> Hi Lin, >> >> One last correction: P_i will have 4 components per tuple. The outputPt array may have either 3 or 4 components per tuple (depending on whether you perform the projection division operation or not). >> >> David >> >> On Apr 6, 2015, at 10:53 AM, David Thompson wrote: >> >>>> In the function: >>>> void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, double* r); >>> >>> Sorry, I see that I did not specify quite enough information. In addition to P_i, you will also need to know how the control points are arranged. So, a proper signature could be >>> >>> void InterpolateOnPatch(vtkDataArray* outputPt, int dim, vtkDataArray* P_i, int* degree, double* r); >>> >>> where >>> >>> outputPt is a VTK data array to hold interpolated points. >>> It will have 3 components; you should use InsertNextPoint() >>> to add the 3-D coordinates mapped from r by the patch. >>> dim is the dimension of the parameter-space. >>> This is the size of the arrays named r and degree. >>> P_i is a VTK data array of control point coordinates. >>> It will have 3 components per tuple. >>> The number of tuples will be the product of the entries >>> in degree + 1. For example, if dim == 3, then P_i should >>> have (degree[0] + 1)*(degree[1] + 1)*(degree[2] + 1) tuples. >>> degree is an array of integer values specifying the degree >>> of along each parametric coordinate in the patch. >>> When dim == 1, degree has a single entry specifying the >>> degree of a curve (degree[0] == 1 -> linear, degree[0] == 3 -> cubic). >>> r is an array of parametric coordinates specifying a single point >>> on the patch. It is of length dim. >>> >>> I am working on a test that will pass this function curve, surface, and volume patches of different degree including some well-known test cases like this biquartic sphere of parametric dimension 2 (dim == 2): >>> >>> http://content.lib.utah.edu/utils/getfile/collection/uspace/id/3043/filename/2155.pdf >>> >>> Does this make more sense? >>> >>> David >>> >>>> 1. Do I assume that i and r are both a 3-vectors here? If not, how do I determine the dimension of that? >>>> 2. Do I assume the highest degree of each polynomial dimension is equal to each other, thus the maximum of (i,j,k) for P_{i,j,k} can be calculated by max(i)=max(j)=max(k)=P_i->GetNumberOfTuples()/3? >>>> 3. Even I know the maximum of (i,j,k), what's the order of storage for the P_i in memory? >>>> >>>> Best, >>>> Lin >>>> >>>> >>>> On Fri, Apr 3, 2015 at 12:56 PM, David Thompson wrote: >>>>> My name is Lin. I'm interested in the project idea about spline visualizations from VTK/GSoC2015. I hope I can make some works on this topic and I understand that many preliminary discussions are needed for a new set of classes in VTK. This mail will contain the conversations about class design for this project. >>>> >>>> Hi Lin, >>>> >>>> One of the first things we should discuss is notation so we can be consistent and avoid confusion. >>>> >>>> Notation >>>> -------- >>>> >>>> One of the first steps will be interpolating points on B?zier patches given control points, P_i, and parametric coordinates, r. Note that i and r may be 1-, 2-, or 3-vectors depending on whether the patch is a curve, surface, or volumetric region. Because VTK assumes points always have 3-D coordinates, each control point will always have 4 coordinates (3 spatial coordinates plus a denominator because we are interested in rational functions). So, a simple bilinear surface patch might be defined by >>>> >>>> P_{0,0} = (0,0,0,1) >>>> P_{1,0} = (1,0,2,1) >>>> P_{1,1} = (1,1,0,1) >>>> P_{0,1} = (0,1,1,1) >>>> >>>> and for r = (0.5, 0.5), P(r) = (0.5, 0.5, 0.75, 1). P(r) can be projected to a 3-D point by dividing the first 3 coordinates by the fourth. Let's call the projected version P'(r) = (0.5/1, 0.5/1, 0.75/1). >>>> >>>> As the degree increases, more control points will be required. The example above is for a rectangular patch. B?zier patches may also be triangular or tetrahedral by using barycentric coordinates. https://en.wikipedia.org/wiki/B%C3%A9zier_triangle >>>> >>>> VTK background >>>> -------------- >>>> >>>> Because we are dealing with rational patches, one of the first issues will be how control points are represented. The vtkPoints class assumes that points always have 3 coordinates (not 4 like our control points). We can >>>> >>>> 1. Assume that control points are specified with 2 things: a vtkPoints instance plus a vtkDataArray holding the denominators. >>>> 2. Create a new vtkControlPoints class that inherits from vtkPoints and allows for an extra coordinate. >>>> 3. Not use vtkPoints instances at all and store control points in a vtkDataArray with 4 components per tuple. >>>> >>>> I am leaning toward option 2. Note that these classes do not force a particular memory layout because of recent changes to the VTK array classes. So, another related issue is how the interpolation techniques can be written to allow alternative memory layouts so that isogeometric finite element simulations can specify the memory layout instead of forcing the simulation to adopt VTK's. >>>> >>>> It would be a good idea to read this wiki page: http://www.vtk.org/Wiki/VTK/InSituDataStructures (especially the "Mapped vtkDataArrays" section) to understand how the array classes have changed recent to allow different memory layouts. >>>> >>>> A good first step would be to write a few tests to perform interpolation of some simple 1-, 2-, and 3-D patches given control points in a vtkDataArray and using the vtkDataArrayIteratorMacro to access control point coordinates. I can provide some control points, parametric coordinates, and the correct interpolated point values if you provide a function like >>>> >>>> void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, double* r); >>>> >>>> that interpolates P_i(r) and stores the result in outputPt by calling outputPt->InsertNextTuple(). >>>> >>>> David >>>> >>> >> >> >> > From majcjc at gmail.com Mon Apr 6 16:50:00 2015 From: majcjc at gmail.com (Lin M) Date: Mon, 6 Apr 2015 16:50:00 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <664F50F1-D75E-4F50-97CD-351813F224AE@kitware.com> References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> <54647355-DFD4-489D-A282-1994902CB6E3@kitware.com> <664F50F1-D75E-4F50-97CD-351813F224AE@kitware.com> Message-ID: Hi Dr. Thompson, Thank you. This is exactly what I need now! I'm using vtkMath::Binomial in my implementation. BTW, do you think my presumption which I wrote in the previous email for the order of storage for P_i is proper? Best, Lin On Mon, Apr 6, 2015 at 4:39 PM, David Thompson wrote: > Hi Lin, > > If you are not familiar with git or the gitlab workflow for submitting > branches, a project that would be an easy first step is to memoize[1] the > vtkMath::Factorial function (which along with vtkMath::Binomial) could be > used to compute coefficients for the Bernstein-Bezier polynomial. > > 1. cd /src > git clone git at gitlab.kitware.com:yourAccount/VTK.git > cd VTK > 2. git checkout -b memoize-factorial > 3. Modify vtkMath.{h,cxx} to memoize the factorial function and test it. > 4. git commit -a > 5. Assuming your fork of VTK is the remote named "origin", run > git push origin memoize-factorial > 6. In a browser, visit https://gitlab.kitware.com/VTK/VTK and submit a > merge request (which indicates you want us to merge your memoize-factorial > branch into VTK's master branch). > > David > > [1]: http://en.wikipedia.org/wiki/Memoize > > >> I have written a simple class to evaluate interpolated coordinates. How > can I submit the code for test? > > > > Please create an account on https://gitlab.kitware.com/ . You can then > fork the VTK repository https://gitlab.kitware.com/vtk/vtk and push > branches to your fork of VTK for me and others on the mailing list to > examine. > > > > Thanks, > > David > > > > > >> On Mon, Apr 6, 2015 at 11:17 AM, Lin M wrote: > >> Yes, I got it now. :-) > >> > >> The only left thing is a presumption that how control points are > arranged. > >> My opinion is that the control points are stored in this order: > >> > >> P_{0, 0, 0};P_{1, 0, 0};...;P_{degree[0], 0, 0}; > >> P_{0, 1, 0};P_{1, 1, 0};...;P_{degree[0], 1, 0}; > >> ... > >> P_{0, degree[1], 0};P_{1, degree[1], 0};...;P_{degree[0], degree[1], 0}; > >> P_{0, 0, 1};P_{1, 0, 1};...;P_{degree[0], 0, 1}; > >> ... > >> P_{0, degree[1], degree[2]};P_{1, degree[1], > degree[2]};...;P_{degree[0], degree[1], degree[2]}; > >> > >> On Mon, Apr 6, 2015 at 10:55 AM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hi Lin, > >> > >> One last correction: P_i will have 4 components per tuple. The outputPt > array may have either 3 or 4 components per tuple (depending on whether you > perform the projection division operation or not). > >> > >> David > >> > >> On Apr 6, 2015, at 10:53 AM, David Thompson > wrote: > >> > >>>> In the function: > >>>> void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, > double* r); > >>> > >>> Sorry, I see that I did not specify quite enough information. In > addition to P_i, you will also need to know how the control points are > arranged. So, a proper signature could be > >>> > >>> void InterpolateOnPatch(vtkDataArray* outputPt, int dim, vtkDataArray* > P_i, int* degree, double* r); > >>> > >>> where > >>> > >>> outputPt is a VTK data array to hold interpolated points. > >>> It will have 3 components; you should use InsertNextPoint() > >>> to add the 3-D coordinates mapped from r by the patch. > >>> dim is the dimension of the parameter-space. > >>> This is the size of the arrays named r and degree. > >>> P_i is a VTK data array of control point coordinates. > >>> It will have 3 components per tuple. > >>> The number of tuples will be the product of the entries > >>> in degree + 1. For example, if dim == 3, then P_i should > >>> have (degree[0] + 1)*(degree[1] + 1)*(degree[2] + 1) tuples. > >>> degree is an array of integer values specifying the degree > >>> of along each parametric coordinate in the patch. > >>> When dim == 1, degree has a single entry specifying the > >>> degree of a curve (degree[0] == 1 -> linear, degree[0] == 3 > -> cubic). > >>> r is an array of parametric coordinates specifying a single > point > >>> on the patch. It is of length dim. > >>> > >>> I am working on a test that will pass this function curve, surface, > and volume patches of different degree including some well-known test cases > like this biquartic sphere of parametric dimension 2 (dim == 2): > >>> > >>> > http://content.lib.utah.edu/utils/getfile/collection/uspace/id/3043/filename/2155.pdf > >>> > >>> Does this make more sense? > >>> > >>> David > >>> > >>>> 1. Do I assume that i and r are both a 3-vectors here? If not, how do > I determine the dimension of that? > >>>> 2. Do I assume the highest degree of each polynomial dimension is > equal to each other, thus the maximum of (i,j,k) for P_{i,j,k} can be > calculated by max(i)=max(j)=max(k)=P_i->GetNumberOfTuples()/3? > >>>> 3. Even I know the maximum of (i,j,k), what's the order of storage > for the P_i in memory? > >>>> > >>>> Best, > >>>> Lin > >>>> > >>>> > >>>> On Fri, Apr 3, 2015 at 12:56 PM, David Thompson < > david.thompson at kitware.com> wrote: > >>>>> My name is Lin. I'm interested in the project idea about spline > visualizations from VTK/GSoC2015. I hope I can make some works on this > topic and I understand that many preliminary discussions are needed for a > new set of classes in VTK. This mail will contain the conversations about > class design for this project. > >>>> > >>>> Hi Lin, > >>>> > >>>> One of the first things we should discuss is notation so we can be > consistent and avoid confusion. > >>>> > >>>> Notation > >>>> -------- > >>>> > >>>> One of the first steps will be interpolating points on B?zier patches > given control points, P_i, and parametric coordinates, r. Note that i and r > may be 1-, 2-, or 3-vectors depending on whether the patch is a curve, > surface, or volumetric region. Because VTK assumes points always have 3-D > coordinates, each control point will always have 4 coordinates (3 spatial > coordinates plus a denominator because we are interested in rational > functions). So, a simple bilinear surface patch might be defined by > >>>> > >>>> P_{0,0} = (0,0,0,1) > >>>> P_{1,0} = (1,0,2,1) > >>>> P_{1,1} = (1,1,0,1) > >>>> P_{0,1} = (0,1,1,1) > >>>> > >>>> and for r = (0.5, 0.5), P(r) = (0.5, 0.5, 0.75, 1). P(r) can be > projected to a 3-D point by dividing the first 3 coordinates by the fourth. > Let's call the projected version P'(r) = (0.5/1, 0.5/1, 0.75/1). > >>>> > >>>> As the degree increases, more control points will be required. The > example above is for a rectangular patch. B?zier patches may also be > triangular or tetrahedral by using barycentric coordinates. > https://en.wikipedia.org/wiki/B%C3%A9zier_triangle > >>>> > >>>> VTK background > >>>> -------------- > >>>> > >>>> Because we are dealing with rational patches, one of the first issues > will be how control points are represented. The vtkPoints class assumes > that points always have 3 coordinates (not 4 like our control points). We > can > >>>> > >>>> 1. Assume that control points are specified with 2 things: a > vtkPoints instance plus a vtkDataArray holding the denominators. > >>>> 2. Create a new vtkControlPoints class that inherits from vtkPoints > and allows for an extra coordinate. > >>>> 3. Not use vtkPoints instances at all and store control points in a > vtkDataArray with 4 components per tuple. > >>>> > >>>> I am leaning toward option 2. Note that these classes do not force a > particular memory layout because of recent changes to the VTK array > classes. So, another related issue is how the interpolation techniques can > be written to allow alternative memory layouts so that isogeometric finite > element simulations can specify the memory layout instead of forcing the > simulation to adopt VTK's. > >>>> > >>>> It would be a good idea to read this wiki page: > http://www.vtk.org/Wiki/VTK/InSituDataStructures (especially the "Mapped > vtkDataArrays" section) to understand how the array classes have changed > recent to allow different memory layouts. > >>>> > >>>> A good first step would be to write a few tests to perform > interpolation of some simple 1-, 2-, and 3-D patches given control points > in a vtkDataArray and using the vtkDataArrayIteratorMacro to access control > point coordinates. I can provide some control points, parametric > coordinates, and the correct interpolated point values if you provide a > function like > >>>> > >>>> void InterpolateOnPatch(vtkDataArray* outputPt, vtkDataArray* P_i, > double* r); > >>>> > >>>> that interpolates P_i(r) and stores the result in outputPt by calling > outputPt->InsertNextTuple(). > >>>> > >>>> David > >>>> > >>> > >> > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Mon Apr 6 19:42:23 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 6 Apr 2015 19:42:23 -0400 Subject: [vtk-developers] vtkFiltersAMRCxx-TestImageToAMR failure In-Reply-To: <20150406181223.1439473454@mail.rogue-research.com> References: <20150406181223.1439473454@mail.rogue-research.com> Message-ID: > Is it indeed an arbitrary placeholder? Could it be changed to 1.0? Other solution? Sean, yes. Looks like setting this to 1 should be acceptable. Thanks Utkarsh From david.thompson at kitware.com Mon Apr 6 20:00:06 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 6 Apr 2015 20:00:06 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> <54647355-DFD4-489D-A282-1994902CB6E3@kitware.com> <664F50F1-D75E-4F50-97CD-351813F224AE@kitware.com> Message-ID: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> Hi Lin, > .. BTW, do you think my presumption which I wrote in the previous email for the order of storage for P_i is proper? Yes, I think the layout you suggested is best because it matches the order in which VTK's structured point data is stored (since we will probably use this for storage in some cases). David From sean at rogue-research.com Tue Apr 7 12:36:18 2015 From: sean at rogue-research.com (Sean McBride) Date: Tue, 7 Apr 2015 12:36:18 -0400 Subject: [vtk-developers] coding standards & switch case label accidental fallthrough Message-ID: <20150407163618.1145058309@mail.rogue-research.com> Hi all, I'd like to propose a coding standards change... I have a patch here: that fixes clang -Wimplicit-fallthrough warnings, which warn when you have adjacent case labels in a switch without breaks between them. In other words, warns when you forget a 'break', which is pretty common, and often not deliberate. For deliberate fall-though, it provides a clang-only C++11 attribute to suppress the warning, which I wrapped into a macro VTK_FALLTHROUGH. So I propose that, by agreed convention, all deliberate switch case fall-through must use VTK_FALLTHOUGH annotations, ex: switch(var) { case 1: bar(); break; case 2: baz(); VTK_FALLTHROUGH; case 3: foo(); break; } Failure to use VTK_FALLTHROUGH above will cause warnings on C++11 clang builds. On other compilers it's less helpful, but still nicely self-documenting. 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 DLRdave at aol.com Tue Apr 7 13:42:51 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 7 Apr 2015 13:42:51 -0400 Subject: [vtk-developers] coding standards & switch case label accidental fallthrough In-Reply-To: <20150407163618.1145058309@mail.rogue-research.com> References: <20150407163618.1145058309@mail.rogue-research.com> Message-ID: Is there really no way to refactor and simply eliminate all the "intentional" fall throughs? It's a really nasty style to be allowing. It should be discouraged in general. Just my opinion, of course. D On Tue, Apr 7, 2015 at 12:36 PM, Sean McBride wrote: > Hi all, > > I'd like to propose a coding standards change... > > I have a patch here: > > > that fixes clang -Wimplicit-fallthrough warnings, which warn when you have adjacent case labels in a switch without breaks between them. In other words, warns when you forget a 'break', which is pretty common, and often not deliberate. > > For deliberate fall-though, it provides a clang-only C++11 attribute to suppress the warning, which I wrapped into a macro VTK_FALLTHROUGH. > > So I propose that, by agreed convention, all deliberate switch case fall-through must use VTK_FALLTHOUGH annotations, ex: > > switch(var) > { > case 1: > bar(); > break; > > case 2: > baz(); > VTK_FALLTHROUGH; > > case 3: > foo(); > break; > } > > Failure to use VTK_FALLTHROUGH above will cause warnings on C++11 clang builds. On other compilers it's less helpful, but still nicely self-documenting. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From sean at rogue-research.com Tue Apr 7 13:49:02 2015 From: sean at rogue-research.com (Sean McBride) Date: Tue, 7 Apr 2015 13:49:02 -0400 Subject: [vtk-developers] coding standards & switch case label accidental fallthrough In-Reply-To: References: <20150407163618.1145058309@mail.rogue-research.com> Message-ID: <20150407174902.1250819088@mail.rogue-research.com> On Tue, 7 Apr 2015 13:42:51 -0400, David Cole said: >Is there really no way to refactor and simply eliminate all the >"intentional" fall throughs? It's a really nasty style to be allowing. >It should be discouraged in general. I did refactor a few, but most I left because I was scared to touch or they were pretty elegant with fall-through. You can take a look: I'd be in favour of the coding standards saying something like "fall-through is discouraged, but when necessary must be annotated with VTK_FALLTHROUGH". 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 majcjc at gmail.com Tue Apr 7 21:30:15 2015 From: majcjc at gmail.com (Lin M) Date: Tue, 7 Apr 2015 21:30:15 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> <54647355-DFD4-489D-A282-1994902CB6E3@kitware.com> <664F50F1-D75E-4F50-97CD-351813F224AE@kitware.com> <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> Message-ID: Hi Dr. Thompson, I have created a merge request in the gitlab. Can you see it? Best, Lin On Mon, Apr 6, 2015 at 8:00 PM, David Thompson wrote: > Hi Lin, > > > .. BTW, do you think my presumption which I wrote in the previous email > for the order of storage for P_i is proper? > > Yes, I think the layout you suggested is best because it matches the order > in which VTK's structured point data is stored (since we will probably use > this for storage in some cases). > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From A.Buykx at tnodiana.com Wed Apr 8 04:43:40 2015 From: A.Buykx at tnodiana.com (Andreas Buykx) Date: Wed, 8 Apr 2015 08:43:40 +0000 Subject: [vtk-developers] git minimum version Message-ID: <65D987BE62E58141AA480A59A8B5BBEA6DEB1979@srv-mail.diana.local> Hi, I tried to push my topic branch to gitlab using git gitlab-push and got an error Fetching gitlab master Fetching origin master Pushing to gitlab Unknown option: -c My git version is 1.7.1 and the VTK documentation says the minimum version required is 1.6.6. I don't know exactly in which version the -c option appeared but 1.7.1 is definitely too old. Maybe you'll want to update the VTK Git Usage page? Kind regards, Andreas ____________________________________________________________ TNO DIANA BV is a limited liability company registered in the trade register of the Chamber of Commerce as TNO DIANA BV with registered number 27252655. ____________________________________________________________ This e-mail and its contents are subject to the DISCLAIMER at http://tnodiana.com/content/Disclaimer ____________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Wed Apr 8 08:39:07 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 08 Apr 2015 08:39:07 -0400 Subject: [vtk-developers] git minimum version In-Reply-To: <65D987BE62E58141AA480A59A8B5BBEA6DEB1979@srv-mail.diana.local> References: <65D987BE62E58141AA480A59A8B5BBEA6DEB1979@srv-mail.diana.local> Message-ID: <5525216B.3030209@kitware.com> On 04/08/2015 04:43 AM, Andreas Buykx wrote: > git gitlab-push > Unknown option: -c > > My git version is 1.7.1 and the VTK documentation says the minimum > version required is 1.6.6. That option requires Git 1.7.2. I've updated the docs here: https://gitlab.kitware.com/vtk/vtk/merge_requests/104 Thanks, -Brad From david.lonie at kitware.com Wed Apr 8 09:49:23 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 8 Apr 2015 09:49:23 -0400 Subject: [vtk-developers] coding standards & switch case label accidental fallthrough In-Reply-To: <20150407174902.1250819088@mail.rogue-research.com> References: <20150407163618.1145058309@mail.rogue-research.com> <20150407174902.1250819088@mail.rogue-research.com> Message-ID: +1 for the change. The explicit token is great for readability and will be important as other compilers start warning about these. -1 for forbidding them. A lot of times it just makes the most sense to use a fall through, as long as it's clearly labeled as intentional. On Tue, Apr 7, 2015 at 1:49 PM, Sean McBride wrote: > On Tue, 7 Apr 2015 13:42:51 -0400, David Cole said: > > >Is there really no way to refactor and simply eliminate all the > >"intentional" fall throughs? It's a really nasty style to be allowing. > >It should be discouraged in general. > > I did refactor a few, but most I left because I was scared to touch or > they were pretty elegant with fall-through. You can take a look: > > > I'd be in favour of the coding standards saying something like > "fall-through is discouraged, but when necessary must be annotated with > VTK_FALLTHROUGH". > > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Wed Apr 8 15:00:53 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 8 Apr 2015 15:00:53 -0400 Subject: [vtk-developers] vtkResliceCursorWidget tests In-Reply-To: References: Message-ID: Anyone want to take ownership for these? I don't have time to dig into this issue, and since the tests have been bad for a while (baselines are invalid) I'll just disable the tests if no one is interested in fixing them. On Wed, Apr 1, 2015 at 12:50 PM, David Lonie wrote: > Is anyone familiar with these tests? > > vtkInteractionWidgetsCxx-TestResliceCursorWidget2 > vtkInteractionWidgetsCxx-TestResliceCursorWidget3 > > They're both failing on my GetBounds refactoring branch, and the more I > look, the more it seems like the current baselines are invalid. Here are > the failures: > > https://open.cdash.org/testDetails.php?test=323957914&build=3752775 > https://open.cdash.org/testDetails.php?test=323957866&build=3752775 > > The valid images just show the background with no data for 3 of the > renderers, while the "invalid" images show data and the cursor crosshairs. > > Digging way, way back into the old VTKData repository turns up a third > version -- one with data and crosshairs, but the crosshairs are style > differently (attached). > > I suspect this broke at some point and the bounds refactoring fixed > something along the way. > > Any insights? > > Thanks, > Dave > -------------- next part -------------- An HTML attachment was scrubbed... URL: From e.tadeu at gmail.com Wed Apr 8 15:37:45 2015 From: e.tadeu at gmail.com (E. Tadeu) Date: Wed, 8 Apr 2015 16:37:45 -0300 Subject: [vtk-developers] vtkCaptionActor2D is not scaling the text to fit the rectangle when font size is default or 12 Message-ID: To test it, just create a vtkCaptionActor2D and add it to a renderer. See example here, tested in VTK 6.2: ``` import vtk ren = vtk.vtkRenderer() renWin = vtk.vtkRenderWindow() renWin.AddRenderer(ren) iren = vtk.vtkRenderWindowInteractor() iren.SetRenderWindow(renWin) actor = vtk.vtkCaptionActor2D() actor.SetCaption(u'Hello') # # This makes it work: # actor.GetCaptionTextProperty().SetFontSize(13) # # This also makes it work: # actor.GetCaptionTextProperty().Modified() # # This doesn't make it work: # actor.GetCaptionTextProperty().SetFontSize(12) ren.AddActor(actor) iren.Initialize() iren.Start() ``` I'm having another similar problem related to the font not being scaled the second time it is rendered (after changing the scale), and I think it may be related to this too. Any hint on what may be causing this? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Wed Apr 8 17:42:53 2015 From: majcjc at gmail.com (Lin M) Date: Wed, 8 Apr 2015 17:42:53 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> <54647355-DFD4-489D-A282-1994902CB6E3@kitware.com> <664F50F1-D75E-4F50-97CD-351813F224AE@kitware.com> <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> Message-ID: Hi Dr. Thompson, 1. If I want to submit the PatchIterpolation class, do I need to follow the VTK coding conventions e.g. inheriting from vtkObject, naming with a prefix "vtk"? 2. Where should I put the code, the "Testing" folder? Best, Lin On Tue, Apr 7, 2015 at 9:30 PM, Lin M wrote: > Hi Dr. Thompson, > > I have created a merge request in the gitlab. Can you see it? > > Best, > Lin > > On Mon, Apr 6, 2015 at 8:00 PM, David Thompson > wrote: > >> Hi Lin, >> >> > .. BTW, do you think my presumption which I wrote in the previous email >> for the order of storage for P_i is proper? >> >> Yes, I think the layout you suggested is best because it matches the >> order in which VTK's structured point data is stored (since we will >> probably use this for storage in some cases). >> >> David > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Wed Apr 8 17:59:27 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 9 Apr 2015 07:59:27 +1000 Subject: [vtk-developers] coding standards & switch case label accidental fallthrough Message-ID: Sean, I don't see the need for introducing yet another VTK_ macro for what is a rare and perfectly legal code construct that is picked up as a warning by one compiler type. You are just imposing another constraint on programmers for what is a perfectly legal construct. What warning level are you using? I don't think that I have seen this warning when building VTK. As David Lonie says it does have its uses. Even when looking at Common/DataModel/vtkHyperTreeGrid.cxx in your link below I think it is easier to read and understand without the added macro (line 1108 onwards). Similarly in a few of the other ones e.g. vtkImageMapToColors.cxx, vtkImageInterpolator.cxx that you have there. Having said this I am amazed at the number of missing break statements that you have found. It is a wonder some of this code ever worked! So the warning is good in that respect. On a more general vein I deeply appreciate the effort you have put into cleaning up VTK over the past year or so. The code base is so much better thanks to your efforts. What do others think? Regards Andrew > ---------- Forwarded message ---------- > From: David Lonie > To: Sean McBride > Cc: vtkdev > Date: Wed, 8 Apr 2015 09:49:23 -0400 > Subject: Re: [vtk-developers] coding standards & switch case label > accidental fallthrough > +1 for the change. The explicit token is great for readability and will be > important as other compilers start warning about these. > > -1 for forbidding them. A lot of times it just makes the most sense to use > a fall through, as long as it's clearly labeled as intentional. > > On Tue, Apr 7, 2015 at 1:49 PM, Sean McBride > wrote: > >> On Tue, 7 Apr 2015 13:42:51 -0400, David Cole said: >> >> >Is there really no way to refactor and simply eliminate all the >> >"intentional" fall throughs? It's a really nasty style to be allowing. >> >It should be discouraged in general. >> >> I did refactor a few, but most I left because I was scared to touch or >> they were pretty elegant with fall-through. You can take a look: >> >> >> I'd be in favour of the coding standards saying something like >> "fall-through is discouraged, but when necessary must be annotated with >> VTK_FALLTHROUGH". >> >> 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 >> >> > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Apr 8 18:14:53 2015 From: david.thompson at kitware.com (David Thompson) Date: Wed, 8 Apr 2015 18:14:53 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> <54647355-DFD4-489D-A282-1994902CB6E3@kitware.com> <664F50F1-D75E-4F50-97CD-351813F224AE@kitware.com> <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> Message-ID: Hi Lin, > 1. If I want to submit the PatchIterpolation class, do I need to follow the VTK coding conventions e.g. inheriting from vtkObject, naming with a prefix "vtk"? Before your branch gets merged into VTK, yes. Merging stuff (other than small fixes or modifications to existing classes) into VTK master will probably not happen until the end of the summer when things are tested and stable. I would put it on a separate branch from memoize-factorial so that memoize-factorial can be merged once it's done (it is a small improvement to an existing class). For now, we can continue developing on the new branch. Or, if you prefer, you can create a separate repository on gitlab to hold just the patch/spline classes. > 2. Where should I put the code, the "Testing" folder? I would add a new VTK module to a branch of your VTK fork (or to a new repository). Name the new module Filters/Bezier or Filters/RationalFunctions. You can use Filters/Geometry as a starting point for modules.cmake, CMakeLists.txt, and the files in Testing/Cxx/.... David From sean at rogue-research.com Wed Apr 8 18:25:52 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 8 Apr 2015 18:25:52 -0400 Subject: [vtk-developers] coding standards & switch case label accidental fallthrough In-Reply-To: References: Message-ID: <20150408222552.2043536378@mail.rogue-research.com> On Thu, 9 Apr 2015 07:59:27 +1000, Andrew Maclean said: >I don't see the need for introducing yet another VTK_ macro for what is a >rare and perfectly legal code construct that is picked up as a warning by >one compiler type. > >You are just imposing another constraint on programmers for what is a >perfectly legal construct. > >What warning level are you using? I don't think that I have seen this >warning when building VTK. clang has a neat warning flag called -Weverything, which enables literally every warning it has. Of course many of those warnings we can't/shouldn't/won't fix, but it's a great way to discover warning flags you don't know about. So on one of my bots I pass -Weverything then a slew of -Wno- warnings to disable the many we don't care about. On occasion, I look at removing one of the -Wno- suppressions where it looks worthwhile. Here I'm looking at removing the -Wno-implicit-fallthough suppression. If you're curious about the exact flags I use, here they are: >As David Lonie says it does have its uses. > >Even when looking at Common/DataModel/vtkHyperTreeGrid.cxx in your link >below I think it is easier to read and understand without the added macro >(line 1108 onwards). Similarly in a few of the other ones >e.g. vtkImageMapToColors.cxx, vtkImageInterpolator.cxx that you have there. > >Having said this I am amazed at the number of missing break statements that >you have found. It is a wonder some of this code ever worked! So the >warning is good in that respect. You've just answered your point in your first paragraph. :) I'm not proposing banning fall-through, just proposing an automated way to catch accidental instances of it. If a programmer forgets a 'break', the dashboard can now catch it. If she really meant to have no break, she can shut the compiler up with VTK_FALLTHROUGH. As you probably saw in my merge request, some of the deliberate fall-throughs were at least annotated with a comment, but alas the compiler does not grok comments. The current fall-through warnings are on my torture dashboard: I agree the VTK_FALLTHROUGH macro is a bit ugly, but the current codebase shows we can and do forget 'break' statements. I'm not aware of any other automated way to catch this mistake... FWIW, boost has an equivalent BOOST_FALLTHROUGH macro. >On a more general vein I deeply appreciate the effort you have put into >cleaning up VTK over the past year or so. The code base is so much better >thanks to your efforts. Nice of you to say, thanks! 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 andrew.amaclean at gmail.com Thu Apr 9 00:59:08 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 9 Apr 2015 14:59:08 +1000 Subject: [vtk-developers] coding standards & switch case label accidental fallthrough In-Reply-To: <20150408222552.2043536378@mail.rogue-research.com> References: <20150408222552.2043536378@mail.rogue-research.com> Message-ID: I'm going to try -Weverything on my code to see what horrors it throws up. On Thu, Apr 9, 2015 at 8:25 AM, Sean McBride wrote: > On Thu, 9 Apr 2015 07:59:27 +1000, Andrew Maclean said: > > >I don't see the need for introducing yet another VTK_ macro for what is a > >rare and perfectly legal code construct that is picked up as a warning by > >one compiler type. > > > >You are just imposing another constraint on programmers for what is a > >perfectly legal construct. > > > >What warning level are you using? I don't think that I have seen this > >warning when building VTK. > > clang has a neat warning flag called -Weverything, which enables literally > every warning it has. Of course many of those warnings we > can't/shouldn't/won't fix, but it's a great way to discover warning flags > you don't know about. So on one of my bots I pass -Weverything then a slew > of -Wno- warnings to disable the many we don't care about. > > On occasion, I look at removing one of the -Wno- suppressions where > it looks worthwhile. Here I'm looking at removing the > -Wno-implicit-fallthough suppression. > > If you're curious about the exact flags I use, here they are: > > > >As David Lonie says it does have its uses. > > > >Even when looking at Common/DataModel/vtkHyperTreeGrid.cxx in your link > >below I think it is easier to read and understand without the added macro > >(line 1108 onwards). Similarly in a few of the other ones > >e.g. vtkImageMapToColors.cxx, vtkImageInterpolator.cxx that you have > there. > > > >Having said this I am amazed at the number of missing break statements > that > >you have found. It is a wonder some of this code ever worked! So the > >warning is good in that respect. > > You've just answered your point in your first paragraph. :) > > I'm not proposing banning fall-through, just proposing an automated way to > catch accidental instances of it. > > If a programmer forgets a 'break', the dashboard can now catch it. If she > really meant to have no break, she can shut the compiler up with > VTK_FALLTHROUGH. As you probably saw in my merge request, some of the > deliberate fall-throughs were at least annotated with a comment, but alas > the compiler does not grok comments. > > The current fall-through warnings are on my torture dashboard: > > > I agree the VTK_FALLTHROUGH macro is a bit ugly, but the current codebase > shows we can and do forget 'break' statements. I'm not aware of any other > automated way to catch this mistake... > > FWIW, boost has an equivalent BOOST_FALLTHROUGH macro. > > >On a more general vein I deeply appreciate the effort you have put into > >cleaning up VTK over the past year or so. The code base is so much better > >thanks to your efforts. > > Nice of you to say, thanks! > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Thu Apr 9 08:55:06 2015 From: david.lonie at kitware.com (David Lonie) Date: Thu, 9 Apr 2015 08:55:06 -0400 Subject: [vtk-developers] vtkCaptionActor2D is not scaling the text to fit the rectangle when font size is default or 12 In-Reply-To: References: Message-ID: On Wed, Apr 8, 2015 at 3:37 PM, E. Tadeu wrote: > To test it, just create a vtkCaptionActor2D and add it to a renderer. > > See example here, tested in VTK 6.2: > > ``` > import vtk > > ren = vtk.vtkRenderer() > renWin = vtk.vtkRenderWindow() > renWin.AddRenderer(ren) > iren = vtk.vtkRenderWindowInteractor() > iren.SetRenderWindow(renWin) > > actor = vtk.vtkCaptionActor2D() > actor.SetCaption(u'Hello') > > # # This makes it work: > # actor.GetCaptionTextProperty().SetFontSize(13) > > # # This also makes it work: > # actor.GetCaptionTextProperty().Modified() > > # # This doesn't make it work: > # actor.GetCaptionTextProperty().SetFontSize(12) > > ren.AddActor(actor) > iren.Initialize() > iren.Start() > ``` > > I'm having another similar problem related to the font not being scaled > the second time it is rendered (after changing the scale), and I think it > may be related to this too. > > Any hint on what may be causing this? > It sounds like the logic to check for modifications is missing something. Can you open a bug report for this? Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Thu Apr 9 13:37:00 2015 From: david.thompson at kitware.com (David Thompson) Date: Thu, 9 Apr 2015 13:37:00 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> <54647355-DFD4-489D-A282-1994902CB6E3@kitware.com> <664F50F1-D75E-4F50-97CD-351813F224AE@kitware.com> <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> Message-ID: Hi Lin, > I have created a merge request in the gitlab. Can you see it? The memoization of vtkMath::Factorial() looks good. I have added a "Reviewed-by: me" comment that should give you permission to merge the branch (by adding a "Do: merge" comment to the merge request). When you add the "Do: merge" comment, you are committing to watch the VTK dashboard over the next day to make sure that there are no build or test failures (and to submit a new merge request to address them if some appear). David From majcjc at gmail.com Thu Apr 9 13:53:58 2015 From: majcjc at gmail.com (Lin M) Date: Thu, 9 Apr 2015 13:53:58 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> <54647355-DFD4-489D-A282-1994902CB6E3@kitware.com> <664F50F1-D75E-4F50-97CD-351813F224AE@kitware.com> <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> Message-ID: Hi Dr. Thompson, Thank you! I found that there were test failures from the buildbot. How can I debug them? Best, Lin On Thu, Apr 9, 2015 at 1:37 PM, David Thompson wrote: > Hi Lin, > > > I have created a merge request in the gitlab. Can you see it? > > The memoization of vtkMath::Factorial() looks good. I have added a > "Reviewed-by: me" comment that should give you permission to merge the > branch (by adding a "Do: merge" comment to the merge request). > > When you add the "Do: merge" comment, you are committing to watch the VTK > dashboard over the next day to make sure that there are no build or test > failures (and to submit a new merge request to address them if some appear). > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Thu Apr 9 14:01:13 2015 From: majcjc at gmail.com (Lin M) Date: Thu, 9 Apr 2015 14:01:13 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> <54647355-DFD4-489D-A282-1994902CB6E3@kitware.com> <664F50F1-D75E-4F50-97CD-351813F224AE@kitware.com> <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> Message-ID: I mean some of the outputs doesn't seem to be debuggable. For example one of the test output said: Test output No protocol specified No protocol specified application-specific initialization failed: couldn't connect to display ":40" Error in startup script: can't find package vtk while executing "package require vtk" (file "/home/buildbot/buildbot-slave/vtk-hythloth-linux-shared-release_java_mpi_python_qt_tcl/source/Testing/Rendering/rtImageTest.tcl" line 1) But how can I fix this error? On Thu, Apr 9, 2015 at 1:53 PM, Lin M wrote: > Hi Dr. Thompson, > > Thank you! > I found that there were test failures from the buildbot. How can I debug > them? > > Best, > Lin > > On Thu, Apr 9, 2015 at 1:37 PM, David Thompson > wrote: >> >> Hi Lin, >> >> > I have created a merge request in the gitlab. Can you see it? >> >> The memoization of vtkMath::Factorial() looks good. I have added a >> "Reviewed-by: me" comment that should give you permission to merge the >> branch (by adding a "Do: merge" comment to the merge request). >> >> When you add the "Do: merge" comment, you are committing to watch the VTK >> dashboard over the next day to make sure that there are no build or test >> failures (and to submit a new merge request to address them if some appear). >> >> David > > From shawn.waldon at kitware.com Thu Apr 9 14:13:07 2015 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Thu, 9 Apr 2015 14:13:07 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> <54647355-DFD4-489D-A282-1994902CB6E3@kitware.com> <664F50F1-D75E-4F50-97CD-351813F224AE@kitware.com> <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> Message-ID: Ok, that test was on hythloth, which is an experimental dashboard to begin with (and the issue, fixed about an hour ago was a buildbot configuration problem). You can ignore that one. We are working on moving the buildbot view of tests so that external contributors can see it. The vtk-expected dashboards look fine with your merge request. --Shawn On Thu, Apr 9, 2015 at 2:01 PM, Lin M wrote: > I mean some of the outputs doesn't seem to be debuggable. For example > one of the test output said: > > Test output > > No protocol specified > No protocol specified > application-specific initialization failed: couldn't connect to display > ":40" > Error in startup script: can't find package vtk > while executing > "package require vtk" > (file > "/home/buildbot/buildbot-slave/vtk-hythloth-linux-shared-release_java_mpi_python_qt_tcl/source/Testing/Rendering/rtImageTest.tcl" > line 1) > > But how can I fix this error? > > On Thu, Apr 9, 2015 at 1:53 PM, Lin M wrote: > > Hi Dr. Thompson, > > > > Thank you! > > I found that there were test failures from the buildbot. How can I debug > > them? > > > > Best, > > Lin > > > > On Thu, Apr 9, 2015 at 1:37 PM, David Thompson < > david.thompson at kitware.com> > > wrote: > >> > >> Hi Lin, > >> > >> > I have created a merge request in the gitlab. Can you see it? > >> > >> The memoization of vtkMath::Factorial() looks good. I have added a > >> "Reviewed-by: me" comment that should give you permission to merge the > >> branch (by adding a "Do: merge" comment to the merge request). > >> > >> When you add the "Do: merge" comment, you are committing to watch the > VTK > >> dashboard over the next day to make sure that there are no build or test > >> failures (and to submit a new merge request to address them if some > appear). > >> > >> David > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 majcjc at gmail.com Thu Apr 9 14:29:11 2015 From: majcjc at gmail.com (Lin M) Date: Thu, 9 Apr 2015 14:29:11 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> <54647355-DFD4-489D-A282-1994902CB6E3@kitware.com> <664F50F1-D75E-4F50-97CD-351813F224AE@kitware.com> <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> Message-ID: Hi Shawn, Thank you for your answer. I get it now. :-) Best, Lin On Thu, Apr 9, 2015 at 2:13 PM, Shawn Waldon wrote: > Ok, that test was on hythloth, which is an experimental dashboard to begin > with (and the issue, fixed about an hour ago was a buildbot configuration > problem). You can ignore that one. We are working on moving the buildbot > view of tests so that external contributors can see it. The vtk-expected > dashboards look fine with your merge request. > > --Shawn > > On Thu, Apr 9, 2015 at 2:01 PM, Lin M wrote: >> >> I mean some of the outputs doesn't seem to be debuggable. For example >> one of the test output said: >> >> Test output >> >> No protocol specified >> No protocol specified >> application-specific initialization failed: couldn't connect to display >> ":40" >> Error in startup script: can't find package vtk >> while executing >> "package require vtk" >> (file >> "/home/buildbot/buildbot-slave/vtk-hythloth-linux-shared-release_java_mpi_python_qt_tcl/source/Testing/Rendering/rtImageTest.tcl" >> line 1) >> >> But how can I fix this error? >> >> On Thu, Apr 9, 2015 at 1:53 PM, Lin M wrote: >> > Hi Dr. Thompson, >> > >> > Thank you! >> > I found that there were test failures from the buildbot. How can I debug >> > them? >> > >> > Best, >> > Lin >> > >> > On Thu, Apr 9, 2015 at 1:37 PM, David Thompson >> > >> > wrote: >> >> >> >> Hi Lin, >> >> >> >> > I have created a merge request in the gitlab. Can you see it? >> >> >> >> The memoization of vtkMath::Factorial() looks good. I have added a >> >> "Reviewed-by: me" comment that should give you permission to merge the >> >> branch (by adding a "Do: merge" comment to the merge request). >> >> >> >> When you add the "Do: merge" comment, you are committing to watch the >> >> VTK >> >> dashboard over the next day to make sure that there are no build or >> >> test >> >> failures (and to submit a new merge request to address them if some >> >> appear). >> >> >> >> David >> > >> > >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the 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 liuf_2001 at 163.com Fri Apr 10 22:31:24 2015 From: liuf_2001 at 163.com (lf) Date: Sat, 11 Apr 2015 10:31:24 +0800 (CST) Subject: [vtk-developers] How to assign a specific color to a region during surface reconstruction using vtkDiscreteMarchingCubes Message-ID: <3612158a.2316.14ca651402d.Coremail.liuf_2001@163.com> Hello, everyone, I got a problem when I do surface reconstruction using vtkDiscreteMarchingCubes. Can somebody give me a help? Thank you very much. Fei Liu ----------------- Objective: we want to do surface reconstruction for some segmented CT images. For each segmented image, we have got four differentiated regions: kidney (gray value 220), tumor (gray value 230), vessels (gray value 240), and spine (gray value 250). The left area has a gray value of 0. When we do surface reconstruction for these segmented CT images, we want to get the following result: each of the four regions (kidney, tumor, vesels and spine) is displayed with a different color given by lookuptake. ----------------- Current problem: However, it does not work using the following codes, that is, the selected colors in the lookuptable are not assigned to the four regions. Here are the codes: { vtkSmartPointer append = vtkSmartPointer::New(); //then I put images in append //using vtkDiscreteMarchingCubes for reconstruction vtkSmartPointer dmc = vtkSmartPointer::New(); dmc->SetInputConnection(append->GetOutputPort()); dmc->SetValue(0, 220); dmc->SetValue(1, 230); dmc->SetValue(2, 240); dmc->SetValue(3, 250); dmc->Update(); //optimization vtkSmartPointer deci = vtkSmartPointer::New(); //?????????????????? deci->SetTargetReduction(0.3); deci->SetInputConnection(dmc->GetOutputPort()); vtkSmartPointer smooth = vtkSmartPointer::New(); //??????? smooth->SetInputConnection(deci->GetOutputPort()); smooth->SetNumberOfIterations(200); vtkSmartPointer skinNormals = vtkSmartPointer::New(); //??? skinNormals->SetInputConnection(smooth->GetOutputPort()); skinNormals->SetFeatureAngle(60.0); vtkSmartPointer stripper = vtkSmartPointer::New(); //???????? stripper->SetInputConnection(skinNormals->GetOutputPort()); // Map the scalar values in the image to colors with a lookup table: vtkSmartPointer lookupTable = vtkSmartPointer::New(); lookupTable->SetNumberOfTableValues(4); lookupTable->SetTableValue(0, 0.8900, 0.8100, 0.3400, 1); // Banana lookupTable->SetTableValue(1, 1.0000, 0.3882, 0.2784, 1); // Tomato lookupTable->SetTableValue(2, 0.7400, 0.9900, 0.7900, 1); // Mint lookupTable->SetTableValue(3, 0.2000, 0.6300, 0.7900, 1); // Peacock lookupTable->Build(); //define a new actor and vtkPolyDataMapper mapper vtkSmartPointer mapper = vtkSmartPointer::New(); mapper->SetInputConnection(stripper->GetOutputPort()); mapper->ScalarVisibilityOn(); mapper->SetScalarRange(220, 250); mapper->SetScalarModeToUseCellData(); mapper->SetLookupTable(lookupTable); vtkSmartPointer actor = vtkSmartPointer::New(); actor->SetMapper(mapper); //add actor to a render and display the result m_StaticSurface1.GetvtkRenderer()->AddActor(actor); m_StaticSurface1.GetvtkRenderer()->ResetCamera(); } -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Mon Apr 13 11:45:56 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 13 Apr 2015 11:45:56 -0400 Subject: [vtk-developers] Wiki scrapping regression after web page update In-Reply-To: References: Message-ID: I'll take a look. thanks David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Tue, Mar 31, 2015 at 3:30 PM, Bill Lorensen wrote: > Folks, > > I scrape the vtk.org wiki site each evening to maintain the vtk wiki > examples. I have a python program that uses mwclient > (https://github.com/mwclient/mwclient) that uses the MediaWiki API. > > Ever since the vtk.org page was updated, my nightly scripts have been > failing. > The error are occur on this line: > > site = mwclient.Site('vtk.org', '/Wiki/') > > If I change vtk.org to itk.org, my scripts work. > > I suspect some sort of web magic going on. I can workaround the > problem but specifying itk.org, but I'd like to understand what > happened just in case the itk.org site changes in the future. > > Thanks, > > 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 joachim.pouderoux at kitware.com Tue Apr 14 09:26:53 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Tue, 14 Apr 2015 15:26:53 +0200 Subject: [vtk-developers] Ghost and Blanking (Visibility) Changes In-Reply-To: References: Message-ID: Thanks, this is good to now. Question: the new architecture does not provide information about ghost level anymore. Is this information useless in general and was never used by any vtk filter? Beside that , the change of VTK XML file version induced by this change can be a problem: I use to generate PVTP/PTVU files on a project I generally link with the latest VTK. I use to visualize the obtained dataset with ParaView. However, since this change, I am not able to open any of those VTK XML files with PV <=4.3.1. To do so I have to manually edit the files and reverse the version tag from 2 to 1... My dataset have no blanking or ghost cells, thus may be one could only specify version 2 in the data writer if the data *really *contains information that a previous version of the reader could not read? Best, Joachim *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2015-04-02 16:54 GMT+02:00 Dan Lipsa : > > Dear VTK and ParaView developers, > We would like to draw your attention to the following updates to > VTK/ParaView that change the way one interfaces to Ghost and Blanking cells > and points. > > These changes have just been merged into master repositories for > VTK/ParaView. > > http://www.kitware.com/blog/home/post/856 > > We welcome suggestions and/or bug reports on these changes. > > Best regards, > Dan > > > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 berk.geveci at kitware.com Tue Apr 14 09:31:33 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 14 Apr 2015 09:31:33 -0400 Subject: [vtk-developers] Ghost and Blanking (Visibility) Changes In-Reply-To: References: Message-ID: > Question: the new architecture does not provide information about ghost level anymore. Is this information useless in > general and was never used by any vtk filter? The ghost level information was only used to strip a particular ghost level, something that was done in the filters. Since we no longer expect filters to strip ghost levels (this is done before the mapper), the levels are no longer needed. > I use to generate PVTP/PTVU files on a project I generally link with the latest VTK. I use to visualize the obtained dataset with ParaView. However, since this change, I am not able to open any of those VTK XML files with PV <=4.3.1. To do so I have to manually edit the files and reverse the version tag from 2 to 1... My dataset have no blanking or ghost cells, thus may be one could only specify version 2 in the data writer if the data *really *contains information that a previous version of the reader could not read? This is a great idea. Dan: if it is not too hard to do, please do this. -berk On Tue, Apr 14, 2015 at 9:26 AM, Joachim Pouderoux < joachim.pouderoux at kitware.com> wrote: > Thanks, this is good to now. > Question: the new architecture does not provide information about ghost > level anymore. Is this information useless in general and was never used by > any vtk filter? > > Beside that , the change of VTK XML file version induced by this change > can be a problem: > I use to generate PVTP/PTVU files on a project I generally link with the > latest VTK. I use to visualize the obtained dataset with ParaView. However, > since this change, I am not able to open any of those VTK XML files with PV > <=4.3.1. To do so I have to manually edit the files and reverse the version > tag from 2 to 1... My dataset have no blanking or ghost cells, thus may be > one could only specify version 2 in the data writer if the data *really *contains > information that a previous version of the reader could not read? > > Best, > Joachim > > *Joachim Pouderoux* > > *PhD, Technical Expert* > *Kitware SAS * > > > 2015-04-02 16:54 GMT+02:00 Dan Lipsa : > >> >> Dear VTK and ParaView developers, >> We would like to draw your attention to the following updates to >> VTK/ParaView that change the way one interfaces to Ghost and Blanking cells >> and points. >> >> These changes have just been merged into master repositories for >> VTK/ParaView. >> >> http://www.kitware.com/blog/home/post/856 >> >> We welcome suggestions and/or bug reports on these changes. >> >> Best regards, >> Dan >> >> >> >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the 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 dan.lipsa at kitware.com Tue Apr 14 10:06:56 2015 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Tue, 14 Apr 2015 10:06:56 -0400 Subject: [vtk-developers] Ghost and Blanking (Visibility) Changes In-Reply-To: References: Message-ID: > > > > > I use to generate PVTP/PTVU files on a project I generally link with the > latest VTK. I use to visualize the obtained dataset with ParaView. However, > since this change, I am not able to open any of those VTK XML files with PV > <=4.3.1. To do so I have to manually edit the files and reverse the version > tag from 2 to 1... My dataset have no blanking or ghost cells, thus may be > one could only specify version 2 in the data writer if the data *really *contains > information that a previous version of the reader could not read? > > This is a great idea. Dan: if it is not too hard to do, please do this. > I'll take a look a this. Maybe we should change the readers to only issue a warning if the file version is newer than the reader. It should not be a problem for old readers to read new files at least in this case - the only thing that happens is that ghost levels and blanking are not read correctly - this may not matter in certain cases. Dan > > -berk > > On Tue, Apr 14, 2015 at 9:26 AM, Joachim Pouderoux < > joachim.pouderoux at kitware.com> wrote: > >> Thanks, this is good to now. >> Question: the new architecture does not provide information about ghost >> level anymore. Is this information useless in general and was never used by >> any vtk filter? >> >> Beside that , the change of VTK XML file version induced by this change >> can be a problem: >> I use to generate PVTP/PTVU files on a project I generally link with the >> latest VTK. I use to visualize the obtained dataset with ParaView. However, >> since this change, I am not able to open any of those VTK XML files with PV >> <=4.3.1. To do so I have to manually edit the files and reverse the version >> tag from 2 to 1... My dataset have no blanking or ghost cells, thus may be >> one could only specify version 2 in the data writer if the data *really *contains >> information that a previous version of the reader could not read? >> >> Best, >> Joachim >> >> *Joachim Pouderoux* >> >> *PhD, Technical Expert* >> *Kitware SAS * >> >> >> 2015-04-02 16:54 GMT+02:00 Dan Lipsa : >> >>> >>> Dear VTK and ParaView developers, >>> We would like to draw your attention to the following updates to >>> VTK/ParaView that change the way one interfaces to Ghost and Blanking cells >>> and points. >>> >>> These changes have just been merged into master repositories for >>> VTK/ParaView. >>> >>> http://www.kitware.com/blog/home/post/856 >>> >>> We welcome suggestions and/or bug reports on these changes. >>> >>> Best regards, >>> Dan >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the 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 joachim.pouderoux at kitware.com Tue Apr 14 10:58:21 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Tue, 14 Apr 2015 16:58:21 +0200 Subject: [vtk-developers] Ghost and Blanking (Visibility) Changes In-Reply-To: References: Message-ID: The problem is that we cannot change the behaviour of old code (the one available in PV <= 4.3.1) so to make them work (as they just refuse to read files with a version > 1) we have to change the actual writer. *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2015-04-14 16:06 GMT+02:00 Dan Lipsa : > >> >> > I use to generate PVTP/PTVU files on a project I generally link with >> the latest VTK. I use to visualize the obtained dataset with ParaView. >> However, since this change, I am not able to open any of those VTK XML >> files with PV <=4.3.1. To do so I have to manually edit the files and >> reverse the version tag from 2 to 1... My dataset have no blanking or ghost >> cells, thus may be one could only specify version 2 in the data writer if >> the data *really *contains information that a previous version of the >> reader could not read? >> >> This is a great idea. Dan: if it is not too hard to do, please do this. >> > > I'll take a look a this. Maybe we should change the readers to only issue > a warning if the file version is newer than the reader. It should not be a > problem for old readers to read new files at least in this case - the only > thing that happens is that ghost levels and blanking are not read correctly > - this may not matter in certain cases. > > Dan > > > > > > >> >> -berk >> >> On Tue, Apr 14, 2015 at 9:26 AM, Joachim Pouderoux < >> joachim.pouderoux at kitware.com> wrote: >> >>> Thanks, this is good to now. >>> Question: the new architecture does not provide information about ghost >>> level anymore. Is this information useless in general and was never used by >>> any vtk filter? >>> >>> Beside that , the change of VTK XML file version induced by this change >>> can be a problem: >>> I use to generate PVTP/PTVU files on a project I generally link with the >>> latest VTK. I use to visualize the obtained dataset with ParaView. However, >>> since this change, I am not able to open any of those VTK XML files with PV >>> <=4.3.1. To do so I have to manually edit the files and reverse the version >>> tag from 2 to 1... My dataset have no blanking or ghost cells, thus may be >>> one could only specify version 2 in the data writer if the data *really >>> *contains information that a previous version of the reader could not >>> read? >>> >>> Best, >>> Joachim >>> >>> *Joachim Pouderoux* >>> >>> *PhD, Technical Expert* >>> *Kitware SAS * >>> >>> >>> 2015-04-02 16:54 GMT+02:00 Dan Lipsa : >>> >>>> >>>> Dear VTK and ParaView developers, >>>> We would like to draw your attention to the following updates to >>>> VTK/ParaView that change the way one interfaces to Ghost and Blanking cells >>>> and points. >>>> >>>> These changes have just been merged into master repositories for >>>> VTK/ParaView. >>>> >>>> http://www.kitware.com/blog/home/post/856 >>>> >>>> We welcome suggestions and/or bug reports on these changes. >>>> >>>> Best regards, >>>> Dan >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> Powered by www.kitware.com >>>> >>>> Visit other Kitware open-source projects at >>>> http://www.kitware.com/opensource/opensource.html >>>> >>>> Search the 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 dan.lipsa at kitware.com Tue Apr 14 11:03:51 2015 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Tue, 14 Apr 2015 11:03:51 -0400 Subject: [vtk-developers] Ghost and Blanking (Visibility) Changes In-Reply-To: References: Message-ID: On Tue, Apr 14, 2015 at 10:58 AM, Joachim Pouderoux < joachim.pouderoux at kitware.com> wrote: > The problem is that we cannot change the behaviour of old code (the one > available in PV <= 4.3.1) so to make them work (as they just refuse to read > files with a version > 1) we have to change the actual writer. > Indeed. I will change the writer. -------------- next part -------------- An HTML attachment was scrubbed... URL: From karasevpa at gmail.com Tue Apr 14 11:18:21 2015 From: karasevpa at gmail.com (Peter Karasev) Date: Tue, 14 Apr 2015 08:18:21 -0700 Subject: [vtk-developers] RFC: Compiler support, removing hacks for old compilers In-Reply-To: <20150316192715.GA23180@megas.kitwarein.com> References: <20150316180926.1146005295@mail.rogue-research.com> <20150316192715.GA23180@megas.kitwarein.com> Message-ID: gcc 4.7.2 and VS2012 have pretty good support for it. I've been using C++11 extensively the past year or so; it makes a huge difference for enabling decoupling of modules, simplified syntax, and easy memory management. decoupling: std::function is easier to understand and more generally applicable than VTK Observers. easy memory management: std::unique_ptr, std::shared_ptr, std::weak_ptr are straightforward to use and don't have the limitation of requiring a vtkObject base class. On Mon, Mar 16, 2015 at 12:27 PM, Ben Boeckel wrote: > On Mon, Mar 16, 2015 at 14:09:26 -0400, Sean McBride wrote: > > The motivation being: > > - reduce cruft in the codebase > > - allow use of newer language features (C++11 eventually) > > FWIW, using C++11 support would bump to gcc 4.8 and VS2013 for > (practical) purposes (gcc 4.4 and VS2010 have rudimentary support for > it, but nothing I would rely on). > > > Thoughts? > > +1. > > --Ben > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- _______________ Peter Karasev karasevpa at gmail.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Tue Apr 14 17:15:09 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Tue, 14 Apr 2015 17:15:09 -0400 Subject: [vtk-developers] [HEADSUP] Buildbot host changing Message-ID: <20150414211509.GA23965@megas.kitware.com> Hi all, We are moving the buildbot host to another machine. While this is happening, builds and their results may be interrupted until the new host is active. The plan is to do this early tomorrow (Wednesday) morning (probably around 9am). Things should be back to normal within an hour after the migration has started. Thanks, --Ben From sean at rogue-research.com Tue Apr 14 19:08:49 2015 From: sean at rogue-research.com (Sean McBride) Date: Tue, 14 Apr 2015 19:08:49 -0400 Subject: [vtk-developers] coding standards & switch case label accidental fallthrough In-Reply-To: References: Message-ID: <20150414230849.707192139@mail.rogue-research.com> On Thu, 9 Apr 2015 07:59:27 +1000, Andrew Maclean said: >I don't see the need for introducing yet another VTK_ macro for what is a >rare and perfectly legal code construct that is picked up as a warning by >one compiler type. > >You are just imposing another constraint on programmers for what is a >perfectly legal construct. > >What warning level are you using? I don't think that I have seen this >warning when building VTK. > >As David Lonie says it does have its uses. > >Even when looking at Common/DataModel/vtkHyperTreeGrid.cxx in your link >below I think it is easier to read and understand without the added macro >(line 1108 onwards). Similarly in a few of the other ones >e.g. vtkImageMapToColors.cxx, vtkImageInterpolator.cxx that you have there. > >Having said this I am amazed at the number of missing break statements that >you have found. It is a wonder some of this code ever worked! So the >warning is good in that respect. > >What do others think? Andrew, As the only one that half-objected, do you -2 the change? Otherwise, I'll merge it tomorrow... 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 ben.boeckel at kitware.com Wed Apr 15 10:13:51 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 15 Apr 2015 10:13:51 -0400 Subject: [vtk-developers] [HEADSUP] Buildbot host changing In-Reply-To: <20150414211509.GA23965@megas.kitware.com> References: <20150414211509.GA23965@megas.kitware.com> Message-ID: <20150415141351.GA24308@megas.kitware.com> On Tue, Apr 14, 2015 at 17:15:09 -0400, Ben Boeckel wrote: > We are moving the buildbot host to another machine. While this is > happening, builds and their results may be interrupted until the new > host is active. The plan is to do this early tomorrow (Wednesday) > morning (probably around 9am). Things should be back to normal within an > hour after the migration has started. The move is complete. Some builds may show up as duplicated on CDash due to the move restarting builds. Thanks, --Ben From bill.lorensen at gmail.com Wed Apr 15 15:27:03 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 15 Apr 2015 15:27:03 -0400 Subject: [vtk-developers] Approving a gitlab topic Message-ID: To approve a gitlab topic I do? Acked-by: me Why not? Approved-by: me The latter seems more descriptive. I currently contribute to 3 open source projects, vtk(gitlab), itk(gerrit) and slicer(github). They each have their own workflow. I also have several of my own projects that uses github. I contribute to these projects in spurts. Bill From robert.maynard at kitware.com Wed Apr 15 15:48:43 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 15 Apr 2015 15:48:43 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: References: Message-ID: Hi Bill, I was discussing this with other developers a few days ago and mentioned that the Acked-by/etc are hard to remember and proposed that we allow +1 to mean approved by a developer, and +2 to mean approved and tested. On Wed, Apr 15, 2015 at 3:27 PM, Bill Lorensen wrote: > To approve a gitlab topic I do? > > Acked-by: me > > Why not? > > Approved-by: me > > The latter seems more descriptive. > > I currently contribute to 3 open source projects, vtk(gitlab), > itk(gerrit) and slicer(github). They each have their own workflow. I > also have several of my own projects that uses github. I contribute to > these projects in spurts. > > 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 > From utkarsh.ayachit at kitware.com Wed Apr 15 15:55:54 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Wed, 15 Apr 2015 15:55:54 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: References: Message-ID: > I was discussing this with other developers a few days ago and > mentioned that the Acked-by/etc are hard to remember and proposed that > we allow +1 to mean approved by a developer, and +2 to mean approved > and tested. +1. From brad.king at kitware.com Wed Apr 15 16:03:31 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 15 Apr 2015 16:03:31 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: References: Message-ID: <552EC413.4010504@kitware.com> On 04/15/2015 03:55 PM, Utkarsh Ayachit wrote: >> I was discussing this with other developers a few days ago and >> mentioned that the Acked-by/etc are hard to remember and proposed that >> we allow +1 to mean approved by a developer, and +2 to mean approved >> and tested. > > +1. Ben and I already have changes in progress for this. -Brad From bill.lorensen at gmail.com Wed Apr 15 16:03:57 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 15 Apr 2015 16:03:57 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: References: Message-ID: +2 On Wed, Apr 15, 2015 at 3:55 PM, Utkarsh Ayachit wrote: >> I was discussing this with other developers a few days ago and >> mentioned that the Acked-by/etc are hard to remember and proposed that >> we allow +1 to mean approved by a developer, and +2 to mean approved >> and tested. > > +1. -- Unpaid intern in BillsBasement at noware dot com From robert.maynard at kitware.com Wed Apr 15 16:06:18 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 15 Apr 2015 16:06:18 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: <552EC413.4010504@kitware.com> References: <552EC413.4010504@kitware.com> Message-ID: Great to hear! Thank you Brad and Ben. On Wed, Apr 15, 2015 at 4:03 PM, Brad King wrote: > On 04/15/2015 03:55 PM, Utkarsh Ayachit wrote: >>> I was discussing this with other developers a few days ago and >>> mentioned that the Acked-by/etc are hard to remember and proposed that >>> we allow +1 to mean approved by a developer, and +2 to mean approved >>> and tested. >> >> +1. > > Ben and I already have changes in progress for this. > > -Brad > From ben.boeckel at kitware.com Wed Apr 15 16:14:53 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Wed, 15 Apr 2015 16:14:53 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: References: Message-ID: <20150415201453.GB22233@megas.kitware.com> On Wed, Apr 15, 2015 at 15:48:43 -0400, Robert Maynard wrote: > I was discussing this with other developers a few days ago and > mentioned that the Acked-by/etc are hard to remember and proposed that > we allow +1 to mean approved by a developer, and +2 to mean approved > and tested. Patch is in an MR for kwrobot actually; needs a bit of testing and docs. +1 is equivalent to Acked-by, +2 Reviewed-by, and +3 Tested-by. Also, "Acked-by" is from projects like the kernel and git which also use Acked-by, Reviewed-by, and Tested-by. from git's Documentation/SubmittingPatches: ======= If you like, you can put extra tags at the end: 1. "Reported-by:" is used to credit someone who found the bug that the patch attempts to fix. 2. "Acked-by:" says that the person who is more familiar with the area the patch attempts to modify liked the patch. 3. "Reviewed-by:", unlike the other tags, can only be offered by the reviewer and means that she is completely satisfied that the patch is ready for application. It is usually offered only after a detailed review. 4. "Tested-by:" is used to indicate that the person applied the patch and found it to have the desired effect. ======= --Ben From sean at rogue-research.com Wed Apr 15 16:15:12 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 15 Apr 2015 16:15:12 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: References: Message-ID: <20150415201512.16658483@mail.rogue-research.com> Even that is hard to remember (though better). Would it not be possible to put buttons with names like "Approved" and "Approved & Tested". Then one has nothing to remember. Sean On Wed, 15 Apr 2015 15:48:43 -0400, Robert Maynard said: >Hi Bill, > >I was discussing this with other developers a few days ago and >mentioned that the Acked-by/etc are hard to remember and proposed that >we allow +1 to mean approved by a developer, and +2 to mean approved >and tested. > >On Wed, Apr 15, 2015 at 3:27 PM, Bill Lorensen >wrote: >> To approve a gitlab topic I do? >> >> Acked-by: me >> >> Why not? >> >> Approved-by: me >> >> The latter seems more descriptive. >> >> I currently contribute to 3 open source projects, vtk(gitlab), >> itk(gerrit) and slicer(github). They each have their own workflow. I >> also have several of my own projects that uses github. I contribute to >> these projects in spurts. From bill.lorensen at gmail.com Wed Apr 15 16:20:01 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 15 Apr 2015 16:20:01 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: <20150415201512.16658483@mail.rogue-research.com> References: <20150415201512.16658483@mail.rogue-research.com> Message-ID: Buttons are great. No need to remember the quirks of the process. On Wed, Apr 15, 2015 at 4:15 PM, Sean McBride wrote: > Even that is hard to remember (though better). Would it not be possible to put buttons with names like "Approved" and "Approved & Tested". Then one has nothing to remember. > > Sean > > > > On Wed, 15 Apr 2015 15:48:43 -0400, Robert Maynard said: > >>Hi Bill, >> >>I was discussing this with other developers a few days ago and >>mentioned that the Acked-by/etc are hard to remember and proposed that >>we allow +1 to mean approved by a developer, and +2 to mean approved >>and tested. >> >>On Wed, Apr 15, 2015 at 3:27 PM, Bill Lorensen >>wrote: >>> To approve a gitlab topic I do? >>> >>> Acked-by: me >>> >>> Why not? >>> >>> Approved-by: me >>> >>> The latter seems more descriptive. >>> >>> I currently contribute to 3 open source projects, vtk(gitlab), >>> itk(gerrit) and slicer(github). They each have their own workflow. I >>> also have several of my own projects that uses github. I contribute to >>> these projects in spurts. > > -- Unpaid intern in BillsBasement at noware dot com From dave.demarle at kitware.com Wed Apr 15 16:28:06 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 15 Apr 2015 16:28:06 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: References: <20150415201512.16658483@mail.rogue-research.com> Message-ID: "+1 and +2" are familiar to all of us since we learned them all (after a while) from gerrit. We should continue to strive to make it easy on newbies too. +1 for buttons David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Apr 15, 2015 at 4:20 PM, Bill Lorensen wrote: > Buttons are great. No need to remember the quirks of the process. > > > On Wed, Apr 15, 2015 at 4:15 PM, Sean McBride > wrote: > > Even that is hard to remember (though better). Would it not be possible > to put buttons with names like "Approved" and "Approved & Tested". Then > one has nothing to remember. > > > > Sean > > > > > > > > On Wed, 15 Apr 2015 15:48:43 -0400, Robert Maynard said: > > > >>Hi Bill, > >> > >>I was discussing this with other developers a few days ago and > >>mentioned that the Acked-by/etc are hard to remember and proposed that > >>we allow +1 to mean approved by a developer, and +2 to mean approved > >>and tested. > >> > >>On Wed, Apr 15, 2015 at 3:27 PM, Bill Lorensen > >>wrote: > >>> To approve a gitlab topic I do? > >>> > >>> Acked-by: me > >>> > >>> Why not? > >>> > >>> Approved-by: me > >>> > >>> The latter seems more descriptive. > >>> > >>> I currently contribute to 3 open source projects, vtk(gitlab), > >>> itk(gerrit) and slicer(github). They each have their own workflow. I > >>> also have several of my own projects that uses github. I contribute to > >>> these projects in spurts. > > > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed Apr 15 17:06:02 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 15 Apr 2015 17:06:02 -0400 Subject: [vtk-developers] VTK Wiki Examples migrating to gitlab Message-ID: Folks, The VTK WIki Examples code repo has been hosted on gitorious.org since the beginning. gitlab.com has purchased gitorious and will kill the site in the near future. In the next couple of weeks, I'll move the wiki examples to gitlab.com. I don't expect any problems, but a few hiccups may occur with web links. The gitorious site has always been flaky. I hope gitlab will be more robust! I'll keep you posted, Bill] From bill.lorensen at gmail.com Wed Apr 15 17:09:47 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 15 Apr 2015 17:09:47 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: References: <20150415201512.16658483@mail.rogue-research.com> Message-ID: Also, how to block a commit. gerrit used a numbering system: -2 ? do not commit -1 ? prefer you do not commit On Wed, Apr 15, 2015 at 4:28 PM, David E DeMarle wrote: > "+1 and +2" are familiar to all of us since we learned them all (after a > while) from gerrit. We should continue to strive to make it easy on newbies > too. > > +1 for buttons > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Wed, Apr 15, 2015 at 4:20 PM, Bill Lorensen > wrote: >> >> Buttons are great. No need to remember the quirks of the process. >> >> >> On Wed, Apr 15, 2015 at 4:15 PM, Sean McBride >> wrote: >> > Even that is hard to remember (though better). Would it not be possible >> > to put buttons with names like "Approved" and "Approved & Tested". Then one >> > has nothing to remember. >> > >> > Sean >> > >> > >> > >> > On Wed, 15 Apr 2015 15:48:43 -0400, Robert Maynard said: >> > >> >>Hi Bill, >> >> >> >>I was discussing this with other developers a few days ago and >> >>mentioned that the Acked-by/etc are hard to remember and proposed that >> >>we allow +1 to mean approved by a developer, and +2 to mean approved >> >>and tested. >> >> >> >>On Wed, Apr 15, 2015 at 3:27 PM, Bill Lorensen >> >>wrote: >> >>> To approve a gitlab topic I do? >> >>> >> >>> Acked-by: me >> >>> >> >>> Why not? >> >>> >> >>> Approved-by: me >> >>> >> >>> The latter seems more descriptive. >> >>> >> >>> I currently contribute to 3 open source projects, vtk(gitlab), >> >>> itk(gerrit) and slicer(github). They each have their own workflow. I >> >>> also have several of my own projects that uses github. I contribute to >> >>> these projects in spurts. >> > >> > >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Wed Apr 15 18:32:33 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 15 Apr 2015 18:32:33 -0400 Subject: [vtk-developers] [vtkusers] VTK Wiki Examples migrating to gitlab In-Reply-To: References: Message-ID: Why not move it to gitlab.kitware.com? You can easily create a repo there. Or even better, someone can create a repo under the VTK group so the examples repo would be a sibling of the VTK repo... On Wed, Apr 15, 2015 at 5:06 PM, Bill Lorensen wrote: > Folks, > > The VTK WIki Examples code repo has been hosted on gitorious.org since > the beginning. gitlab.com has purchased gitorious and will kill the > site in the near future. In the next couple of weeks, I'll move the > wiki examples to gitlab.com. I don't expect any problems, but a few > hiccups may occur with web links. The gitorious site has always been > flaky. I hope gitlab will be more robust! > > I'll keep you posted, > > Bill] > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Wed Apr 15 20:07:23 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 15 Apr 2015 20:07:23 -0400 Subject: [vtk-developers] [vtkusers] VTK Wiki Examples migrating to gitlab In-Reply-To: References: Message-ID: Will do. On Apr 15, 2015 6:33 PM, "Berk Geveci" wrote: > Why not move it to gitlab.kitware.com? You can easily create a repo > there. Or even better, someone can create a repo under the VTK group so the > examples repo would be a sibling of the VTK repo... > > On Wed, Apr 15, 2015 at 5:06 PM, Bill Lorensen > wrote: > >> Folks, >> >> The VTK WIki Examples code repo has been hosted on gitorious.org since >> the beginning. gitlab.com has purchased gitorious and will kill the >> site in the near future. In the next couple of weeks, I'll move the >> wiki examples to gitlab.com. I don't expect any problems, but a few >> hiccups may occur with web links. The gitorious site has always been >> flaky. I hope gitlab will be more robust! >> >> I'll keep you posted, >> >> Bill] >> _______________________________________________ >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Apr 15 22:20:04 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 15 Apr 2015 22:20:04 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: References: <20150415201512.16658483@mail.rogue-research.com> Message-ID: Buttons, labelled "Approve" and "Reject" Not to be overly pedantic, but buttons should indicate the action you are doing by clicking them, not the action you did once they have been clicked. (i.e. -- make it an action verb, not a past tense "did that" thing...) +2 for buttons! On Wed, Apr 15, 2015 at 5:09 PM, Bill Lorensen wrote: > Also, > > how to block a commit. gerrit used a numbering system: > > -2 ? do not commit > -1 ? prefer you do not commit > > > > > On Wed, Apr 15, 2015 at 4:28 PM, David E DeMarle > wrote: >> "+1 and +2" are familiar to all of us since we learned them all (after a >> while) from gerrit. We should continue to strive to make it easy on newbies >> too. >> >> +1 for buttons >> >> David E DeMarle >> Kitware, Inc. >> R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4909 >> >> On Wed, Apr 15, 2015 at 4:20 PM, Bill Lorensen >> wrote: >>> >>> Buttons are great. No need to remember the quirks of the process. >>> >>> >>> On Wed, Apr 15, 2015 at 4:15 PM, Sean McBride >>> wrote: >>> > Even that is hard to remember (though better). Would it not be possible >>> > to put buttons with names like "Approved" and "Approved & Tested". Then one >>> > has nothing to remember. >>> > >>> > Sean >>> > >>> > >>> > >>> > On Wed, 15 Apr 2015 15:48:43 -0400, Robert Maynard said: >>> > >>> >>Hi Bill, >>> >> >>> >>I was discussing this with other developers a few days ago and >>> >>mentioned that the Acked-by/etc are hard to remember and proposed that >>> >>we allow +1 to mean approved by a developer, and +2 to mean approved >>> >>and tested. >>> >> >>> >>On Wed, Apr 15, 2015 at 3:27 PM, Bill Lorensen >>> >>wrote: >>> >>> To approve a gitlab topic I do? >>> >>> >>> >>> Acked-by: me >>> >>> >>> >>> Why not? >>> >>> >>> >>> Approved-by: me >>> >>> >>> >>> The latter seems more descriptive. >>> >>> >>> >>> I currently contribute to 3 open source projects, vtk(gitlab), >>> >>> itk(gerrit) and slicer(github). They each have their own workflow. I >>> >>> also have several of my own projects that uses github. I contribute to >>> >>> these projects in spurts. >>> > >>> > >>> >>> >>> >>> -- >>> Unpaid intern in BillsBasement at noware dot com >>> _______________________________________________ >>> Powered by www.kitware.com >>> >>> Visit other Kitware open-source projects at >>> http://www.kitware.com/opensource/opensource.html >>> >>> Search the list archives at: http://markmail.org/search/?q=vtk-developers >>> >>> Follow this link to subscribe/unsubscribe: >>> http://public.kitware.com/mailman/listinfo/vtk-developers >>> >> > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From marcus.hanwell at kitware.com Thu Apr 16 10:28:34 2015 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Thu, 16 Apr 2015 10:28:34 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: References: Message-ID: +2 On Wed, Apr 15, 2015 at 4:03 PM, Bill Lorensen wrote: > +2 > > > On Wed, Apr 15, 2015 at 3:55 PM, Utkarsh Ayachit > wrote: >>> I was discussing this with other developers a few days ago and >>> mentioned that the Acked-by/etc are hard to remember and proposed that >>> we allow +1 to mean approved by a developer, and +2 to mean approved >>> and tested. >> >> +1. > > > > -- > 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 brad.king at kitware.com Thu Apr 16 10:46:01 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 16 Apr 2015 10:46:01 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: <552EC413.4010504@kitware.com> References: <552EC413.4010504@kitware.com> Message-ID: <552FCB29.9050102@kitware.com> On 04/15/2015 04:03 PM, Brad King wrote: > Ben and I already have changes in progress for this. The infrastructure for interpreting -1,+1,+2,+3 votes has been deployed. See MR here for documentation updates: https://gitlab.kitware.com/vtk/vtk/merge_requests/121 Note that we don't actually enforce anything at merge time yet, but the +[123] votes are scraped for the merge message. -Brad From brad.king at kitware.com Thu Apr 16 10:47:34 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 16 Apr 2015 10:47:34 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: References: <20150415201512.16658483@mail.rogue-research.com> Message-ID: <552FCB86.6090000@kitware.com> On 04/15/2015 10:20 PM, David Cole via vtk-developers wrote: > Buttons, labelled "Approve" and "Reject" > > Not to be overly pedantic, but buttons should indicate the action you > are doing by clicking them, not the action you did once they have been > clicked. (i.e. -- make it an action verb, not a past tense "did that" > thing...) > > +2 for buttons! Adding buttons will require modification to GitLab, which we've ruled must be kept to a minimum. We already have a few mods in use to get the event web hooks we need. Only after we've gotten those upstreamed successfully should we consider further mods locally. We don't want to end up forked like we did with Gerrit. -Brad From bill.lorensen at gmail.com Thu Apr 16 11:00:21 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 16 Apr 2015 11:00:21 -0400 Subject: [vtk-developers] [vtkusers] VTK Wiki Examples migrating to gitlab In-Reply-To: References: Message-ID: Berk, I have decided to use github. That is where the itk wiki examples reside. Also, I don't need all of the extra stuff that gitlab provides. Most commits to the examples' repo's are automated through scripting. Bill On Wed, Apr 15, 2015 at 8:07 PM, Bill Lorensen wrote: > Will do. > > On Apr 15, 2015 6:33 PM, "Berk Geveci" wrote: >> >> Why not move it to gitlab.kitware.com? You can easily create a repo there. >> Or even better, someone can create a repo under the VTK group so the >> examples repo would be a sibling of the VTK repo... >> >> On Wed, Apr 15, 2015 at 5:06 PM, Bill Lorensen >> wrote: >>> >>> Folks, >>> >>> The VTK WIki Examples code repo has been hosted on gitorious.org since >>> the beginning. gitlab.com has purchased gitorious and will kill the >>> site in the near future. In the next couple of weeks, I'll move the >>> wiki examples to gitlab.com. I don't expect any problems, but a few >>> hiccups may occur with web links. The gitorious site has always been >>> flaky. I hope gitlab will be more robust! >>> >>> I'll keep you posted, >>> >>> Bill] >>> _______________________________________________ >>> 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 >> >> > -- Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Thu Apr 16 12:29:53 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 16 Apr 2015 12:29:53 -0400 Subject: [vtk-developers] material files patch for vtkOBJReader In-Reply-To: References: Message-ID: Berk, Peter has done an excellent job creating the OBJImporter. He has been very responsive to suggestions. Although there may be some minor cleanup necessary, I think his gitlab topic is ready to merge. However, he does not have permission to do the merge. I suggest he be added to the approved developer list. Bill https://gitlab.kitware.com/vtk/vtk/merge_requests/26 On Mon, Dec 22, 2014 at 2:44 PM, Berk Geveci wrote: > My preference would be to develop a new OBJ importer that uses the OBJ > reader. Making the OBJ reader depend on rendering may impact some folks > negatively. By the way, I would defer this for a few months if possible. We > have a project targeted towards importing material properties for ray > tracing etc. I don't think that we will follow the importer route and we > will probably develop a new infrastructure. It may fit better here. > > Best, > -berk > > On Mon, Dec 22, 2014 at 12:32 PM, Peter Karasev wrote: >> >> Hi, >> >> I'm hoping to get an update for vtkOBJReader integrated in that >> enables reading material-texture-library (.mtl) files. These are typically >> distributed along with the .obj file that contains geometry data. >> >> There's an issue with the module structure of VTK in doing this, >> however: having the MTL file means that you basically must generate not only >> geometry but the entire actors with vtkProperty*'s set on them. >> >> I propose moving vtkOBJReader into the same area as vtk3DSImporter, >> where it is allowed to access things in vtkRenderingCore like vtkActor >> class. Alternatively, a dependency(ies) could be added to vtkIOGeometry to >> allow creating actors. Any views on which way to go here? >> >> -- >> >> _______________ >> Peter Karasev >> karasevpa at gmail.com >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Unpaid intern in BillsBasement at noware dot com From jchris.fillionr at kitware.com Thu Apr 16 18:07:23 2015 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 16 Apr 2015 18:07:23 -0400 Subject: [vtk-developers] material files patch for vtkOBJReader In-Reply-To: References: Message-ID: +1 On Thu, Apr 16, 2015 at 12:29 PM, Bill Lorensen wrote: > Berk, > > Peter has done an excellent job creating the OBJImporter. He has been > very responsive to suggestions. Although there may be some minor > cleanup necessary, I think his gitlab topic is ready to merge. > However, he does not have permission to do the merge. I suggest he be > added to the approved developer list. > > Bill > > https://gitlab.kitware.com/vtk/vtk/merge_requests/26 > > > On Mon, Dec 22, 2014 at 2:44 PM, Berk Geveci > wrote: > > My preference would be to develop a new OBJ importer that uses the OBJ > > reader. Making the OBJ reader depend on rendering may impact some folks > > negatively. By the way, I would defer this for a few months if possible. > We > > have a project targeted towards importing material properties for ray > > tracing etc. I don't think that we will follow the importer route and we > > will probably develop a new infrastructure. It may fit better here. > > > > Best, > > -berk > > > > On Mon, Dec 22, 2014 at 12:32 PM, Peter Karasev > wrote: > >> > >> Hi, > >> > >> I'm hoping to get an update for vtkOBJReader integrated in that > >> enables reading material-texture-library (.mtl) files. These are > typically > >> distributed along with the .obj file that contains geometry data. > >> > >> There's an issue with the module structure of VTK in doing this, > >> however: having the MTL file means that you basically must generate not > only > >> geometry but the entire actors with vtkProperty*'s set on them. > >> > >> I propose moving vtkOBJReader into the same area as > vtk3DSImporter, > >> where it is allowed to access things in vtkRenderingCore like vtkActor > >> class. Alternatively, a dependency(ies) could be added to vtkIOGeometry > to > >> allow creating actors. Any views on which way to go here? > >> > >> -- > >> > >> _______________ > >> Peter Karasev > >> karasevpa at gmail.com > >> > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > >> > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Thu Apr 16 18:30:24 2015 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 16 Apr 2015 18:30:24 -0400 Subject: [vtk-developers] Wiki scrapping regression after web page update In-Reply-To: References: Message-ID: Hi Bill, Seems the wiki is available here: http://www.vtk.org/Wiki/VTK Instead of site = mwclient.Site('vtk.org', '/Wiki/') try this site = mwclient.Site('vtk.org', '/Wiki/VTK/') Hth Jc On Mon, Apr 13, 2015 at 11:45 AM, David E DeMarle wrote: > I'll take a look. > thanks > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Tue, Mar 31, 2015 at 3:30 PM, Bill Lorensen > wrote: > >> Folks, >> >> I scrape the vtk.org wiki site each evening to maintain the vtk wiki >> examples. I have a python program that uses mwclient >> (https://github.com/mwclient/mwclient) that uses the MediaWiki API. >> >> Ever since the vtk.org page was updated, my nightly scripts have been >> failing. >> The error are occur on this line: >> >> site = mwclient.Site('vtk.org', '/Wiki/') >> >> If I change vtk.org to itk.org, my scripts work. >> >> I suspect some sort of web magic going on. I can workaround the >> problem but specifying itk.org, but I'd like to understand what >> happened just in case the itk.org site changes in the future. >> >> Thanks, >> >> 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 >> >> > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jchris.fillionr at kitware.com Thu Apr 16 18:31:52 2015 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Thu, 16 Apr 2015 18:31:52 -0400 Subject: [vtk-developers] Wiki scrapping regression after web page update In-Reply-To: References: Message-ID: Hi Bill, I wrote too fast. Ignore my previous email. Jc On Thu, Apr 16, 2015 at 6:30 PM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > Hi Bill, > > Seems the wiki is available here: http://www.vtk.org/Wiki/VTK > > Instead of > > site = mwclient.Site('vtk.org', '/Wiki/') > > try this > > site = mwclient.Site('vtk.org', '/Wiki/VTK/') > > Hth > Jc > > On Mon, Apr 13, 2015 at 11:45 AM, David E DeMarle < > dave.demarle at kitware.com> wrote: > >> I'll take a look. >> thanks >> >> David E DeMarle >> Kitware, Inc. >> R&D Engineer >> 21 Corporate Drive >> Clifton Park, NY 12065-8662 >> Phone: 518-881-4909 >> >> On Tue, Mar 31, 2015 at 3:30 PM, Bill Lorensen >> wrote: >> >>> Folks, >>> >>> I scrape the vtk.org wiki site each evening to maintain the vtk wiki >>> examples. I have a python program that uses mwclient >>> (https://github.com/mwclient/mwclient) that uses the MediaWiki API. >>> >>> Ever since the vtk.org page was updated, my nightly scripts have been >>> failing. >>> The error are occur on this line: >>> >>> site = mwclient.Site('vtk.org', '/Wiki/') >>> >>> If I change vtk.org to itk.org, my scripts work. >>> >>> I suspect some sort of web magic going on. I can workaround the >>> problem but specifying itk.org, but I'd like to understand what >>> happened just in case the itk.org site changes in the future. >>> >>> Thanks, >>> >>> 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 >>> >>> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > > > -- > +1 919 869 8849 > -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Thu Apr 16 19:44:37 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 16 Apr 2015 19:44:37 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: <552FCB86.6090000@kitware.com> References: <20150415201512.16658483@mail.rogue-research.com> <552FCB86.6090000@kitware.com> Message-ID: I %100 agree with Brad. -berk On Thu, Apr 16, 2015 at 10:47 AM, Brad King wrote: > On 04/15/2015 10:20 PM, David Cole via vtk-developers wrote: > > Buttons, labelled "Approve" and "Reject" > > > > Not to be overly pedantic, but buttons should indicate the action you > > are doing by clicking them, not the action you did once they have been > > clicked. (i.e. -- make it an action verb, not a past tense "did that" > > thing...) > > > > +2 for buttons! > > Adding buttons will require modification to GitLab, which we've > ruled must be kept to a minimum. We already have a few mods in > use to get the event web hooks we need. Only after we've gotten > those upstreamed successfully should we consider further mods > locally. We don't want to end up forked like we did with Gerrit. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Thu Apr 16 19:45:22 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 16 Apr 2015 19:45:22 -0400 Subject: [vtk-developers] [vtkusers] VTK Wiki Examples migrating to gitlab In-Reply-To: References: Message-ID: Sounds good. -berk On Thu, Apr 16, 2015 at 11:00 AM, Bill Lorensen wrote: > Berk, > > I have decided to use github. That is where the itk wiki examples > reside. Also, I don't need all of the extra stuff that gitlab > provides. > > Most commits to the examples' repo's are automated through scripting. > > Bill > > On Wed, Apr 15, 2015 at 8:07 PM, Bill Lorensen > wrote: > > Will do. > > > > On Apr 15, 2015 6:33 PM, "Berk Geveci" wrote: > >> > >> Why not move it to gitlab.kitware.com? You can easily create a repo > there. > >> Or even better, someone can create a repo under the VTK group so the > >> examples repo would be a sibling of the VTK repo... > >> > >> On Wed, Apr 15, 2015 at 5:06 PM, Bill Lorensen > > >> wrote: > >>> > >>> Folks, > >>> > >>> The VTK WIki Examples code repo has been hosted on gitorious.org since > >>> the beginning. gitlab.com has purchased gitorious and will kill the > >>> site in the near future. In the next couple of weeks, I'll move the > >>> wiki examples to gitlab.com. I don't expect any problems, but a few > >>> hiccups may occur with web links. The gitorious site has always been > >>> flaky. I hope gitlab will be more robust! > >>> > >>> I'll keep you posted, > >>> > >>> Bill] > >>> _______________________________________________ > >>> 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 > >> > >> > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Thu Apr 16 19:53:32 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 16 Apr 2015 19:53:32 -0400 Subject: [vtk-developers] material files patch for vtkOBJReader In-Reply-To: References: Message-ID: I apologize for missing your Gitlab comment Bill. I have been in report land and have not been paying attention to development for a few weeks. If Peter is considering further contributions to VTK in the future, adding him to the developer list in Gitlab sounds great to me. VTK could use more developers like Peter :-) If this is a one time thing, someone else should probably merge it. Peter: what say you? Best, -berk On Thu, Apr 16, 2015 at 12:29 PM, Bill Lorensen wrote: > Berk, > > Peter has done an excellent job creating the OBJImporter. He has been > very responsive to suggestions. Although there may be some minor > cleanup necessary, I think his gitlab topic is ready to merge. > However, he does not have permission to do the merge. I suggest he be > added to the approved developer list. > > Bill > > https://gitlab.kitware.com/vtk/vtk/merge_requests/26 > > > On Mon, Dec 22, 2014 at 2:44 PM, Berk Geveci > wrote: > > My preference would be to develop a new OBJ importer that uses the OBJ > > reader. Making the OBJ reader depend on rendering may impact some folks > > negatively. By the way, I would defer this for a few months if possible. > We > > have a project targeted towards importing material properties for ray > > tracing etc. I don't think that we will follow the importer route and we > > will probably develop a new infrastructure. It may fit better here. > > > > Best, > > -berk > > > > On Mon, Dec 22, 2014 at 12:32 PM, Peter Karasev > wrote: > >> > >> Hi, > >> > >> I'm hoping to get an update for vtkOBJReader integrated in that > >> enables reading material-texture-library (.mtl) files. These are > typically > >> distributed along with the .obj file that contains geometry data. > >> > >> There's an issue with the module structure of VTK in doing this, > >> however: having the MTL file means that you basically must generate not > only > >> geometry but the entire actors with vtkProperty*'s set on them. > >> > >> I propose moving vtkOBJReader into the same area as > vtk3DSImporter, > >> where it is allowed to access things in vtkRenderingCore like vtkActor > >> class. Alternatively, a dependency(ies) could be added to vtkIOGeometry > to > >> allow creating actors. Any views on which way to go here? > >> > >> -- > >> > >> _______________ > >> Peter Karasev > >> karasevpa at gmail.com > >> > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > >> > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Apr 17 08:56:30 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 17 Apr 2015 08:56:30 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: References: <20150415201512.16658483@mail.rogue-research.com> Message-ID: <20150417125630.GA24711@megas.kitware.com> On Wed, Apr 15, 2015 at 22:20:04 -0400, David Cole via vtk-developers wrote: > Buttons, labelled "Approve" and "Reject" > > Not to be overly pedantic, but buttons should indicate the action you > are doing by clicking them, not the action you did once they have been > clicked. (i.e. -- make it an action verb, not a past tense "did that" > thing...) > > +2 for buttons! Here are some bookmarklets you can add to your browser add put in the bookmark toolbar: Ack: javascript:(function(){jQuery("textarea.note_text:visible").val("+1")})() Review: javascript:(function(){jQuery("textarea.note_text:visible").val("+2")})() Tested: javascript:(function(){jQuery("textarea.note_text:visible").val("+3")})() Reject: javascript:(function(){jQuery("textarea.note_text:visible").val("-1")})() Buildbot: javascript:(function(){jQuery("textarea.note_text:visible").val("@buildbot test")})() Merge: javascript:(function(){jQuery("textarea.note_text:visible").val("\n\nDo: merge")})() Note that these will *overwrite* any text currently in the comment box. --Ben From DLRdave at aol.com Fri Apr 17 09:39:06 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 17 Apr 2015 09:39:06 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: <20150417125630.GA24711@megas.kitware.com> References: <20150415201512.16658483@mail.rogue-research.com> <20150417125630.GA24711@megas.kitware.com> Message-ID: <4AC5E19B-105E-4E8F-8171-E7DDC370628F@gmail.com> JavaScript FTW! Thanks, Ben. Great idea. > On Apr 17, 2015, at 8:56 AM, Ben Boeckel wrote: > >> On Wed, Apr 15, 2015 at 22:20:04 -0400, David Cole via vtk-developers wrote: >> Buttons, labelled "Approve" and "Reject" >> >> Not to be overly pedantic, but buttons should indicate the action you >> are doing by clicking them, not the action you did once they have been >> clicked. (i.e. -- make it an action verb, not a past tense "did that" >> thing...) >> >> +2 for buttons! > > Here are some bookmarklets you can add to your browser add put in the > bookmark toolbar: > > Ack: > javascript:(function(){jQuery("textarea.note_text:visible").val("+1")})() > Review: > javascript:(function(){jQuery("textarea.note_text:visible").val("+2")})() > Tested: > javascript:(function(){jQuery("textarea.note_text:visible").val("+3")})() > Reject: > javascript:(function(){jQuery("textarea.note_text:visible").val("-1")})() > Buildbot: > javascript:(function(){jQuery("textarea.note_text:visible").val("@buildbot test")})() > Merge: > javascript:(function(){jQuery("textarea.note_text:visible").val("\n\nDo: merge")})() > > Note that these will *overwrite* any text currently in the comment box. > > --Ben From DLRdave at aol.com Fri Apr 17 09:46:41 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 17 Apr 2015 09:46:41 -0400 Subject: [vtk-developers] Approving a gitlab topic In-Reply-To: <20150417125630.GA24711@megas.kitware.com> References: <20150415201512.16658483@mail.rogue-research.com> <20150417125630.GA24711@megas.kitware.com> Message-ID: <2A3AEBFA-1071-4023-ADB4-C077313C7771@aol.com> JavaScript FTW! Thanks, Ben. Great idea. > On Apr 17, 2015, at 8:56 AM, Ben Boeckel wrote: > >> On Wed, Apr 15, 2015 at 22:20:04 -0400, David Cole via vtk-developers wrote: >> Buttons, labelled "Approve" and "Reject" >> >> Not to be overly pedantic, but buttons should indicate the action you >> are doing by clicking them, not the action you did once they have been >> clicked. (i.e. -- make it an action verb, not a past tense "did that" >> thing...) >> >> +2 for buttons! > > Here are some bookmarklets you can add to your browser add put in the > bookmark toolbar: > > Ack: > javascript:(function(){jQuery("textarea.note_text:visible").val("+1")})() > Review: > javascript:(function(){jQuery("textarea.note_text:visible").val("+2")})() > Tested: > javascript:(function(){jQuery("textarea.note_text:visible").val("+3")})() > Reject: > javascript:(function(){jQuery("textarea.note_text:visible").val("-1")})() > Buildbot: > javascript:(function(){jQuery("textarea.note_text:visible").val("@buildbot test")})() > Merge: > javascript:(function(){jQuery("textarea.note_text:visible").val("\n\nDo: merge")})() > > Note that these will *overwrite* any text currently in the comment box. > > --Ben From karasevpa at gmail.com Fri Apr 17 11:10:50 2015 From: karasevpa at gmail.com (Peter Karasev) Date: Fri, 17 Apr 2015 08:10:50 -0700 Subject: [vtk-developers] material files patch for vtkOBJReader In-Reply-To: References: Message-ID: Yes I would be interested in contributing over time; not a one time thing. Peter Karasev On Apr 16, 2015 7:53 PM, "Berk Geveci" wrote: > I apologize for missing your Gitlab comment Bill. I have been in report > land and have not been paying attention to development for a few weeks. > > If Peter is considering further contributions to VTK in the future, adding > him to the developer list in Gitlab sounds great to me. VTK could use more > developers like Peter :-) If this is a one time thing, someone else should > probably merge it. Peter: what say you? > > Best, > -berk > > > On Thu, Apr 16, 2015 at 12:29 PM, Bill Lorensen > wrote: > >> Berk, >> >> Peter has done an excellent job creating the OBJImporter. He has been >> very responsive to suggestions. Although there may be some minor >> cleanup necessary, I think his gitlab topic is ready to merge. >> However, he does not have permission to do the merge. I suggest he be >> added to the approved developer list. >> >> Bill >> >> https://gitlab.kitware.com/vtk/vtk/merge_requests/26 >> >> >> On Mon, Dec 22, 2014 at 2:44 PM, Berk Geveci >> wrote: >> > My preference would be to develop a new OBJ importer that uses the OBJ >> > reader. Making the OBJ reader depend on rendering may impact some folks >> > negatively. By the way, I would defer this for a few months if >> possible. We >> > have a project targeted towards importing material properties for ray >> > tracing etc. I don't think that we will follow the importer route and we >> > will probably develop a new infrastructure. It may fit better here. >> > >> > Best, >> > -berk >> > >> > On Mon, Dec 22, 2014 at 12:32 PM, Peter Karasev >> wrote: >> >> >> >> Hi, >> >> >> >> I'm hoping to get an update for vtkOBJReader integrated in that >> >> enables reading material-texture-library (.mtl) files. These are >> typically >> >> distributed along with the .obj file that contains geometry data. >> >> >> >> There's an issue with the module structure of VTK in doing this, >> >> however: having the MTL file means that you basically must generate >> not only >> >> geometry but the entire actors with vtkProperty*'s set on them. >> >> >> >> I propose moving vtkOBJReader into the same area as >> vtk3DSImporter, >> >> where it is allowed to access things in vtkRenderingCore like vtkActor >> >> class. Alternatively, a dependency(ies) could be added to >> vtkIOGeometry to >> >> allow creating actors. Any views on which way to go here? >> >> >> >> -- >> >> >> >> _______________ >> >> Peter Karasev >> >> karasevpa at gmail.com >> >> >> >> _______________________________________________ >> >> Powered by www.kitware.com >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> >> >> > >> > _______________________________________________ >> > Powered by www.kitware.com >> > >> > Visit other Kitware open-source projects at >> > http://www.kitware.com/opensource/opensource.html >> > >> > Follow this link to subscribe/unsubscribe: >> > http://public.kitware.com/mailman/listinfo/vtk-developers >> > >> > >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Fri Apr 17 12:19:35 2015 From: majcjc at gmail.com (Lin M) Date: Fri, 17 Apr 2015 12:19:35 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> <54647355-DFD4-489D-A282-1994902CB6E3@kitware.com> <664F50F1-D75E-4F50-97CD-351813F224AE@kitware.com> <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> Message-ID: Hi Dr. Thompson, I have created a new branch named fiter-bizier and upload the code for patch interpolation. Best, Lin On Thu, Apr 9, 2015 at 2:29 PM, Lin M wrote: > Hi Shawn, > > Thank you for your answer. I get it now. :-) > > Best, > Lin > > On Thu, Apr 9, 2015 at 2:13 PM, Shawn Waldon > wrote: > > Ok, that test was on hythloth, which is an experimental dashboard to > begin > > with (and the issue, fixed about an hour ago was a buildbot configuration > > problem). You can ignore that one. We are working on moving the > buildbot > > view of tests so that external contributors can see it. The vtk-expected > > dashboards look fine with your merge request. > > > > --Shawn > > > > On Thu, Apr 9, 2015 at 2:01 PM, Lin M wrote: > >> > >> I mean some of the outputs doesn't seem to be debuggable. For example > >> one of the test output said: > >> > >> Test output > >> > >> No protocol specified > >> No protocol specified > >> application-specific initialization failed: couldn't connect to display > >> ":40" > >> Error in startup script: can't find package vtk > >> while executing > >> "package require vtk" > >> (file > >> > "/home/buildbot/buildbot-slave/vtk-hythloth-linux-shared-release_java_mpi_python_qt_tcl/source/Testing/Rendering/rtImageTest.tcl" > >> line 1) > >> > >> But how can I fix this error? > >> > >> On Thu, Apr 9, 2015 at 1:53 PM, Lin M wrote: > >> > Hi Dr. Thompson, > >> > > >> > Thank you! > >> > I found that there were test failures from the buildbot. How can I > debug > >> > them? > >> > > >> > Best, > >> > Lin > >> > > >> > On Thu, Apr 9, 2015 at 1:37 PM, David Thompson > >> > > >> > wrote: > >> >> > >> >> Hi Lin, > >> >> > >> >> > I have created a merge request in the gitlab. Can you see it? > >> >> > >> >> The memoization of vtkMath::Factorial() looks good. I have added a > >> >> "Reviewed-by: me" comment that should give you permission to merge > the > >> >> branch (by adding a "Do: merge" comment to the merge request). > >> >> > >> >> When you add the "Do: merge" comment, you are committing to watch the > >> >> VTK > >> >> dashboard over the next day to make sure that there are no build or > >> >> test > >> >> failures (and to submit a new merge request to address them if some > >> >> appear). > >> >> > >> >> David > >> > > >> > > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the 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 majcjc at gmail.com Fri Apr 17 12:37:38 2015 From: majcjc at gmail.com (Lin M) Date: Fri, 17 Apr 2015 12:37:38 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> <54647355-DFD4-489D-A282-1994902CB6E3@kitware.com> <664F50F1-D75E-4F50-97CD-351813F224AE@kitware.com> <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> Message-ID: Do I need to make a merge requests for that? There are still many things to be improved in the code. On Fri, Apr 17, 2015 at 12:19 PM, Lin M wrote: > Hi Dr. Thompson, > > I have created a new branch named fiter-bizier and upload the code for > patch interpolation. > > Best, > Lin > > On Thu, Apr 9, 2015 at 2:29 PM, Lin M wrote: > >> Hi Shawn, >> >> Thank you for your answer. I get it now. :-) >> >> Best, >> Lin >> >> On Thu, Apr 9, 2015 at 2:13 PM, Shawn Waldon >> wrote: >> > Ok, that test was on hythloth, which is an experimental dashboard to >> begin >> > with (and the issue, fixed about an hour ago was a buildbot >> configuration >> > problem). You can ignore that one. We are working on moving the >> buildbot >> > view of tests so that external contributors can see it. The >> vtk-expected >> > dashboards look fine with your merge request. >> > >> > --Shawn >> > >> > On Thu, Apr 9, 2015 at 2:01 PM, Lin M wrote: >> >> >> >> I mean some of the outputs doesn't seem to be debuggable. For example >> >> one of the test output said: >> >> >> >> Test output >> >> >> >> No protocol specified >> >> No protocol specified >> >> application-specific initialization failed: couldn't connect to display >> >> ":40" >> >> Error in startup script: can't find package vtk >> >> while executing >> >> "package require vtk" >> >> (file >> >> >> "/home/buildbot/buildbot-slave/vtk-hythloth-linux-shared-release_java_mpi_python_qt_tcl/source/Testing/Rendering/rtImageTest.tcl" >> >> line 1) >> >> >> >> But how can I fix this error? >> >> >> >> On Thu, Apr 9, 2015 at 1:53 PM, Lin M wrote: >> >> > Hi Dr. Thompson, >> >> > >> >> > Thank you! >> >> > I found that there were test failures from the buildbot. How can I >> debug >> >> > them? >> >> > >> >> > Best, >> >> > Lin >> >> > >> >> > On Thu, Apr 9, 2015 at 1:37 PM, David Thompson >> >> > >> >> > wrote: >> >> >> >> >> >> Hi Lin, >> >> >> >> >> >> > I have created a merge request in the gitlab. Can you see it? >> >> >> >> >> >> The memoization of vtkMath::Factorial() looks good. I have added a >> >> >> "Reviewed-by: me" comment that should give you permission to merge >> the >> >> >> branch (by adding a "Do: merge" comment to the merge request). >> >> >> >> >> >> When you add the "Do: merge" comment, you are committing to watch >> the >> >> >> VTK >> >> >> dashboard over the next day to make sure that there are no build or >> >> >> test >> >> >> failures (and to submit a new merge request to address them if some >> >> >> appear). >> >> >> >> >> >> David >> >> > >> >> > >> >> _______________________________________________ >> >> Powered by www.kitware.com >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Search the list archives at: >> http://markmail.org/search/?q=vtk-developers >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.boeckel at kitware.com Fri Apr 17 12:49:31 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 17 Apr 2015 12:49:31 -0400 Subject: [vtk-developers] material files patch for vtkOBJReader In-Reply-To: References: Message-ID: <20150417164931.GC23841@megas.kitware.com> On Fri, Apr 17, 2015 at 08:10:50 -0700, Peter Karasev wrote: > Yes I would be interested in contributing over time; not a one time thing. Developer access granted :) . --Ben From berk.geveci at kitware.com Fri Apr 17 15:21:24 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Fri, 17 Apr 2015 15:21:24 -0400 Subject: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter In-Reply-To: <65D987BE62E58141AA480A59A8B5BBEA6DEB198A@srv-mail.diana.local> References: <65D987BE62E58141AA480A59A8B5BBEA6DEAF624@srv-mail.diana.local> <551C5095.7050700@dsl.pipex.com> <65D987BE62E58141AA480A59A8B5BBEA6DEB1705@srv-mail.diana.local> <65D987BE62E58141AA480A59A8B5BBEA6DEB198A@srv-mail.diana.local> Message-ID: Dear Andreas, I took a look at your branch. At an initial glance, things look good. I will dig deeper and also ask for some help in the near future. I have one question: I noticed that vtkWedge::IntersectWithLine() uses face information. Did you verify that it still works? Best, -berk On Wed, Apr 8, 2015 at 4:50 AM, Andreas Buykx wrote: > Hi Berk, > > > > I just pushed my work. I think it would be good to add the python script > as well somewhere? > > > > https://gitlab.kitware.com/bxa/vtk/tree/wedge-face-points > > > > Happy holidays, > > Andreas > > > > *From:* Berk Geveci [mailto:berk.geveci at kitware.com] > *Sent:* dinsdag 7 april 2015 18:49 > *To:* Andreas Buykx > > *Subject:* Re: [vtk-developers] vtkWedge face node ordering and > vtkUnstructuredGridGeometryFilter > > > > Hi Andreas, > > > > Can you please point me to your branch? I am on vacation for the rest of > the week so you may not hear from me for a few days. > > > > Best, > > -berk > > > > On Fri, Apr 3, 2015 at 8:06 AM, Andreas Buykx > wrote: > > Hi, > > All non-linear wedges have the same ordering of face points, causing their > normal to point inward. > > Creating the wedge inside-out seems to work for the > vtkUnstructuredGridGeometryFilter (UGGF) issue, but wouldn't this have side > effects in routines in vtkCell or vtkCell3D, e.g. when interpolating, > contouring, etc? > > From code inspection I found out that for all wedges, the only method that > uses the face point ordering array is the method IntersectWithLine, and > that method seems to be independent of the orientation of the face. > Changing the three methods that return the face points (GetFace and > GetFaceArray) to return properly ordered faces would therefore have the > same net result as changing the order of the points in the faces array. In > both cases all direct and indirect clients (including UGGF) of these > methods may produce different results. However, these differences in > results, if any, are for the better I would say. For example it may not be > necessary anymore to correct normals since they are already oriented > consistently ;-). > > As for documentation, the documentation of vtkWedge does not mention > anything specific about the orientation of face points or face normals, nor > does the vtkCell3D or vtkCell. Also, I couldn't find any definitions of how > face normal are supposed to be oriented in the books (toolkit ed.4, user's > guide ed.11). > > I created a topic in my repository and made the necessary changes in all > wedge classes. The tests that are mentioned for these classes succeed > (cells.py fails because I have no VTKData, and TestCellCentersPointPlacer > spits out some xml related to DartMeasurement which seems not related to > the wedge test). Note that TestCellCentersPointPlacer creates an inverted > wedge. > > How do we proceed? > > Kind regards, > Andreas > > ________________________________________ > From: John Platt [jcplatt at dsl.pipex.com] > Sent: Wednesday, April 01, 2015 10:09 PM > To: Berk Geveci; Andreas Buykx > Cc: vtk-developers at vtk.org > Subject: Re: [vtk-developers] vtkWedge face node ordering and > vtkUnstructuredGridGeometryFilter > > > Hi, > > I think this is also a problem for vtkDataSetSurfaceFilter when mixing > quadratic hex's & wedges. If the actor opacity is reduced, the internal > faces between the hex's & wedges are visible. > > This can be fixed by turning the wedge inside-out i.e. swapping points 1 > & 2 and 4 & 5. The FE system I work with allows both right and left > handed elements so the topology of each element must be checked and > inverted if necessary. > > I agree that the order of the nodes in the face arrays should be changed > to be consistent with the other cells. I suspect this would largely go > unnoticed given the time this inconsistency has been present and the > number of reports on the behaviour. > > Thanks, > > John. > > > > On 01/04/2015 16:42, Berk Geveci wrote: > > Hi Andreas, > > > > Changing the ordering of vtkWedge would be a very large undertaking > > given that there is years of documentation, file formats (in VTK and > > 3rd party), code etc. that depend on a certain ordering. One less > > intrusive way would be to change any vtkWedge methods that returns > > faces to return them in a different order. I suspect this option is > > doable but I'd like to hear from the community. The least intrusive > > options is to fix the few filters that have this issue but I feel like > > it is a band-aid. > > > > Best, > > -berk > > > > On Wed, Apr 1, 2015 at 9:51 AM, Andreas Buykx > wrote: > >> Hi, > >> > >> > >> > >> To detect if coinciding faces of neighbouring 3D cells are connected, > >> vtkUnstructuredGridGeometryFilter walks the points of these faces in > >> opposite directions and expects the point ids to match. This fails for > >> vtkWedge attached to e.g. vtkTetra and vtkHexahedron as demonstrated by > the > >> python script I attach. The root cause is that the > vtkWedge::GetFaceArray > >> and vtkWedge::GetFace return the face points in an ordering that makes > the > >> face normal point into the 3D cell instead of out of the 3D cell, like > all > >> other 3D cells do. The two other algorithms that generate surface cells > >> (vtkDataSetSurfaceFilter and vtkGeometryFilter) don't suffer from this > >> ordering because the former checks point ordering but explicitly allows > both > >> loop directions, and the latter only takes cell connectivity into > account > >> without checking point-ordering at all. > >> > >> > >> > >> I don't know what the reason is to have a different face-point ordering > for > >> the vtkWedge, but one of the other consequences is that the outer > surface > >> will have inconsistent cell normals as can easily be seen when loading > the > >> xml files produced by the tests in paraview, and showing the cell > normals. > >> So I would prefer to change the face-point ordering in vtkWedge. If > that is > >> not possible for some reason then I propose to make/update the > case-blocks > >> in the surface filters cell-type switches to re-order the face-points > for > >> the wedge faces. As long as this is not dealt with our FEA models will > show > >> edges where they should not be so I will have to solve this issue one > way or > >> another, and I'd like to contribute it to VTK as well. > >> > >> > >> > >> Shall I make a mantis issue for this? Who can help me with the > git/gerrit > >> stuff? > >> > >> > >> > >> Thanks a lot, > >> > >> Andreas Buykx > >> > >> ____________________________________________________________ > >> TNO DIANA BV is a limited liability company registered in the trade > register > >> of the Chamber of Commerce as TNO DIANA BV with registered number > 27252655. > >> ____________________________________________________________ > >> This e-mail and its contents are subject to the DISCLAIMER at > >> http://tnodiana.com/content/Disclaimer > >> ____________________________________________________________ > >> > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > >> > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > ____________________________________________________________ > TNO DIANA BV is a limited liability company registered in the trade > register of the Chamber of Commerce as TNO DIANA BV with registered number > 27252655. > ____________________________________________________________ > This e-mail and its contents are subject to the DISCLAIMER at > http://tnodiana.com/content/Disclaimer > ____________________________________________________________ > > > ____________________________________________________________ > TNO DIANA BV is a limited liability company registered in the trade > register of the Chamber of Commerce as TNO DIANA BV with registered number > 27252655. > ____________________________________________________________ > This e-mail and its contents are subject to the DISCLAIMER at > http://tnodiana.com/content/Disclaimer > ____________________________________________________________ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri Apr 17 22:53:50 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 17 Apr 2015 22:53:50 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <7BDC5A79-20D2-4846-8F84-A9A6014ACC41@kitware.com> <5409EB39-58C8-44FC-A5AE-00373C1C28F9@kitware.com> <56D12D32-339D-4417-8DBF-2E8D237FA7F8@kitware.com> <54647355-DFD4-489D-A282-1994902CB6E3@kitware.com> <664F50F1-D75E-4F50-97CD-351813F224AE@kitware.com> <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> Message-ID: <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> Hi Lin, Thanks for pushing the branch to gitlab. > Do I need to make a merge requests for that? There are still many things to be improved in the code. You can submit merge requests -- but not to vtk/vtk. I have created a new group named splines and added you as a developer. Please fork this repository: https://gitlab.kitware.com/splines/vtk You will have to tell gitlab to delete your existing fork of VTK (only on the web, not the files on your computer!) and fork that repository instead in order to submit merge requests. To remove your current fork of VTK, visit: https://gitlab.kitware.com/Lin.Ma/vtk/edit Scroll to the bottom of the page and click the red "Remove project" button. Then you can fork splines/vtk by visiting https://gitlab.kitware.com/splines/vtk and clicking its "Fork" button at the top right of the page. You will see that splines/vtk already contains your filters-bezier branch and that I have made some changes (so that it meets the VTK style guidelines). Please review the changes and make sure you understand what I've done. If you are unsure what I did or why I did it, please ask. Once you have reviewed the changes, please make a small change and submit a merge request from Lin.Ma/vtk filters-bezier to vtk/splines filters-bezier to test that merge requests work. Thanks, David From max.sagebaum at scicomp.uni-kl.de Mon Apr 20 03:04:38 2015 From: max.sagebaum at scicomp.uni-kl.de (Max Sagebaum) Date: Mon, 20 Apr 2015 07:04:38 +0000 Subject: [vtk-developers] Changing floating point Types in VTK Message-ID: <1429513478.7444.5.camel@localhost> Dear developers, we are currently using parts of the VTK Version 5.10 for our CFD Postprocessing Tool. We have successfully modified theses parts to facilitate an AD-Tool (Algorithmic Differentiation) to differentiate these code parts (intention is to not just get absolute values for our CFD-results, but also evaluate sensitivities/gradients). Caused by further developments in our tool we would like to go with newer VTK-Versions, which means repeating the changes in the code parts facilitating AD. We would like to implement these changes into the VTK-trunk, to avoid reprogramming and to offer the possibility of using AD to everyone. We would like to explain the changes in short and ask you to judge if such changes are likely to be accepted or if there is an interest in making VTK ?AD-able?. If not, we would avoid the presumably laborious implementation and would not put it into the Git/Develop loop. There are two main changes we had to make. To get the gradients of a program, the AD-Tool defines new AD floating point types which take care of the derivative computation. In order to use these AD types in VTK we needed to create two typedefs for float and double. Then every usage of float and double in VTK was replaced by the new typedefs. With this change, it is also possible to other types in VTK. E.g. complex values. The second change we made, was to rename every 'static_cast' call to a new function 'perform_cast'. Basically 'perfom_cast' just calls 'static_cast'. If you use other types than float or double 'static_cast' will complain that the conversion from eg. 'MyFloatType' to 'int' does not exist. 'perfom_cast' was specialized for the AD types and therefore the casts could be done. During this process we checked most of the occurrences of 'static_cast' and validated that the usage will not break the differentiation. There are two other solutions to our approach. We could implement conversion operators for the AD types, which enables 'static_cast' to do the conversion. But this is mostly discouraged by the tool developers. If the conversion operators are implemented, the compiler starts to implicit convert the AD types and very weird things can happen. The second approach would define these operators as explicit which would prevent the compiler from implicitly converting them. But then VTK would need to be compiled with C++11 enabled or if the user changes these types he also has to enable C++11 if necessary. Is the any interest on the developers or users side to use VTK with AD or other floating point types? Thanks for your opinions and judgment! Max Sagebaum From A.Buykx at tnodiana.com Mon Apr 20 06:49:16 2015 From: A.Buykx at tnodiana.com (Andreas Buykx) Date: Mon, 20 Apr 2015 10:49:16 +0000 Subject: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter In-Reply-To: References: <65D987BE62E58141AA480A59A8B5BBEA6DEAF624@srv-mail.diana.local> <551C5095.7050700@dsl.pipex.com> <65D987BE62E58141AA480A59A8B5BBEA6DEB1705@srv-mail.diana.local> <65D987BE62E58141AA480A59A8B5BBEA6DEB198A@srv-mail.diana.local> Message-ID: <65D987BE62E58141AA480A59A8B5BBEA6DEB3F61@srv-mail.diana.local> Hi, Good point about IntersectWithLine. I added a IntersectWithLine test to wedge_test.py, and intersect with a line parallel to the wedge?s axis both from top to bottom and from bottom to top. I apply the same test to a hexahedron. Apparently, in VTK6.2.0, the top and bottom parameterized coordinate are returned for the wedge?s triangles with face-normal pointing inward, but for the hexahedron?s quadrilaterals with a face-normal pointing outward. This is consistent with the wedge being defined inside-out. Should this behavior be changed as well? If not there is an inconsistency between face orientation and behavior of IntersectWithLine, if it is changed, many calling filters may yield different results. Note as well that the documentation of the vtkWedge states that the points are arranged such that bottom triangle normal points away from the other triangle face, so outward. This in contrast to the vtkHexahedron where the bottom quadrilateral points towards the other face, so inward. I suppose the definition of the cell will not be changed, that would have a significant impact for sure. However, I don?t think though that the cell point ordering is supposed to be related to the parameterization of the intersection of the faces: given the cell point ordering the two opposite faces of wedge and hexahedron have normals that point in the same absolute direction, so one face normal points inward and one face normal points outward. The IntersectWithLine implementations return parameterizations that orient the normals either both inward or both outward. So, I?m not sure as to what should be done. I think with my change the face normals are oriented outward, and the intersection point parameterization should be consistent with that. What are your views? Kind regards, Andreas From: Berk Geveci [mailto:berk.geveci at kitware.com] Sent: vrijdag 17 april 2015 21:21 To: Andreas Buykx; VTK Developers Subject: Re: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter Dear Andreas, I took a look at your branch. At an initial glance, things look good. I will dig deeper and also ask for some help in the near future. I have one question: I noticed that vtkWedge::IntersectWithLine() uses face information. Did you verify that it still works? Best, -berk On Wed, Apr 8, 2015 at 4:50 AM, Andreas Buykx > wrote: Hi Berk, I just pushed my work. I think it would be good to add the python script as well somewhere? https://gitlab.kitware.com/bxa/vtk/tree/wedge-face-points Happy holidays, Andreas From: Berk Geveci [mailto:berk.geveci at kitware.com] Sent: dinsdag 7 april 2015 18:49 To: Andreas Buykx Subject: Re: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter Hi Andreas, Can you please point me to your branch? I am on vacation for the rest of the week so you may not hear from me for a few days. Best, -berk On Fri, Apr 3, 2015 at 8:06 AM, Andreas Buykx > wrote: Hi, All non-linear wedges have the same ordering of face points, causing their normal to point inward. Creating the wedge inside-out seems to work for the vtkUnstructuredGridGeometryFilter (UGGF) issue, but wouldn't this have side effects in routines in vtkCell or vtkCell3D, e.g. when interpolating, contouring, etc? From code inspection I found out that for all wedges, the only method that uses the face point ordering array is the method IntersectWithLine, and that method seems to be independent of the orientation of the face. Changing the three methods that return the face points (GetFace and GetFaceArray) to return properly ordered faces would therefore have the same net result as changing the order of the points in the faces array. In both cases all direct and indirect clients (including UGGF) of these methods may produce different results. However, these differences in results, if any, are for the better I would say. For example it may not be necessary anymore to correct normals since they are already oriented consistently ;-). As for documentation, the documentation of vtkWedge does not mention anything specific about the orientation of face points or face normals, nor does the vtkCell3D or vtkCell. Also, I couldn't find any definitions of how face normal are supposed to be oriented in the books (toolkit ed.4, user's guide ed.11). I created a topic in my repository and made the necessary changes in all wedge classes. The tests that are mentioned for these classes succeed (cells.py fails because I have no VTKData, and TestCellCentersPointPlacer spits out some xml related to DartMeasurement which seems not related to the wedge test). Note that TestCellCentersPointPlacer creates an inverted wedge. How do we proceed? Kind regards, Andreas ________________________________________ From: John Platt [jcplatt at dsl.pipex.com] Sent: Wednesday, April 01, 2015 10:09 PM To: Berk Geveci; Andreas Buykx Cc: vtk-developers at vtk.org Subject: Re: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter Hi, I think this is also a problem for vtkDataSetSurfaceFilter when mixing quadratic hex's & wedges. If the actor opacity is reduced, the internal faces between the hex's & wedges are visible. This can be fixed by turning the wedge inside-out i.e. swapping points 1 & 2 and 4 & 5. The FE system I work with allows both right and left handed elements so the topology of each element must be checked and inverted if necessary. I agree that the order of the nodes in the face arrays should be changed to be consistent with the other cells. I suspect this would largely go unnoticed given the time this inconsistency has been present and the number of reports on the behaviour. Thanks, John. On 01/04/2015 16:42, Berk Geveci wrote: > Hi Andreas, > > Changing the ordering of vtkWedge would be a very large undertaking > given that there is years of documentation, file formats (in VTK and > 3rd party), code etc. that depend on a certain ordering. One less > intrusive way would be to change any vtkWedge methods that returns > faces to return them in a different order. I suspect this option is > doable but I'd like to hear from the community. The least intrusive > options is to fix the few filters that have this issue but I feel like > it is a band-aid. > > Best, > -berk > > On Wed, Apr 1, 2015 at 9:51 AM, Andreas Buykx > wrote: >> Hi, >> >> >> >> To detect if coinciding faces of neighbouring 3D cells are connected, >> vtkUnstructuredGridGeometryFilter walks the points of these faces in >> opposite directions and expects the point ids to match. This fails for >> vtkWedge attached to e.g. vtkTetra and vtkHexahedron as demonstrated by the >> python script I attach. The root cause is that the vtkWedge::GetFaceArray >> and vtkWedge::GetFace return the face points in an ordering that makes the >> face normal point into the 3D cell instead of out of the 3D cell, like all >> other 3D cells do. The two other algorithms that generate surface cells >> (vtkDataSetSurfaceFilter and vtkGeometryFilter) don't suffer from this >> ordering because the former checks point ordering but explicitly allows both >> loop directions, and the latter only takes cell connectivity into account >> without checking point-ordering at all. >> >> >> >> I don't know what the reason is to have a different face-point ordering for >> the vtkWedge, but one of the other consequences is that the outer surface >> will have inconsistent cell normals as can easily be seen when loading the >> xml files produced by the tests in paraview, and showing the cell normals. >> So I would prefer to change the face-point ordering in vtkWedge. If that is >> not possible for some reason then I propose to make/update the case-blocks >> in the surface filters cell-type switches to re-order the face-points for >> the wedge faces. As long as this is not dealt with our FEA models will show >> edges where they should not be so I will have to solve this issue one way or >> another, and I'd like to contribute it to VTK as well. >> >> >> >> Shall I make a mantis issue for this? Who can help me with the git/gerrit >> stuff? >> >> >> >> Thanks a lot, >> >> Andreas Buykx >> >> ____________________________________________________________ >> TNO DIANA BV is a limited liability company registered in the trade register >> of the Chamber of Commerce as TNO DIANA BV with registered number 27252655. >> ____________________________________________________________ >> This e-mail and its contents are subject to the DISCLAIMER at >> http://tnodiana.com/content/Disclaimer >> ____________________________________________________________ >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > ____________________________________________________________ TNO DIANA BV is a limited liability company registered in the trade register of the Chamber of Commerce as TNO DIANA BV with registered number 27252655. ____________________________________________________________ This e-mail and its contents are subject to the DISCLAIMER at http://tnodiana.com/content/Disclaimer ____________________________________________________________ ____________________________________________________________ TNO DIANA BV is a limited liability company registered in the trade register of the Chamber of Commerce as TNO DIANA BV with registered number 27252655. ____________________________________________________________ This e-mail and its contents are subject to the DISCLAIMER at http://tnodiana.com/content/Disclaimer ____________________________________________________________ ____________________________________________________________ TNO DIANA BV is a limited liability company registered in the trade register of the Chamber of Commerce as TNO DIANA BV with registered number 27252655. ____________________________________________________________ This e-mail and its contents are subject to the DISCLAIMER at http://tnodiana.com/content/Disclaimer ____________________________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: wedge_test.py Type: application/octet-stream Size: 8034 bytes Desc: wedge_test.py URL: From ben.boeckel at kitware.com Mon Apr 20 09:12:00 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Mon, 20 Apr 2015 09:12:00 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> Message-ID: <20150420131200.GA450@megas.kitware.com> On Fri, Apr 17, 2015 at 22:53:50 -0400, David Thompson wrote: > Thanks for pushing the branch to gitlab. > > > Do I need to make a merge requests for that? There are still many > > things to be improved in the code. > > You can submit merge requests -- but not to vtk/vtk. I have created a > new group named splines and added you as a developer. Please fork this > repository: > > https://gitlab.kitware.com/splines/vtk I have local (largely untested, but a smoke test succeeded) changes which allow submitting MRs to other forks of the same project, so this whole repo shuffle thing should be unnecessary once that gets some more testing (and we should finally have a complete end-to-end test instance up and running here this week). > You will have to tell gitlab to delete your existing fork of VTK (only > on the web, not the files on your computer!) and fork that repository > instead in order to submit merge requests. To remove your current fork > of VTK, visit: > > https://gitlab.kitware.com/Lin.Ma/vtk/edit > > Scroll to the bottom of the page and click the red "Remove project" > button. Then you can fork splines/vtk by visiting > > https://gitlab.kitware.com/splines/vtk > > and clicking its "Fork" button at the top right of the page. You will > see that splines/vtk already contains your filters-bezier branch and > that I have made some changes (so that it meets the VTK style > guidelines). Probably easier to just rename the project rather than deleting it. Alternatively, give developer access to Lin.Ma for splines/vtk and make an MR from splines/vtk to itself. > Please review the changes and make sure you understand what I've done. > If you are unsure what I did or why I did it, please ask. > > Once you have reviewed the changes, please make a small change and > submit a merge request from Lin.Ma/vtk filters-bezier to vtk/splines > filters-bezier to test that merge requests work. FYI, kwrobot and buildbot do not act on reporitories other than the ones specified in their scripts, so your @buildbot test I saw will go ignored until it shows up as an MR on vtk/vtk. --Ben From will.schroeder at kitware.com Mon Apr 20 12:00:04 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Mon, 20 Apr 2015 12:00:04 -0400 Subject: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter In-Reply-To: <65D987BE62E58141AA480A59A8B5BBEA6DEB3F61@srv-mail.diana.local> References: <65D987BE62E58141AA480A59A8B5BBEA6DEAF624@srv-mail.diana.local> <551C5095.7050700@dsl.pipex.com> <65D987BE62E58141AA480A59A8B5BBEA6DEB1705@srv-mail.diana.local> <65D987BE62E58141AA480A59A8B5BBEA6DEB198A@srv-mail.diana.local> <65D987BE62E58141AA480A59A8B5BBEA6DEB3F61@srv-mail.diana.local> Message-ID: Hi Andreas- Interesting discussion, I'm sorry that I'm late to the party. Here are some random items: 1. This document is worth viewing if you have not seen it already (on page 9): http://ins.uni-bonn.de/teaching/alumni/bebendorf/Praktikum_SS12/vtk_file_formats.pdf has a pictorial representation of the point ordering (the vtk.org link to this file is broken due to our recent rework of the VTK web pages; I have informed our web people). Note that the vtkWedge is ordered inconsistently with all other cells as you have pointed out. I have no idea why: whether it was another cook in the kitchen or whether a brain was not functioning properly that day. 2. As Berk pointed out, changing the point ordering at this late date is problematic, mainly because lots of people have written files assuming this ordering. My main concern is to make sure that once the data is ingested into VTK from that point on the computations are consistent. This includes filters like vtkUnstructuredGridGeometryFilter and also all internal methods for parameterization and topological access. So let's identify the inconsistencies (I think you've already done most of the work) and make sure that everything is consistent once the data is read into VTK. W On Mon, Apr 20, 2015 at 6:49 AM, Andreas Buykx wrote: > Hi, > > > > Good point about IntersectWithLine. > > I added a IntersectWithLine test to wedge_test.py, and intersect with a > line parallel to the wedge?s axis both from top to bottom and from bottom > to top. I apply the same test to a hexahedron. > > > > Apparently, in VTK6.2.0, the top and bottom parameterized coordinate are > returned for the wedge?s triangles with face-normal pointing inward, but > for the hexahedron?s quadrilaterals with a face-normal pointing outward. > This is consistent with the wedge being defined inside-out. Should this > behavior be changed as well? If not there is an inconsistency between face > orientation and behavior of IntersectWithLine, if it is changed, many > calling filters may yield different results. > > > > Note as well that the documentation of the vtkWedge states that the points > are arranged such that bottom triangle normal points *away* from the > other triangle face, so outward. This in contrast to the vtkHexahedron > where the bottom quadrilateral points *towards* the other face, so > inward. I suppose the definition of the cell will not be changed, that > would have a significant impact for sure. > > > > However, I don?t think though that the cell point ordering is supposed to > be related to the parameterization of the intersection of the faces: given > the cell point ordering the two opposite faces of wedge and hexahedron have > normals that point in the same absolute direction, so one face normal > points inward and one face normal points outward. The IntersectWithLine > implementations return parameterizations that orient the normals either > both inward or both outward. > > > > So, I?m not sure as to what should be done. I think with my change the > face normals are oriented outward, and the intersection point > parameterization should be consistent with that. What are your views? > > > > Kind regards, > > Andreas > > > > *From:* Berk Geveci [mailto:berk.geveci at kitware.com] > *Sent:* vrijdag 17 april 2015 21:21 > *To:* Andreas Buykx; VTK Developers > > *Subject:* Re: [vtk-developers] vtkWedge face node ordering and > vtkUnstructuredGridGeometryFilter > > > > Dear Andreas, > > > > I took a look at your branch. At an initial glance, things look good. I > will dig deeper and also ask for some help in the near future. I have one > question: I noticed that vtkWedge::IntersectWithLine() uses face > information. Did you verify that it still works? > > > > Best, > > -berk > > > > On Wed, Apr 8, 2015 at 4:50 AM, Andreas Buykx > wrote: > > Hi Berk, > > > > I just pushed my work. I think it would be good to add the python script > as well somewhere? > > > > https://gitlab.kitware.com/bxa/vtk/tree/wedge-face-points > > > > Happy holidays, > > Andreas > > > > *From:* Berk Geveci [mailto:berk.geveci at kitware.com] > *Sent:* dinsdag 7 april 2015 18:49 > *To:* Andreas Buykx > > > *Subject:* Re: [vtk-developers] vtkWedge face node ordering and > vtkUnstructuredGridGeometryFilter > > > > Hi Andreas, > > > > Can you please point me to your branch? I am on vacation for the rest of > the week so you may not hear from me for a few days. > > > > Best, > > -berk > > > > On Fri, Apr 3, 2015 at 8:06 AM, Andreas Buykx > wrote: > > Hi, > > All non-linear wedges have the same ordering of face points, causing their > normal to point inward. > > Creating the wedge inside-out seems to work for the > vtkUnstructuredGridGeometryFilter (UGGF) issue, but wouldn't this have side > effects in routines in vtkCell or vtkCell3D, e.g. when interpolating, > contouring, etc? > > From code inspection I found out that for all wedges, the only method that > uses the face point ordering array is the method IntersectWithLine, and > that method seems to be independent of the orientation of the face. > Changing the three methods that return the face points (GetFace and > GetFaceArray) to return properly ordered faces would therefore have the > same net result as changing the order of the points in the faces array. In > both cases all direct and indirect clients (including UGGF) of these > methods may produce different results. However, these differences in > results, if any, are for the better I would say. For example it may not be > necessary anymore to correct normals since they are already oriented > consistently ;-). > > As for documentation, the documentation of vtkWedge does not mention > anything specific about the orientation of face points or face normals, nor > does the vtkCell3D or vtkCell. Also, I couldn't find any definitions of how > face normal are supposed to be oriented in the books (toolkit ed.4, user's > guide ed.11). > > I created a topic in my repository and made the necessary changes in all > wedge classes. The tests that are mentioned for these classes succeed > (cells.py fails because I have no VTKData, and TestCellCentersPointPlacer > spits out some xml related to DartMeasurement which seems not related to > the wedge test). Note that TestCellCentersPointPlacer creates an inverted > wedge. > > How do we proceed? > > Kind regards, > Andreas > > ________________________________________ > From: John Platt [jcplatt at dsl.pipex.com] > Sent: Wednesday, April 01, 2015 10:09 PM > To: Berk Geveci; Andreas Buykx > Cc: vtk-developers at vtk.org > Subject: Re: [vtk-developers] vtkWedge face node ordering and > vtkUnstructuredGridGeometryFilter > > > Hi, > > I think this is also a problem for vtkDataSetSurfaceFilter when mixing > quadratic hex's & wedges. If the actor opacity is reduced, the internal > faces between the hex's & wedges are visible. > > This can be fixed by turning the wedge inside-out i.e. swapping points 1 > & 2 and 4 & 5. The FE system I work with allows both right and left > handed elements so the topology of each element must be checked and > inverted if necessary. > > I agree that the order of the nodes in the face arrays should be changed > to be consistent with the other cells. I suspect this would largely go > unnoticed given the time this inconsistency has been present and the > number of reports on the behaviour. > > Thanks, > > John. > > > > On 01/04/2015 16:42, Berk Geveci wrote: > > Hi Andreas, > > > > Changing the ordering of vtkWedge would be a very large undertaking > > given that there is years of documentation, file formats (in VTK and > > 3rd party), code etc. that depend on a certain ordering. One less > > intrusive way would be to change any vtkWedge methods that returns > > faces to return them in a different order. I suspect this option is > > doable but I'd like to hear from the community. The least intrusive > > options is to fix the few filters that have this issue but I feel like > > it is a band-aid. > > > > Best, > > -berk > > > > On Wed, Apr 1, 2015 at 9:51 AM, Andreas Buykx > wrote: > >> Hi, > >> > >> > >> > >> To detect if coinciding faces of neighbouring 3D cells are connected, > >> vtkUnstructuredGridGeometryFilter walks the points of these faces in > >> opposite directions and expects the point ids to match. This fails for > >> vtkWedge attached to e.g. vtkTetra and vtkHexahedron as demonstrated by > the > >> python script I attach. The root cause is that the > vtkWedge::GetFaceArray > >> and vtkWedge::GetFace return the face points in an ordering that makes > the > >> face normal point into the 3D cell instead of out of the 3D cell, like > all > >> other 3D cells do. The two other algorithms that generate surface cells > >> (vtkDataSetSurfaceFilter and vtkGeometryFilter) don't suffer from this > >> ordering because the former checks point ordering but explicitly allows > both > >> loop directions, and the latter only takes cell connectivity into > account > >> without checking point-ordering at all. > >> > >> > >> > >> I don't know what the reason is to have a different face-point ordering > for > >> the vtkWedge, but one of the other consequences is that the outer > surface > >> will have inconsistent cell normals as can easily be seen when loading > the > >> xml files produced by the tests in paraview, and showing the cell > normals. > >> So I would prefer to change the face-point ordering in vtkWedge. If > that is > >> not possible for some reason then I propose to make/update the > case-blocks > >> in the surface filters cell-type switches to re-order the face-points > for > >> the wedge faces. As long as this is not dealt with our FEA models will > show > >> edges where they should not be so I will have to solve this issue one > way or > >> another, and I'd like to contribute it to VTK as well. > >> > >> > >> > >> Shall I make a mantis issue for this? Who can help me with the > git/gerrit > >> stuff? > >> > >> > >> > >> Thanks a lot, > >> > >> Andreas Buykx > >> > >> ____________________________________________________________ > >> TNO DIANA BV is a limited liability company registered in the trade > register > >> of the Chamber of Commerce as TNO DIANA BV with registered number > 27252655. > >> ____________________________________________________________ > >> This e-mail and its contents are subject to the DISCLAIMER at > >> http://tnodiana.com/content/Disclaimer > >> ____________________________________________________________ > >> > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > >> > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > ____________________________________________________________ > TNO DIANA BV is a limited liability company registered in the trade > register of the Chamber of Commerce as TNO DIANA BV with registered number > 27252655. > ____________________________________________________________ > This e-mail and its contents are subject to the DISCLAIMER at > http://tnodiana.com/content/Disclaimer > ____________________________________________________________ > > > > ____________________________________________________________ > TNO DIANA BV is a limited liability company registered in the trade > register of the Chamber of Commerce as TNO DIANA BV with registered number > 27252655. > ____________________________________________________________ > This e-mail and its contents are subject to the DISCLAIMER at > http://tnodiana.com/content/Disclaimer > ____________________________________________________________ > > > ____________________________________________________________ > TNO DIANA BV is a limited liability company registered in the trade > register of the Chamber of Commerce as TNO DIANA BV with registered number > 27252655. > ____________________________________________________________ > This e-mail and its contents are subject to the DISCLAIMER at > http://tnodiana.com/content/Disclaimer > ____________________________________________________________ > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 hobbsk at ohio.edu Mon Apr 20 15:50:59 2015 From: hobbsk at ohio.edu (Kevin H. Hobbs) Date: Mon, 20 Apr 2015 15:50:59 -0400 Subject: [vtk-developers] Expected Build Change Message-ID: <553558A3.2080708@ohio.edu> The operating system on bubbles and murron has been updated and the build names have been changed to reflect the new OS. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 173 bytes Desc: OpenPGP digital signature URL: From jcplatt at dsl.pipex.com Mon Apr 20 17:20:37 2015 From: jcplatt at dsl.pipex.com (John Platt) Date: Mon, 20 Apr 2015 22:20:37 +0100 Subject: [vtk-developers] vtkWedge face node ordering and vtkUnstructuredGridGeometryFilter In-Reply-To: References: <65D987BE62E58141AA480A59A8B5BBEA6DEAF624@srv-mail.diana.local> <551C5095.7050700@dsl.pipex.com> <65D987BE62E58141AA480A59A8B5BBEA6DEB1705@srv-mail.diana.local> <65D987BE62E58141AA480A59A8B5BBEA6DEB198A@srv-mail.diana.local> <65D987BE62E58141AA480A59A8B5BBEA6DEB3F61@srv-mail.diana.local> Message-ID: <55356DA5.7090001@dsl.pipex.com> Hi Will, I don't think the picture conforms to the parametric coordinates... static double vtkWedgeCellPCoords[18] = {0.0,0.0,0.0, 1.0,0.0,0.0, 0.0,1.0,0.0, 0.0,0.0,1.0, 1.0,0.0,1.0, 0.0,1.0,1.0}; Vectors joining PCoords 0-1, 0-2, 0-3 form a RH set and in this sense it is consistent with the tetrahedron. The problem seems to be with the ordering given internally to the nodes on each face, rather than the cell ordering. John. On 20/04/2015 17:00, Will Schroeder wrote: > Hi Andreas- > > Interesting discussion, I'm sorry that I'm late to the party. Here are > some random items: > > 1. This document is worth viewing if you have not seen it already (on > page 9): > http://ins.uni-bonn.de/teaching/alumni/bebendorf/Praktikum_SS12/vtk_file_formats.pdf > > has a pictorial representation of the point ordering (the vtk.org > link to this file is broken due to our recent rework > of the VTK web pages; I have informed our web people). Note that the > vtkWedge is ordered inconsistently with all other cells as you have > pointed out. I have no idea why: whether it was another cook in the > kitchen or whether a brain was not functioning properly that day. > > 2. As Berk pointed out, changing the point ordering at this late date > is problematic, mainly because lots of people have written files > assuming this ordering. My main concern is to make sure that once the > data is ingested into VTK from that point on the computations are > consistent. This includes filters like > vtkUnstructuredGridGeometryFilter and also all internal methods for > parameterization and topological access. So let's identify the > inconsistencies (I think you've already done most of the work) and > make sure that everything is consistent once the data is read into VTK. > > W > > On Mon, Apr 20, 2015 at 6:49 AM, Andreas Buykx > wrote: > > Hi, > > Good point about IntersectWithLine. > > I added a IntersectWithLine test to wedge_test.py, and intersect > with a line parallel to the wedge?s axis both from top to bottom > and from bottom to top. I apply the same test to a hexahedron. > > Apparently, in VTK6.2.0, the top and bottom parameterized > coordinate are returned for the wedge?s triangles with face-normal > pointing inward, but for the hexahedron?s quadrilaterals with a > face-normal pointing outward. This is consistent with the wedge > being defined inside-out. Should this behavior be changed as well? > If not there is an inconsistency between face orientation and > behavior of IntersectWithLine, if it is changed, many calling > filters may yield different results. > > Note as well that the documentation of the vtkWedge states that > the points are arranged such that bottom triangle normal points > /away/ from the other triangle face, so outward. This in contrast > to the vtkHexahedron where the bottom quadrilateral points > /towards/ the other face, so inward. I suppose the definition of > the cell will not be changed, that would have a significant impact > for sure. > > However, I don?t think though that the cell point ordering is > supposed to be related to the parameterization of the intersection > of the faces: given the cell point ordering the two opposite > faces of wedge and hexahedron have normals that point in the same > absolute direction, so one face normal points inward and one face > normal points outward. The IntersectWithLine implementations > return parameterizations that orient the normals either both > inward or both outward. > > So, I?m not sure as to what should be done. I think with my change > the face normals are oriented outward, and the intersection point > parameterization should be consistent with that. What are your views? > > Kind regards, > > Andreas > > *From:*Berk Geveci [mailto:berk.geveci at kitware.com > ] > *Sent:* vrijdag 17 april 2015 21:21 > *To:* Andreas Buykx; VTK Developers > > > *Subject:* Re: [vtk-developers] vtkWedge face node ordering and > vtkUnstructuredGridGeometryFilter > > Dear Andreas, > > I took a look at your branch. At an initial glance, things look > good. I will dig deeper and also ask for some help in the near > future. I have one question: I noticed > that vtkWedge::IntersectWithLine() uses face information. Did you > verify that it still works? > > Best, > > -berk > > On Wed, Apr 8, 2015 at 4:50 AM, Andreas Buykx > > wrote: > > Hi Berk, > > I just pushed my work. I think it would be good to add the python > script as well somewhere? > > https://gitlab.kitware.com/bxa/vtk/tree/wedge-face-points > > Happy holidays, > > Andreas > > *From:*Berk Geveci [mailto:berk.geveci at kitware.com > ] > *Sent:* dinsdag 7 april 2015 18:49 > *To:* Andreas Buykx > > > *Subject:* Re: [vtk-developers] vtkWedge face node ordering and > vtkUnstructuredGridGeometryFilter > > Hi Andreas, > > Can you please point me to your branch? I am on vacation for the > rest of the week so you may not hear from me for a few days. > > Best, > > -berk > > On Fri, Apr 3, 2015 at 8:06 AM, Andreas Buykx > > wrote: > > Hi, > > All non-linear wedges have the same ordering of face points, > causing their normal to point inward. > > Creating the wedge inside-out seems to work for the > vtkUnstructuredGridGeometryFilter (UGGF) issue, but wouldn't this > have side effects in routines in vtkCell or vtkCell3D, e.g. when > interpolating, contouring, etc? > > >From code inspection I found out that for all wedges, the only > method that uses the face point ordering array is the method > IntersectWithLine, and that method seems to be independent of the > orientation of the face. Changing the three methods that return > the face points (GetFace and GetFaceArray) to return properly > ordered faces would therefore have the same net result as changing > the order of the points in the faces array. In both cases all > direct and indirect clients (including UGGF) of these methods may > produce different results. However, these differences in results, > if any, are for the better I would say. For example it may not be > necessary anymore to correct normals since they are already > oriented consistently ;-). > > As for documentation, the documentation of vtkWedge does not > mention anything specific about the orientation of face points or > face normals, nor does the vtkCell3D or vtkCell. Also, I couldn't > find any definitions of how face normal are supposed to be > oriented in the books (toolkit ed.4, user's guide ed.11). > > I created a topic in my repository and made the necessary changes > in all wedge classes. The tests that are mentioned for these > classes succeed (cells.py fails because I have no VTKData, and > TestCellCentersPointPlacer spits out some xml related to > DartMeasurement which seems not related to the wedge test). Note > that TestCellCentersPointPlacer creates an inverted wedge. > > How do we proceed? > > Kind regards, > Andreas > > ________________________________________ > From: John Platt [jcplatt at dsl.pipex.com > ] > Sent: Wednesday, April 01, 2015 10:09 PM > To: Berk Geveci; Andreas Buykx > Cc: vtk-developers at vtk.org > Subject: Re: [vtk-developers] vtkWedge face node ordering and > vtkUnstructuredGridGeometryFilter > > > Hi, > > I think this is also a problem for vtkDataSetSurfaceFilter when mixing > quadratic hex's & wedges. If the actor opacity is reduced, the > internal > faces between the hex's & wedges are visible. > > This can be fixed by turning the wedge inside-out i.e. swapping > points 1 > & 2 and 4 & 5. The FE system I work with allows both right and left > handed elements so the topology of each element must be checked and > inverted if necessary. > > I agree that the order of the nodes in the face arrays should be > changed > to be consistent with the other cells. I suspect this would largely go > unnoticed given the time this inconsistency has been present and the > number of reports on the behaviour. > > Thanks, > > John. > > > > On 01/04/2015 16:42, Berk Geveci wrote: > > Hi Andreas, > > > > Changing the ordering of vtkWedge would be a very large undertaking > > given that there is years of documentation, file formats (in VTK and > > 3rd party), code etc. that depend on a certain ordering. One less > > intrusive way would be to change any vtkWedge methods that returns > > faces to return them in a different order. I suspect this option is > > doable but I'd like to hear from the community. The least intrusive > > options is to fix the few filters that have this issue but I > feel like > > it is a band-aid. > > > > Best, > > -berk > > > > On Wed, Apr 1, 2015 at 9:51 AM, Andreas Buykx > > wrote: > >> Hi, > >> > >> > >> > >> To detect if coinciding faces of neighbouring 3D cells are > connected, > >> vtkUnstructuredGridGeometryFilter walks the points of these > faces in > >> opposite directions and expects the point ids to match. This > fails for > >> vtkWedge attached to e.g. vtkTetra and vtkHexahedron as > demonstrated by the > >> python script I attach. The root cause is that the > vtkWedge::GetFaceArray > >> and vtkWedge::GetFace return the face points in an ordering > that makes the > >> face normal point into the 3D cell instead of out of the 3D > cell, like all > >> other 3D cells do. The two other algorithms that generate > surface cells > >> (vtkDataSetSurfaceFilter and vtkGeometryFilter) don't suffer > from this > >> ordering because the former checks point ordering but > explicitly allows both > >> loop directions, and the latter only takes cell connectivity > into account > >> without checking point-ordering at all. > >> > >> > >> > >> I don't know what the reason is to have a different face-point > ordering for > >> the vtkWedge, but one of the other consequences is that the > outer surface > >> will have inconsistent cell normals as can easily be seen when > loading the > >> xml files produced by the tests in paraview, and showing the > cell normals. > >> So I would prefer to change the face-point ordering in > vtkWedge. If that is > >> not possible for some reason then I propose to make/update the > case-blocks > >> in the surface filters cell-type switches to re-order the > face-points for > >> the wedge faces. As long as this is not dealt with our FEA > models will show > >> edges where they should not be so I will have to solve this > issue one way or > >> another, and I'd like to contribute it to VTK as well. > >> > >> > >> > >> Shall I make a mantis issue for this? Who can help me with the > git/gerrit > >> stuff? > >> > >> > >> > >> Thanks a lot, > >> > >> Andreas Buykx > >> > >> ____________________________________________________________ > >> TNO DIANA BV is a limited liability company registered in the > trade register > >> of the Chamber of Commerce as TNO DIANA BV with registered > number 27252655. > >> ____________________________________________________________ > >> This e-mail and its contents are subject to the DISCLAIMER at > >> http://tnodiana.com/content/Disclaimer > >> ____________________________________________________________ > >> > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > >> > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > > > Follow this link to subscribe/unsubscribe: > > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > ____________________________________________________________ > TNO DIANA BV is a limited liability company registered in the > trade register of the Chamber of Commerce as TNO DIANA BV with > registered number 27252655. > ____________________________________________________________ > This e-mail and its contents are subject to the DISCLAIMER at > http://tnodiana.com/content/Disclaimer > ____________________________________________________________ > > ____________________________________________________________ > TNO DIANA BV is a limited liability company registered in the > trade register of the Chamber of Commerce as TNO DIANA BV with > registered number 27252655. > ____________________________________________________________ > This e-mail and its contents are subject to the DISCLAIMER at > http://tnodiana.com/content/Disclaimer > ____________________________________________________________ > > ____________________________________________________________ > TNO DIANA BV is a limited liability company registered in the > trade register of the Chamber of Commerce as TNO DIANA BV with > registered number 27252655. > ____________________________________________________________ > This e-mail and its contents are subject to the DISCLAIMER at > http://tnodiana.com/content/Disclaimer > ____________________________________________________________ > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 aashish.chaudhary at kitware.com Tue Apr 21 10:45:48 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Tue, 21 Apr 2015 10:45:48 -0400 Subject: [vtk-developers] Volume rendering update Message-ID: Hi All, We have made several improvements to the volume rendering engine in the last few months and will be pushing more changes to VTK in the next two weeks. Below is a quick summary of our work. Your suggestions and contributions are welcome and encouraged. We are also planning a blog by the end of this month with performance numbers to cover some detail on the work done as part of the VTK rendering improvements. Most Recent Updates: - Added support for multiple component (2, 3, 4) independent components and 2 dependent components - Fixed cropping issues and fixed related tests - Fixed a bug which result in a crash when context changes Other Updates - Fixed various mac issues - Improved interactive performance for large volumes - Fixed extents not getting updated issues in presence of other filters - Fixed window color adjustments issues. - Fixed issue with noise textures - Added volume rendering benchmarking tests - Added new volume tests. Now testing various features where were not tested before (52 volume tests now) - Fixed resources not releasing issues - vtkVolume now uses vtkTextureObject - Using the shader cache for volume rendering - 99 % tests are passing on Mac/Linux and Windows. Work in Progress - Fixing 2 and 3 independent component tests on a particular dashboard that uses Mesa GL - Looking into some very specific rendering performance issues specifically on Mac - New blog post on volume rendering -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.kilgus at Dkfz-Heidelberg.de Wed Apr 22 09:57:58 2015 From: t.kilgus at Dkfz-Heidelberg.de (Kilgus, Thomas) Date: Wed, 22 Apr 2015 15:57:58 +0200 Subject: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? Message-ID: <57EE86D11538B44096C712532DBB6C5A012EF2AC55A3@DKFZEX01.ad.dkfz-heidelberg.de> Hi everyone, we recently switched to VTK 6.2 and there is no more anti-aliasing in any renderwindow. If you compare the output to VTK 6.1 you will see significant differences. See attached screenshot. This can be reproduced with the STL read example [3] and setting the rendering property to wireframe like this: actor->GetProperty()->SetRepresentationToWireframe(); I figured out that anti-aliasing can be enabled again with: renderWindow->SetLineSmoothing(1); The following call, which I would assume to be necessary, has no effect: renderWindow->SetMultiSamples(8); I could not find anything in the documentation about this. Is this change desired? Is this a bug? To avoid confusion: We had a similar issue when switching to the QVTKWidget2, which we are not using now different reasons. See [1] for older mails and [2] for a patch. This seems to be another issue though. Regards, Thomas [1] http://vtk.1045678.n5.nabble.com/Anti-aliasing-multi-sampling-in-QVTKWidget2-td5730077.html [2] http://review.source.kitware.com/#/c/18864/ [3] http://www.vtk.org/Wiki/VTK/Examples/Cxx/IO/ReadSTL Thomas Kilgus German Cancer Research Center (DKFZ) Div. Medical and Biological Informatics Junior group: Computer-assisted Interventions (E131) Im Neuenheimer Feld 280 69120 Heidelberg, Germany Phone: +49(0) 6221-42-3545 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: antialiasing.png Type: image/png Size: 40536 bytes Desc: antialiasing.png URL: From david.lonie at kitware.com Wed Apr 22 10:34:14 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 22 Apr 2015 10:34:14 -0400 Subject: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? In-Reply-To: <57EE86D11538B44096C712532DBB6C5A012EF2AC55A3@DKFZEX01.ad.dkfz-heidelberg.de> References: <57EE86D11538B44096C712532DBB6C5A012EF2AC55A3@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: Are you using offscreen rendering, by any chance? There is a known issue that the MultiSampling options are not currently respected for some offscreen window implementations. Dave On Wed, Apr 22, 2015 at 9:57 AM, Kilgus, Thomas wrote: > Hi everyone, > > > > we recently switched to VTK 6.2 and there is no more anti-aliasing in any > renderwindow. If you compare the output to VTK 6.1 you will see significant > differences. See attached screenshot. This can be reproduced with the STL > read example [3] and setting the rendering property to wireframe like this: > > actor->GetProperty()->SetRepresentationToWireframe(); > > > > I figured out that anti-aliasing can be enabled again with: > > renderWindow->SetLineSmoothing(1); > > > > The following call, which I would assume to be necessary, has no effect: > > renderWindow->SetMultiSamples(8); > > > > I could not find anything in the documentation about this. Is this change > desired? Is this a bug? > > > > To avoid confusion: We had a similar issue when switching to the > QVTKWidget2, which we are not using now different reasons. See [1] for > older mails and [2] for a patch. This seems to be another issue though. > > > > Regards, > > Thomas > > > > > > [1] > http://vtk.1045678.n5.nabble.com/Anti-aliasing-multi-sampling-in-QVTKWidget2-td5730077.html > > [2] http://review.source.kitware.com/#/c/18864/ > > [3] http://www.vtk.org/Wiki/VTK/Examples/Cxx/IO/ReadSTL > > > > > > Thomas Kilgus > > German Cancer Research Center (DKFZ) > > Div. Medical and Biological Informatics > > Junior group: Computer-assisted Interventions (E131) > > Im Neuenheimer Feld 280 > > 69120 Heidelberg, Germany > > Phone: +49(0) 6221-42-3545 > > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 t.kilgus at Dkfz-Heidelberg.de Wed Apr 22 10:43:56 2015 From: t.kilgus at Dkfz-Heidelberg.de (Kilgus, Thomas) Date: Wed, 22 Apr 2015 16:43:56 +0200 Subject: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? In-Reply-To: References: <57EE86D11538B44096C712532DBB6C5A012EF2AC55A3@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: <57EE86D11538B44096C712532DBB6C5A012EF2AC55BA@DKFZEX01.ad.dkfz-heidelberg.de> No, just the regular VTK example. Is this feature working for you? Thomas Von: David Lonie [mailto:david.lonie at kitware.com] Gesendet: Mittwoch, 22. April 2015 16:34 An: Kilgus, Thomas Cc: vtk-developers at vtk.org Betreff: Re: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? Are you using offscreen rendering, by any chance? There is a known issue that the MultiSampling options are not currently respected for some offscreen window implementations. Dave On Wed, Apr 22, 2015 at 9:57 AM, Kilgus, Thomas > wrote: Hi everyone, we recently switched to VTK 6.2 and there is no more anti-aliasing in any renderwindow. If you compare the output to VTK 6.1 you will see significant differences. See attached screenshot. This can be reproduced with the STL read example [3] and setting the rendering property to wireframe like this: actor->GetProperty()->SetRepresentationToWireframe(); I figured out that anti-aliasing can be enabled again with: renderWindow->SetLineSmoothing(1); The following call, which I would assume to be necessary, has no effect: renderWindow->SetMultiSamples(8); I could not find anything in the documentation about this. Is this change desired? Is this a bug? To avoid confusion: We had a similar issue when switching to the QVTKWidget2, which we are not using now different reasons. See [1] for older mails and [2] for a patch. This seems to be another issue though. Regards, Thomas [1] http://vtk.1045678.n5.nabble.com/Anti-aliasing-multi-sampling-in-QVTKWidget2-td5730077.html [2] http://review.source.kitware.com/#/c/18864/ [3] http://www.vtk.org/Wiki/VTK/Examples/Cxx/IO/ReadSTL Thomas Kilgus German Cancer Research Center (DKFZ) Div. Medical and Biological Informatics Junior group: Computer-assisted Interventions (E131) Im Neuenheimer Feld 280 69120 Heidelberg, Germany Phone: +49(0) 6221-42-3545 _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the 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.lonie at kitware.com Wed Apr 22 10:55:00 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 22 Apr 2015 10:55:00 -0400 Subject: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? In-Reply-To: <57EE86D11538B44096C712532DBB6C5A012EF2AC55BA@DKFZEX01.ad.dkfz-heidelberg.de> References: <57EE86D11538B44096C712532DBB6C5A012EF2AC55A3@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC55BA@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: On Wed, Apr 22, 2015 at 10:43 AM, Kilgus, Thomas < t.kilgus at dkfz-heidelberg.de> wrote: > No, just the regular VTK example. Is this feature working for you? > I've been using on-screen multisampling on the current dev branch without issues. Not sure what else would be causing this. Can you open a bug report for this? Best if you can include a short script that reproduces the issue and details about your operating system. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Wed Apr 22 11:46:37 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 22 Apr 2015 11:46:37 -0400 Subject: [vtk-developers] Expected Build Change In-Reply-To: <553558A3.2080708@ohio.edu> References: <553558A3.2080708@ohio.edu> Message-ID: Kevin, I've updated those entries in the dependencies track. thanks for the testers and the heads up David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Mon, Apr 20, 2015 at 3:50 PM, Kevin H. Hobbs wrote: > The operating system on bubbles and murron has been updated and the > build names have been changed to reflect the new OS. > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Apr 22 15:55:43 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 22 Apr 2015 15:55:43 -0400 Subject: [vtk-developers] libvtkRenderingFreeTypeOpenGL gone? Message-ID: <20150422195543.147555727@mail.rogue-research.com> Hi all, When I build VTK 6.2, one of the resulting libs is "lvtkRenderingFreeTypeOpenGL.a". I've just built git master and that library doesn't seem to be built anymore. Is that expected/normal? 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 bill.lorensen at gmail.com Wed Apr 22 16:08:29 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 22 Apr 2015 16:08:29 -0400 Subject: [vtk-developers] libvtkRenderingFreeTypeOpenGL gone? In-Reply-To: <20150422195543.147555727@mail.rogue-research.com> References: <20150422195543.147555727@mail.rogue-research.com> Message-ID: Yes, it has been removed. On Wed, Apr 22, 2015 at 3:55 PM, Sean McBride wrote: > Hi all, > > When I build VTK 6.2, one of the resulting libs is "lvtkRenderingFreeTypeOpenGL.a". I've just built git master and that library doesn't seem to be built anymore. Is that expected/normal? > > 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 > -- Unpaid intern in BillsBasement at noware dot com From david.gobbi at gmail.com Wed Apr 22 16:08:51 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 22 Apr 2015 14:08:51 -0600 Subject: [vtk-developers] libvtkRenderingFreeTypeOpenGL gone? In-Reply-To: <20150422195543.147555727@mail.rogue-research.com> References: <20150422195543.147555727@mail.rogue-research.com> Message-ID: Hi Sean, Yeah, that library has been gone for a week or so. Just yesterday, I finally repaired my own cmake scripts to compensate for this, and also to allow for OpenGL2 compilation: # These are the libraries that we absolutely need to link to set(VTK_LIBS vtkRenderingCore vtkRenderingImage vtkInteractionStyle vtkRenderingFreeType vtkIOImage vtkIOMINC vtkIOLegacy vtkImagingStencil vtkImagingStatistics vtksys) # These are libraries that we link to, only if they are present set(VTK_EXTRA_LIBS vtkIOMPIImage vtkRenderingOpenGL vtkRenderingFreeTypeOpenGL vtkRenderingOpenGL2 vtkRenderingFreeTypeOpenGL2) # Check for the existence of each of the EXTRA libs foreach(TMP_LIB ${VTK_EXTRA_LIBS}) list(FIND VTK_LIBRARIES ${TMP_LIB} TMP_INDEX) if(TMP_INDEX GREATER -1) set(VTK_LIBS ${VTK_LIBS} ${TMP_LIB}) endif() endforeach() # Now use VTK_LIBS in target_link_libraries() - David On Wed, Apr 22, 2015 at 1:55 PM, Sean McBride wrote: > Hi all, > > When I build VTK 6.2, one of the resulting libs is > "lvtkRenderingFreeTypeOpenGL.a". I've just built git master and that > library doesn't seem to be built anymore. Is that expected/normal? > > Cheers, > -------------- next part -------------- An HTML attachment was scrubbed... URL: From t.kilgus at Dkfz-Heidelberg.de Thu Apr 23 05:22:35 2015 From: t.kilgus at Dkfz-Heidelberg.de (Kilgus, Thomas) Date: Thu, 23 Apr 2015 11:22:35 +0200 Subject: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? In-Reply-To: References: <57EE86D11538B44096C712532DBB6C5A012EF2AC55A3@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC55BA@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: <57EE86D11538B44096C712532DBB6C5A012EF2AC561F@DKFZEX01.ad.dkfz-heidelberg.de> Hi David, I filed a bug report: http://www.vtk.org/Bug/view.php?id=15433 We have this issue on various operating systems. I explained everything in mantis and added a file to reproduce it. In general, you could checkout the tag v6.2.0 and open any renderwindow which contains lots lines, such as a surface rendered as wireframe. I would be really surprised if this is not reproducible on that commit for you. Regards, Thomas Von: David Lonie [mailto:david.lonie at kitware.com] Gesendet: Mittwoch, 22. April 2015 16:55 An: Kilgus, Thomas Cc: vtk-developers at vtk.org Betreff: Re: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? On Wed, Apr 22, 2015 at 10:43 AM, Kilgus, Thomas > wrote: No, just the regular VTK example. Is this feature working for you? I've been using on-screen multisampling on the current dev branch without issues. Not sure what else would be causing this. Can you open a bug report for this? Best if you can include a short script that reproduces the issue and details about your operating system. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Apr 23 06:41:22 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 23 Apr 2015 06:41:22 -0400 Subject: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? In-Reply-To: <57EE86D11538B44096C712532DBB6C5A012EF2AC561F@DKFZEX01.ad.dkfz-heidelberg.de> References: <57EE86D11538B44096C712532DBB6C5A012EF2AC55A3@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC55BA@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC561F@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: That looks like it could just be a lighting or color difference... Both images appear anti-aliased to my eye, but the exact coloring of the lines is definitely different. On Thu, Apr 23, 2015 at 5:22 AM, Kilgus, Thomas wrote: > Hi David, > > > > I filed a bug report: http://www.vtk.org/Bug/view.php?id=15433 > > > > We have this issue on various operating systems. I explained everything in > mantis and added a file to reproduce it. In general, you could checkout the > tag v6.2.0 and open any renderwindow which contains lots lines, such as a > surface rendered as wireframe. I would be really surprised if this is not > reproducible on that commit for you. > > > > Regards, > > Thomas > > > > Von: David Lonie [mailto:david.lonie at kitware.com] > Gesendet: Mittwoch, 22. April 2015 16:55 > An: Kilgus, Thomas > Cc: vtk-developers at vtk.org > Betreff: Re: [vtk-developers] Anti-aliasing / multi sampling turned off in > VTK 6.2? > > > > On Wed, Apr 22, 2015 at 10:43 AM, Kilgus, Thomas > wrote: > > No, just the regular VTK example. Is this feature working for you? > > > > I've been using on-screen multisampling on the current dev branch without > issues. Not sure what else would be causing this. > > > > Can you open a bug report for this? Best if you can include a short script > that reproduces the issue and details about your operating system. > > > > Dave > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 t.kilgus at Dkfz-Heidelberg.de Thu Apr 23 08:38:04 2015 From: t.kilgus at Dkfz-Heidelberg.de (Kilgus, Thomas) Date: Thu, 23 Apr 2015 14:38:04 +0200 Subject: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? In-Reply-To: References: <57EE86D11538B44096C712532DBB6C5A012EF2AC55A3@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC55BA@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC561F@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: <57EE86D11538B44096C712532DBB6C5A012EF2AC5653@DKFZEX01.ad.dkfz-heidelberg.de> Ah it's very tricky to make a nice screen shot of anti-aliasing... I attached another version in mantis named AntiAliasingOff.png. I hope it becomes clear now. It is obvious if you build the example. -----Urspr?ngliche Nachricht----- Von: David Cole [mailto:DLRdave at aol.com] Gesendet: Donnerstag, 23. April 2015 12:41 An: Kilgus, Thomas Cc: David Lonie; vtk-developers at vtk.org Betreff: Re: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? That looks like it could just be a lighting or color difference... Both images appear anti-aliased to my eye, but the exact coloring of the lines is definitely different. On Thu, Apr 23, 2015 at 5:22 AM, Kilgus, Thomas wrote: > Hi David, > > > > I filed a bug report: http://www.vtk.org/Bug/view.php?id=15433 > > > > We have this issue on various operating systems. I explained > everything in mantis and added a file to reproduce it. In general, you > could checkout the tag v6.2.0 and open any renderwindow which contains > lots lines, such as a surface rendered as wireframe. I would be really > surprised if this is not reproducible on that commit for you. > > > > Regards, > > Thomas > > > > Von: David Lonie [mailto:david.lonie at kitware.com] > Gesendet: Mittwoch, 22. April 2015 16:55 > An: Kilgus, Thomas > Cc: vtk-developers at vtk.org > Betreff: Re: [vtk-developers] Anti-aliasing / multi sampling turned > off in VTK 6.2? > > > > On Wed, Apr 22, 2015 at 10:43 AM, Kilgus, Thomas > wrote: > > No, just the regular VTK example. Is this feature working for you? > > > > I've been using on-screen multisampling on the current dev branch > without issues. Not sure what else would be causing this. > > > > Can you open a bug report for this? Best if you can include a short > script that reproduces the issue and details about your operating system. > > > > Dave > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From DLRdave at aol.com Thu Apr 23 08:48:43 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 23 Apr 2015 08:48:43 -0400 Subject: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? In-Reply-To: <57EE86D11538B44096C712532DBB6C5A012EF2AC5653@DKFZEX01.ad.dkfz-heidelberg.de> References: <57EE86D11538B44096C712532DBB6C5A012EF2AC55A3@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC55BA@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC561F@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC5653@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: OK -- I do see it in the AntiAliasingOff png file. On Thu, Apr 23, 2015 at 8:38 AM, Kilgus, Thomas wrote: > Ah it's very tricky to make a nice screen shot of anti-aliasing... I attached another version in mantis named AntiAliasingOff.png. I hope it becomes clear now. It is obvious if you build the example. > > > -----Urspr?ngliche Nachricht----- > Von: David Cole [mailto:DLRdave at aol.com] > Gesendet: Donnerstag, 23. April 2015 12:41 > An: Kilgus, Thomas > Cc: David Lonie; vtk-developers at vtk.org > Betreff: Re: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? > > That looks like it could just be a lighting or color difference... > Both images appear anti-aliased to my eye, but the exact coloring of the lines is definitely different. > > > On Thu, Apr 23, 2015 at 5:22 AM, Kilgus, Thomas wrote: >> Hi David, >> >> >> >> I filed a bug report: http://www.vtk.org/Bug/view.php?id=15433 >> >> >> >> We have this issue on various operating systems. I explained >> everything in mantis and added a file to reproduce it. In general, you >> could checkout the tag v6.2.0 and open any renderwindow which contains >> lots lines, such as a surface rendered as wireframe. I would be really >> surprised if this is not reproducible on that commit for you. >> >> >> >> Regards, >> >> Thomas >> >> >> >> Von: David Lonie [mailto:david.lonie at kitware.com] >> Gesendet: Mittwoch, 22. April 2015 16:55 >> An: Kilgus, Thomas >> Cc: vtk-developers at vtk.org >> Betreff: Re: [vtk-developers] Anti-aliasing / multi sampling turned >> off in VTK 6.2? >> >> >> >> On Wed, Apr 22, 2015 at 10:43 AM, Kilgus, Thomas >> wrote: >> >> No, just the regular VTK example. Is this feature working for you? >> >> >> >> I've been using on-screen multisampling on the current dev branch >> without issues. Not sure what else would be causing this. >> >> >> >> Can you open a bug report for this? Best if you can include a short >> script that reproduces the issue and details about your operating system. >> >> >> >> Dave >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the 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 t.kilgus at Dkfz-Heidelberg.de Thu Apr 23 08:53:20 2015 From: t.kilgus at Dkfz-Heidelberg.de (Kilgus, Thomas) Date: Thu, 23 Apr 2015 14:53:20 +0200 Subject: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? In-Reply-To: References: <57EE86D11538B44096C712532DBB6C5A012EF2AC55A3@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC55BA@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC561F@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC5653@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: <57EE86D11538B44096C712532DBB6C5A012EF2AC5657@DKFZEX01.ad.dkfz-heidelberg.de> Oh great, at least it is now visible. Do you have any build to reproduce this? -----Urspr?ngliche Nachricht----- Von: David Cole [mailto:DLRdave at aol.com] Gesendet: Donnerstag, 23. April 2015 14:49 An: Kilgus, Thomas Cc: David Lonie; vtk-developers at vtk.org Betreff: Re: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? OK -- I do see it in the AntiAliasingOff png file. On Thu, Apr 23, 2015 at 8:38 AM, Kilgus, Thomas wrote: > Ah it's very tricky to make a nice screen shot of anti-aliasing... I attached another version in mantis named AntiAliasingOff.png. I hope it becomes clear now. It is obvious if you build the example. > > > -----Urspr?ngliche Nachricht----- > Von: David Cole [mailto:DLRdave at aol.com] > Gesendet: Donnerstag, 23. April 2015 12:41 > An: Kilgus, Thomas > Cc: David Lonie; vtk-developers at vtk.org > Betreff: Re: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? > > That looks like it could just be a lighting or color difference... > Both images appear anti-aliased to my eye, but the exact coloring of the lines is definitely different. > > > On Thu, Apr 23, 2015 at 5:22 AM, Kilgus, Thomas wrote: >> Hi David, >> >> >> >> I filed a bug report: http://www.vtk.org/Bug/view.php?id=15433 >> >> >> >> We have this issue on various operating systems. I explained >> everything in mantis and added a file to reproduce it. In general, >> you could checkout the tag v6.2.0 and open any renderwindow which >> contains lots lines, such as a surface rendered as wireframe. I would >> be really surprised if this is not reproducible on that commit for you. >> >> >> >> Regards, >> >> Thomas >> >> >> >> Von: David Lonie [mailto:david.lonie at kitware.com] >> Gesendet: Mittwoch, 22. April 2015 16:55 >> An: Kilgus, Thomas >> Cc: vtk-developers at vtk.org >> Betreff: Re: [vtk-developers] Anti-aliasing / multi sampling turned >> off in VTK 6.2? >> >> >> >> On Wed, Apr 22, 2015 at 10:43 AM, Kilgus, Thomas >> wrote: >> >> No, just the regular VTK example. Is this feature working for you? >> >> >> >> I've been using on-screen multisampling on the current dev branch >> without issues. Not sure what else would be causing this. >> >> >> >> Can you open a bug report for this? Best if you can include a short >> script that reproduces the issue and details about your operating system. >> >> >> >> Dave >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the 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 david.lonie at kitware.com Thu Apr 23 09:12:21 2015 From: david.lonie at kitware.com (David Lonie) Date: Thu, 23 Apr 2015 09:12:21 -0400 Subject: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? In-Reply-To: <57EE86D11538B44096C712532DBB6C5A012EF2AC5657@DKFZEX01.ad.dkfz-heidelberg.de> References: <57EE86D11538B44096C712532DBB6C5A012EF2AC55A3@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC55BA@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC561F@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC5653@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC5657@DKFZEX01.ad.dkfz-heidelberg.de> Message-ID: I can reproduce this on current master using the test script in the bug report. Something is definitely broken... Dave On Thu, Apr 23, 2015 at 8:53 AM, Kilgus, Thomas wrote: > Oh great, at least it is now visible. Do you have any build to reproduce > this? > > -----Urspr?ngliche Nachricht----- > Von: David Cole [mailto:DLRdave at aol.com] > Gesendet: Donnerstag, 23. April 2015 14:49 > An: Kilgus, Thomas > Cc: David Lonie; vtk-developers at vtk.org > Betreff: Re: [vtk-developers] Anti-aliasing / multi sampling turned off in > VTK 6.2? > > OK -- I do see it in the AntiAliasingOff png file. > > On Thu, Apr 23, 2015 at 8:38 AM, Kilgus, Thomas < > t.kilgus at dkfz-heidelberg.de> wrote: > > Ah it's very tricky to make a nice screen shot of anti-aliasing... I > attached another version in mantis named AntiAliasingOff.png. I hope it > becomes clear now. It is obvious if you build the example. > > > > > > -----Urspr?ngliche Nachricht----- > > Von: David Cole [mailto:DLRdave at aol.com] > > Gesendet: Donnerstag, 23. April 2015 12:41 > > An: Kilgus, Thomas > > Cc: David Lonie; vtk-developers at vtk.org > > Betreff: Re: [vtk-developers] Anti-aliasing / multi sampling turned off > in VTK 6.2? > > > > That looks like it could just be a lighting or color difference... > > Both images appear anti-aliased to my eye, but the exact coloring of the > lines is definitely different. > > > > > > On Thu, Apr 23, 2015 at 5:22 AM, Kilgus, Thomas < > t.kilgus at dkfz-heidelberg.de> wrote: > >> Hi David, > >> > >> > >> > >> I filed a bug report: http://www.vtk.org/Bug/view.php?id=15433 > >> > >> > >> > >> We have this issue on various operating systems. I explained > >> everything in mantis and added a file to reproduce it. In general, > >> you could checkout the tag v6.2.0 and open any renderwindow which > >> contains lots lines, such as a surface rendered as wireframe. I would > >> be really surprised if this is not reproducible on that commit for you. > >> > >> > >> > >> Regards, > >> > >> Thomas > >> > >> > >> > >> Von: David Lonie [mailto:david.lonie at kitware.com] > >> Gesendet: Mittwoch, 22. April 2015 16:55 > >> An: Kilgus, Thomas > >> Cc: vtk-developers at vtk.org > >> Betreff: Re: [vtk-developers] Anti-aliasing / multi sampling turned > >> off in VTK 6.2? > >> > >> > >> > >> On Wed, Apr 22, 2015 at 10:43 AM, Kilgus, Thomas > >> wrote: > >> > >> No, just the regular VTK example. Is this feature working for you? > >> > >> > >> > >> I've been using on-screen multisampling on the current dev branch > >> without issues. Not sure what else would be causing this. > >> > >> > >> > >> Can you open a bug report for this? Best if you can include a short > >> script that reproduces the issue and details about your operating > system. > >> > >> > >> > >> Dave > >> > >> > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the 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 joachim.pouderoux at kitware.com Thu Apr 23 10:15:16 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Thu, 23 Apr 2015 16:15:16 +0200 Subject: [vtk-developers] announce: VTK/ParaView Training - June 2 and 3, 2015, Lyon, France Message-ID: Kitware will be holding VTK and ParaView training courses respectively on June 2 and 3 in Lyon, France. Please visit our web site for more information and registration details at: VTK: http://training.kitware.fr/browse/102 ParaView: http://training.kitware.fr/browse/104 Note that the courses will be taught in English. If you have any question, please contact us at! formations at http://www.kitware.fr Thank you, *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Thu Apr 23 11:26:19 2015 From: sean at rogue-research.com (Sean McBride) Date: Thu, 23 Apr 2015 11:26:19 -0400 Subject: [vtk-developers] Anti-aliasing / multi sampling turned off in VTK 6.2? In-Reply-To: References: <57EE86D11538B44096C712532DBB6C5A012EF2AC55A3@DKFZEX01.ad.dkfz-heidelberg.de> <57EE86D11538B44096C712532DBB6C5A012EF2AC55BA@DKFZEX01.ad.dkfz-heidelberg.de > <57EE86D11538B44096C712532DBB6C5A012EF2AC561F@DKFZEX01.ad.dkfz-heidelberg.de > <57EE86D11538B44096C712532DBB6C5A012EF2AC5653@DKFZEX01.ad.dkfz-heidelberg.de > <57EE86D11538B44096C712532DBB6C5A012EF2AC5657@DKFZEX01.ad.dkfz-heidelberg.de > Message-ID: <20150423152619.104100079@mail.rogue-research.com> On Thu, 23 Apr 2015 09:12:21 -0400, David Lonie said: >I can reproduce this on current master using the test script in the bug >report. Something is definitely broken... You could always 'git bisect' it to see exactly where it started giving different results. 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 e.tadeu at gmail.com Thu Apr 23 11:44:02 2015 From: e.tadeu at gmail.com (E. Tadeu) Date: Thu, 23 Apr 2015 12:44:02 -0300 Subject: [vtk-developers] Crash related to vtkRenderWindow::SetOffScreenRendering Message-ID: Hi, there is a crash in VTK 6 that seems related to setting off-screen rendering to On, and then to Off again. This is a simple failing test case: ``` def test_off_screen_rendering_bug(): import vtk renderer = vtk.vtkRenderer() render_window = vtk.vtkRenderWindow() render_window.AddRenderer(renderer) render_window.Render() render_window.SetOffScreenRendering(True) render_window.SetOffScreenRendering(False) # <-- Problem happens here assert render_window.GetRenderers().GetFirstRenderer().GetRenderWindow() is not None render_window.Render() # <-- Crashes here if the assert above is commented out. ``` The RenderWindow pointer of the renderers are being set to NULL in the `render_window.SetOffScreenRendering(False)` call. Note: this is only happening when the attribute OffScreenUseFrameBuffer is 0, because SetOffScreenRendering is invoking CleanUpOffScreenRendering, which is invoking CleanUpRenderers, which sets the RenderWindow to NULL and then it is never attributed back to a valid value (because ContextId is also set to 0, and ResumeScreenRendering only restores the RenderWindow when ContextId != 0). OffScreenUseFrameBuffer is kept as 0 when CreateHardwareOffScreenWindow fails (probably because OpenGL framebuffer extension is also disabled). So, in order to really reproduce this, the framebuffer must be disabled (using remote desktop connection seems to do this). This used to work on older versions, so I've tried to trace what changes possibly led to this problem, and I got these commits: https://gitlab.kitware.com/vtk/vtk/commit/9b6f235663f5db37455a26ea77647a3f693e5f8d Authored by: Clinton Stimpson 7 years ago ENH: Don't leave the vtkRenderer's RenderWindow NULL after reparenting the vtkRenderWindow. Making modifications (add/remove 3D widgets) before the next render would lead to crashes. https://gitlab.kitware.com/vtk/vtk/commit/a6fa3e375c17771864345763ae2283d47be7aae8 Authored by: Burlen Loring 2 years ago OpenGL error hunt This patch implements OpenGL error checking in VTK. (...) https://gitlab.kitware.com/vtk/vtk/commit/f7f82536aa867acc64b9a458c60810dd3fbf2b00 Authored by: Utkarsh Ayachit 2 years ago Fixed regression introduced by a6fa3e375c. (It seems that the regression was not completely fixed). I've already reported it here: http://www.paraview.org/Bug/view.php?id=15435 Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Fri Apr 24 12:04:06 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Fri, 24 Apr 2015 18:04:06 +0200 Subject: [vtk-developers] Compiling VTK as a single library Message-ID: Hello, For some reasons I had to modify my local copy of VTK CMake scripts in order to generate a single libVTK.so/a (or VTK.dll/lib under Windows). Of course there are pro and cons to this but this is available through a CMake option. Do you think this feature should be pushed in VTK or not? Joachim *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Fri Apr 24 12:24:48 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 24 Apr 2015 10:24:48 -0600 Subject: [vtk-developers] Compiling VTK as a single library In-Reply-To: References: Message-ID: I seem to remember that this used to be an option, way back in VTK 2.x and VTK 3.x. It's definitely a nice feature, but how much complexity does it add to the CMake code? - David On Fri, Apr 24, 2015 at 10:04 AM, Joachim Pouderoux < joachim.pouderoux at kitware.com> wrote: > Hello, > > For some reasons I had to modify my local copy of VTK CMake scripts in > order to generate a single libVTK.so/a (or VTK.dll/lib under Windows). Of > course there are pro and cons to this but this is available through a CMake > option. > > Do you think this feature should be pushed in VTK or not? > > Joachim > > *Joachim Pouderoux* > > *PhD, Technical Expert* > *Kitware SAS * > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Fri Apr 24 13:04:07 2015 From: sean at rogue-research.com (Sean McBride) Date: Fri, 24 Apr 2015 13:04:07 -0400 Subject: [vtk-developers] Compiling VTK as a single library In-Reply-To: References: Message-ID: <20150424170407.803115717@mail.rogue-research.com> On Fri, 24 Apr 2015 10:24:48 -0600, David Gobbi said: >I seem to remember that this used to be an option, way back in VTK 2.x and >VTK 3.x. > >It's definitely a nice feature, but how much complexity does it add to the >CMake code? It could certainly simplify things for people that build VTK then manually add it to Xcode or VS projects. There would only be one lib to add, and no guessing which libs are needed. 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 Fri Apr 24 13:15:28 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Fri, 24 Apr 2015 19:15:28 +0200 Subject: [vtk-developers] Compiling VTK as a single library In-Reply-To: <20150424170407.803115717@mail.rogue-research.com> References: <20150424170407.803115717@mail.rogue-research.com> Message-ID: This is basically the 2 last commits on this old branch: https://github.com/jpouderoux/VTK/tree/CompileVTKAsOneBigLibrary It claims that it generates a static lib but in my memory I made it works as a dynamic lib as well... Note that it also contains a script that trims down lot vtk sources directories which are not used in my project, just ignore it for sure. *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2015-04-24 19:04 GMT+02:00 Sean McBride : > On Fri, 24 Apr 2015 10:24:48 -0600, David Gobbi said: > > >I seem to remember that this used to be an option, way back in VTK 2.x and > >VTK 3.x. > > > >It's definitely a nice feature, but how much complexity does it add to the > >CMake code? > > It could certainly simplify things for people that build VTK then manually > add it to Xcode or VS projects. There would only be one lib to add, and no > guessing which libs are needed. > > Cheers, > > -- > ____________________________________________________________ > Sean McBride, B. Eng sean at rogue-research.com > Rogue Research www.rogue-research.com > Mac Software Developer Montr?al, Qu?bec, Canada > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Fri Apr 24 13:30:10 2015 From: DLRdave at aol.com (David Cole) Date: Fri, 24 Apr 2015 13:30:10 -0400 Subject: [vtk-developers] Compiling VTK as a single library In-Reply-To: References: <20150424170407.803115717@mail.rogue-research.com> Message-ID: It would be useful to push this as a test branch, but with the "one library" flag turned ON by default, so that we can see if it builds/works everywhere that CDash at home / buildbot tests things. It doesn't look overly complicating, and it could definitely be useful for some. D On Fri, Apr 24, 2015 at 1:15 PM, Joachim Pouderoux wrote: > This is basically the 2 last commits on this old branch: > https://github.com/jpouderoux/VTK/tree/CompileVTKAsOneBigLibrary > It claims that it generates a static lib but in my memory I made it works as > a dynamic lib as well... > > Note that it also contains a script that trims down lot vtk sources > directories which are not used in my project, just ignore it for sure. > > Joachim Pouderoux > > PhD, Technical Expert > Kitware SAS > > > 2015-04-24 19:04 GMT+02:00 Sean McBride : >> >> On Fri, 24 Apr 2015 10:24:48 -0600, David Gobbi said: >> >> >I seem to remember that this used to be an option, way back in VTK 2.x >> > and >> >VTK 3.x. >> > >> >It's definitely a nice feature, but how much complexity does it add to >> > the >> >CMake code? >> >> It could certainly simplify things for people that build VTK then manually >> add it to Xcode or VS projects. There would only be one lib to add, and no >> guessing which libs are needed. >> >> Cheers, >> >> -- >> ____________________________________________________________ >> Sean McBride, B. Eng sean at rogue-research.com >> Rogue Research www.rogue-research.com >> Mac Software Developer Montr?al, Qu?bec, Canada >> >> > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From david.gobbi at gmail.com Fri Apr 24 14:34:33 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Fri, 24 Apr 2015 12:34:33 -0600 Subject: [vtk-developers] Compiling VTK as a single library In-Reply-To: References: <20150424170407.803115717@mail.rogue-research.com> Message-ID: It's a much smaller change than I thought it would be! If this works cross-platform, I definitely think it would be worthwhile. - David On Fri, Apr 24, 2015 at 11:30 AM, David Cole wrote: > It would be useful to push this as a test branch, but with the "one > library" flag turned ON by default, so that we can see if it > builds/works everywhere that CDash at home / buildbot tests things. > > It doesn't look overly complicating, and it could definitely be useful for > some. > > > D > > > On Fri, Apr 24, 2015 at 1:15 PM, Joachim Pouderoux > wrote: > > This is basically the 2 last commits on this old branch: > > https://github.com/jpouderoux/VTK/tree/CompileVTKAsOneBigLibrary > > It claims that it generates a static lib but in my memory I made it > works as > > a dynamic lib as well... > > > > Note that it also contains a script that trims down lot vtk sources > > directories which are not used in my project, just ignore it for sure. > > > > Joachim Pouderoux > > > > PhD, Technical Expert > > Kitware SAS > > > > > > 2015-04-24 19:04 GMT+02:00 Sean McBride : > >> > >> On Fri, 24 Apr 2015 10:24:48 -0600, David Gobbi said: > >> > >> >I seem to remember that this used to be an option, way back in VTK 2.x > >> > and > >> >VTK 3.x. > >> > > >> >It's definitely a nice feature, but how much complexity does it add to > >> > the > >> >CMake code? > >> > >> It could certainly simplify things for people that build VTK then > manually > >> add it to Xcode or VS projects. There would only be one lib to add, > and no > >> guessing which libs are needed. > >> > >> Cheers, > -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Fri Apr 24 14:56:21 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Fri, 24 Apr 2015 14:56:21 -0400 Subject: [vtk-developers] Compiling VTK as a single library In-Reply-To: References: <20150424170407.803115717@mail.rogue-research.com> Message-ID: The only issue that I see with the code is that CMAKE_AR sound be used directly. IIRC you should look at CMAKE_CXX_ARCHIVE_CREATE / CMAKE_CXX_ARCHIVE_APPEND / etc. On top of that you might think about handling if the user has enabled INTERPROCEDURAL_OPTIMIZATION which cause the linux intel to use xiar instead of the archiver in CMAKE_AR. On Fri, Apr 24, 2015 at 2:34 PM, David Gobbi wrote: > It's a much smaller change than I thought it would be! If this works > cross-platform, I definitely think it would be worthwhile. > > - David > > > On Fri, Apr 24, 2015 at 11:30 AM, David Cole wrote: >> >> It would be useful to push this as a test branch, but with the "one >> library" flag turned ON by default, so that we can see if it >> builds/works everywhere that CDash at home / buildbot tests things. >> >> It doesn't look overly complicating, and it could definitely be useful for >> some. >> >> >> D >> >> >> On Fri, Apr 24, 2015 at 1:15 PM, Joachim Pouderoux >> wrote: >> > This is basically the 2 last commits on this old branch: >> > https://github.com/jpouderoux/VTK/tree/CompileVTKAsOneBigLibrary >> > It claims that it generates a static lib but in my memory I made it >> > works as >> > a dynamic lib as well... >> > >> > Note that it also contains a script that trims down lot vtk sources >> > directories which are not used in my project, just ignore it for sure. >> > >> > Joachim Pouderoux >> > >> > PhD, Technical Expert >> > Kitware SAS >> > >> > >> > 2015-04-24 19:04 GMT+02:00 Sean McBride : >> >> >> >> On Fri, 24 Apr 2015 10:24:48 -0600, David Gobbi said: >> >> >> >> >I seem to remember that this used to be an option, way back in VTK 2.x >> >> > and >> >> >VTK 3.x. >> >> > >> >> >It's definitely a nice feature, but how much complexity does it add to >> >> > the >> >> >CMake code? >> >> >> >> It could certainly simplify things for people that build VTK then >> >> manually >> >> add it to Xcode or VS projects. There would only be one lib to add, >> >> and no >> >> guessing which libs are needed. >> >> >> >> Cheers, > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From ben.boeckel at kitware.com Fri Apr 24 15:08:43 2015 From: ben.boeckel at kitware.com (Ben Boeckel) Date: Fri, 24 Apr 2015 15:08:43 -0400 Subject: [vtk-developers] Compiling VTK as a single library In-Reply-To: References: <20150424170407.803115717@mail.rogue-research.com> Message-ID: <20150424190843.GA6214@megas.kitware.com> On Fri, Apr 24, 2015 at 13:30:10 -0400, David Cole via vtk-developers wrote: > It would be useful to push this as a test branch, but with the "one > library" flag turned ON by default, so that we can see if it > builds/works everywhere that CDash at home / buildbot tests things. > > It doesn't look overly complicating, and it could definitely be useful for some. The kits logic could be leveraged to act as if everything were part of one large kit. --Ben From joachim.pouderoux at kitware.com Fri Apr 24 15:42:04 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Fri, 24 Apr 2015 21:42:04 +0200 Subject: [vtk-developers] Compiling VTK as a single library In-Reply-To: References: <20150424170407.803115717@mail.rogue-research.com> Message-ID: Ok I'll take a look at it. However for now what I can tell is that this stuff has been compiled successfully on Windows with MSVC2012-13 and ICC, and on Linux with GCC, ICC and PGI. *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2015-04-24 20:56 GMT+02:00 Robert Maynard : > The only issue that I see with the code is that CMAKE_AR sound be used > directly. IIRC you should look at CMAKE_CXX_ARCHIVE_CREATE / > CMAKE_CXX_ARCHIVE_APPEND / etc. On top of that you might think about > handling if the user has enabled INTERPROCEDURAL_OPTIMIZATION which > cause the linux intel to use xiar instead of the archiver in CMAKE_AR. > > > On Fri, Apr 24, 2015 at 2:34 PM, David Gobbi > wrote: > > It's a much smaller change than I thought it would be! If this works > > cross-platform, I definitely think it would be worthwhile. > > > > - David > > > > > > On Fri, Apr 24, 2015 at 11:30 AM, David Cole wrote: > >> > >> It would be useful to push this as a test branch, but with the "one > >> library" flag turned ON by default, so that we can see if it > >> builds/works everywhere that CDash at home / buildbot tests things. > >> > >> It doesn't look overly complicating, and it could definitely be useful > for > >> some. > >> > >> > >> D > >> > >> > >> On Fri, Apr 24, 2015 at 1:15 PM, Joachim Pouderoux > >> wrote: > >> > This is basically the 2 last commits on this old branch: > >> > https://github.com/jpouderoux/VTK/tree/CompileVTKAsOneBigLibrary > >> > It claims that it generates a static lib but in my memory I made it > >> > works as > >> > a dynamic lib as well... > >> > > >> > Note that it also contains a script that trims down lot vtk sources > >> > directories which are not used in my project, just ignore it for sure. > >> > > >> > Joachim Pouderoux > >> > > >> > PhD, Technical Expert > >> > Kitware SAS > >> > > >> > > >> > 2015-04-24 19:04 GMT+02:00 Sean McBride : > >> >> > >> >> On Fri, 24 Apr 2015 10:24:48 -0600, David Gobbi said: > >> >> > >> >> >I seem to remember that this used to be an option, way back in VTK > 2.x > >> >> > and > >> >> >VTK 3.x. > >> >> > > >> >> >It's definitely a nice feature, but how much complexity does it add > to > >> >> > the > >> >> >CMake code? > >> >> > >> >> It could certainly simplify things for people that build VTK then > >> >> manually > >> >> add it to Xcode or VS projects. There would only be one lib to add, > >> >> and no > >> >> guessing which libs are needed. > >> >> > >> >> Cheers, > > > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > > http://www.kitware.com/opensource/opensource.html > > > > Search the 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 majcjc at gmail.com Fri Apr 24 16:25:46 2015 From: majcjc at gmail.com (Lin M) Date: Fri, 24 Apr 2015 16:25:46 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <20150420131200.GA450@megas.kitware.com> References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> Message-ID: Hi Dr. Thompson, Really sorry for late reply. I have been overwhelmed by my siggraph aisa project recently. I changed the method to compute binomial coefficient from vtkMath::Binomial to vtkMath::Factorial using our memoization improvement and tried to merge from Lin.Ma/filter-bezier to Spline/filter-bezier. What do you think is the proper thing to do next? Best, Lin On Mon, Apr 20, 2015 at 9:12 AM, Ben Boeckel wrote: > On Fri, Apr 17, 2015 at 22:53:50 -0400, David Thompson wrote: > > Thanks for pushing the branch to gitlab. > > > > > Do I need to make a merge requests for that? There are still many > > > things to be improved in the code. > > > > You can submit merge requests -- but not to vtk/vtk. I have created a > > new group named splines and added you as a developer. Please fork this > > repository: > > > > https://gitlab.kitware.com/splines/vtk > > I have local (largely untested, but a smoke test succeeded) changes > which allow submitting MRs to other forks of the same project, so this > whole repo shuffle thing should be unnecessary once that gets some more > testing (and we should finally have a complete end-to-end test instance > up and running here this week). > > > You will have to tell gitlab to delete your existing fork of VTK (only > > on the web, not the files on your computer!) and fork that repository > > instead in order to submit merge requests. To remove your current fork > > of VTK, visit: > > > > https://gitlab.kitware.com/Lin.Ma/vtk/edit > > > > Scroll to the bottom of the page and click the red "Remove project" > > button. Then you can fork splines/vtk by visiting > > > > https://gitlab.kitware.com/splines/vtk > > > > and clicking its "Fork" button at the top right of the page. You will > > see that splines/vtk already contains your filters-bezier branch and > > that I have made some changes (so that it meets the VTK style > > guidelines). > > Probably easier to just rename the project rather than deleting it. > Alternatively, give developer access to Lin.Ma for splines/vtk and make > an MR from splines/vtk to itself. > > > Please review the changes and make sure you understand what I've done. > > If you are unsure what I did or why I did it, please ask. > > > > Once you have reviewed the changes, please make a small change and > > submit a merge request from Lin.Ma/vtk filters-bezier to vtk/splines > > filters-bezier to test that merge requests work. > > FYI, kwrobot and buildbot do not act on reporitories other than the ones > specified in their scripts, so your @buildbot test I saw will go > ignored until it shows up as an MR on vtk/vtk. > > --Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon Apr 27 13:46:57 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 27 Apr 2015 13:46:57 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> Message-ID: Hi Lin, > ... I changed the method to compute binomial coefficient from vtkMath::Binomial to vtkMath::Factorial using our memoization improvement and tried to merge from Lin.Ma/filter-bezier to Spline/filter-bezier. Great! I can see that you were able to merge to the branch. > What do you think is the proper thing to do next? Right now, it looks like TestPatchInterpolation is modifying the array holding control point coordinates. I think it would be a good idea to write the interpolated points to a separate array and then make the test verify that Bernstein polynomial is being computed properly. There are 2 ways to verify things: value tests and image tests. 1. Value testing. Interpolate a few different r values on a few different sets of control points and compare the resulting point coordinates to values you know are good. The comparison must allow for small differences due to the differences in floating-point arithmetic implementations on different platforms. 2. Image testing. Plot the interpolated points and compare the rendering of the interpolated points to one you have verified is correct. While not as accurate as value testing, it can often be easier to debug a failing test with a rendered image. VTK provides utilities for comparing images (also allowing for small differences due to floating-point math, OpenGL implementations, and so on). The image baselines that get compared to your test's rendering are stored outside of the git repository to keep the repository from getting bloated. Instead, the MD5 sum of the baseline images are stored in the git repository and the images are stored separately on Kitware's servers, which can be queried to find a file with a given MD5 sum. Please take a look at this documentation on adding test data and baseline images to VTK: https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/data.md and see if you can add an image-based test of the patch interpolation. David From mat930121 at hotmail.com Mon Apr 27 17:45:36 2015 From: mat930121 at hotmail.com (Ragnarok) Date: Mon, 27 Apr 2015 14:45:36 -0700 (MST) Subject: [vtk-developers] Combining Qt 5.4.1 with vtk 6.2.0 (using CMake GUI 3.2.1) on windows Message-ID: <1430171136529-5731644.post@n5.nabble.com> Hi! I'm new to vtk and qt and want to create a project using vtk and qt. Unfortunately, I'm stuck at the part where I have to use some plugin for qt. I've followed this tutorial : http://www.vtk.org/Wiki/VTK/Tutorials/QtSetup and everything seems to be working. I had to add/edit entries to the tutorial for it to work : //added CMAKE_PREFIX_PATH = E:\Qt\Qt5.4.1\5.4\msvc2013_64 in cmake //edited VTK_QT_VERSION = 5 I'm stuck at the last part where it is said : Copy QVTKWidgetPlugin.lib and QVTKWidgetPlugin.dll from C:\bin\VTK\bin\Debug to C:\Qt\4.7.0\plugins\designer I cannot find either the .lib or .dll file. Am I missing an important step? -- View this message in context: http://vtk.1045678.n5.nabble.com/Combining-Qt-5-4-1-with-vtk-6-2-0-using-CMake-GUI-3-2-1-on-windows-tp5731644.html Sent from the VTK - Dev mailing list archive at Nabble.com. From mat930121 at hotmail.com Mon Apr 27 18:44:47 2015 From: mat930121 at hotmail.com (Ragnarok) Date: Mon, 27 Apr 2015 15:44:47 -0700 (MST) Subject: [vtk-developers] Combining Qt 5.4.1 with vtk 6.2.0 (using CMake GUI 3.2.1) on windows [HELP] In-Reply-To: <1430171136529-5731644.post@n5.nabble.com> References: <1430171136529-5731644.post@n5.nabble.com> Message-ID: <1430174687272-5731645.post@n5.nabble.com> I repeated every step and it now works, I have no idea what my problem was -- View this message in context: http://vtk.1045678.n5.nabble.com/Combining-Qt-5-4-1-with-vtk-6-2-0-using-CMake-GUI-3-2-1-on-windows-HELP-tp5731644p5731645.html Sent from the VTK - Dev mailing list archive at Nabble.com. From blessley at cs.uoregon.edu Mon Apr 27 19:15:57 2015 From: blessley at cs.uoregon.edu (Brent Lessley) Date: Mon, 27 Apr 2015 16:15:57 -0700 Subject: [vtk-developers] GSoC Project with VTK Message-ID: Dear VTK Community, Today my Google Summer of Code project proposal for VTK was accepted. I'm sending this message to introduce myself to the VTK community. Currently, I am a 2nd-year computer science PhD student at the University of Oregon, working under the supervision of Prof. Hank Childs. As part of the project, I plan to use VTK-m and data parallel primitives to implement many-core algorithms for the problem of identifying external faces in a mesh of cells. The result of my work will be contributed back to VTK-m as an open-source module. I look forward to this experience and the opportunity to work with you this summer. Best, Brent Lessley -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Mon Apr 27 20:01:59 2015 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Mon, 27 Apr 2015 20:01:59 -0400 Subject: [vtk-developers] GSoC Project with VTK In-Reply-To: References: Message-ID: On Mon, Apr 27, 2015 at 7:15 PM, Brent Lessley wrote: > Dear VTK Community, > > Today my Google Summer of Code project proposal for VTK was accepted. I'm > sending this message to introduce myself to the VTK community. Currently, I > am a 2nd-year computer science PhD student at the University of Oregon, > working under the supervision of Prof. Hank Childs. As part of the project, > I plan to use VTK-m and data parallel primitives to implement many-core > algorithms for the problem of identifying external faces in a mesh of cells. > The result of my work will be contributed back to VTK-m as an open-source > module. > > I look forward to this experience and the opportunity to work with you this > summer. > Thanks for introducing yourself, we are very much looking forward to seeing what you and our five other students accomplish this summer! It is our biggest summer of code yet, and we have some great projects. Best wishes, Marcus From andrew.amaclean at gmail.com Tue Apr 28 03:42:57 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 28 Apr 2015 17:42:57 +1000 Subject: [vtk-developers] Need help with a crash on Kamino OSX Release mode. Message-ID: Hi All, I need some help here. I have converted TestSetGet.tcl to Python but I get a crash on the dashboard for kamino building osx in release mode, here: https://open.cdash.org/buildSummary.php?buildid=3789971 and here: https://open.cdash.org/buildSummary.php?buildid=3789950 In an earlier attempt, linux release on megas was also crashing in release mode: https://open.cdash.org/testDetails.php?test=331289192&build=3789418 Based on this I excluded vtkScatterPlotMatrix which fixed it on megas but not on Kamino. So I excluded vtkChartMatrix and I still have the same errors on Kamino. But there are no clues as to where the crash is happening. However in looking at: https://open.cdash.org/testDetails.php?test=331378847&build=3789950 I think it is in vtkView - which is already excluded. This could be the problem: void SetRepresentation (vtkDataRepresentation *rep) vtkDataRepresentation * GetRepresentation (int index=0) Can anyone help? I guess I can try excluding all the *View classes as documented in: http://www.vtk.org/doc/nightly/html/classvtkView.html Is there a less brute-force approach? The code is here: https://gitlab.kitware.com/vtk/vtk/merge_requests/151 Thanks in advance for any help/guidance. Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Tue Apr 28 05:57:19 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Tue, 28 Apr 2015 11:57:19 +0200 Subject: [vtk-developers] OpenGL backend differences Message-ID: Hi, Mathieu and I were facing a tricky situation when adding a new VTK test. We basically tried to render a piece of a RTAnalyticSource. We generated the baseline image with the legacy backend and tests were failing with the OpenGL 2 backend. Attached are the images we obtained with the two backends - you can see that the color spots have not the same orientation. We finally found the origin of the problem: as the grid is made of hexahedron, the geometry filter generates a surface made of quads. For the legacy backend, rendering quads is not an issue as OpenGL allows to render (non-convex) polygons directly, so the legacy painter-mapper directly sends the quad to OpenGL for rendering. With the new backend, only triangles are transferred to the graphic board and a triangulation is implicitly performed by the mapper (actually by vtkglVBOHelper.cxx:338 - vtkgl::AppendTriangleIndexBuffer function). Note that this function respects the order of the triangulation performed by vtkQuad::Triangulate() but it seems like it is not the one implicitly performed by OpenGL (or some OpenGL implementations at least) when you render quad primitives. To fix the issue we inserted a vtkTriangleFilter between the GeometryFilter and the Mapper so that both mapper implementations end up with the same triangulated mesh to render. I think this behaviour should be documented somewhere (may be it is already? anyway now at least it is here) as I am sure this should cause problems later. Best, *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test-opengl1.png Type: image/png Size: 5514 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test-opengl2.png Type: image/png Size: 5445 bytes Desc: not available URL: From ken.martin at kitware.com Tue Apr 28 09:06:15 2015 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 28 Apr 2015 09:06:15 -0400 Subject: [vtk-developers] OpenGL backend differences In-Reply-To: References: Message-ID: <30fb69bec17dd58186dfaf81b96978b0@mail.gmail.com> Yes, that used to be a common problem in the early days of graphic libraries as they often would render quads differently depending on implementation. I added it to the running list of regressions/todos which is included below: Changes/ToDos/Regressions 1. Gouraud shading dropped, actors set to Gouraud now render using Phong shading 2. Wireframe polygons without normals are now lighted differently than before. Previously VTK would generate vertex normals from the polygon and use those to light the wireframe line. The new code lights the lines in the fragment shader by generating a normal that is perpendicular to the line and maximally aligned with the camera view direction. That normal is then used for lighting calcs. This results in different images but arguably just as intuitive as the prior approach. 3. currently when picking, only 16,777,215 primitives per mapper are supported, could extend this up to 2^31 without too much grief, beyond that gl_PrimitiveID will not work and we would just have to loop in the mapper rendering a batch of prims at a time 4. SetZBuffer data function in RenderWindow is currently not working, have to take the same approach as SetRGBA functions and have a shader do this. 5. ImageSliceMapper and ImageMapper should be modified to directly use TextureObject instead of vtkTexture, saving some pipeline overhead etc. 6. triangle cell data passed into strips via field data does not work, and I would say we do not support this odd case. Maybe modify stripper to complain if PassCellDataAsFieldData is turned on. vtkStripper stripper stripper PassCellDataAsFieldDataOn vtkPolyDataMapper sphereMapper sphereMapper SetColorModeToMapScalars sphereMapper SetScalarModeToUseFieldData 7. When no lights are on, the old backend would still apply lighting equations just with no lights (mostly, the valid image for NoLightGeneration is missing the line, seems wrong). The new backend does not apply lighting equations in that case, rather it treats it like the 2d mapper, rendering without a lighting model. The old approach can be achieved simply by having a light that has it?s intensity set to zero (as opposed to being turned off) if that is what you are after. 8. Need to cache VBOs, so that if multiple mappers are using the same VBO they share it. Related to that, right now we rebuild the VBO even if just the IBO is changing, a VBO cache would handle that case as well and is s step towards sharing gl buffers data between actors/mappers. 9. When a texture map modulates the color on a fragment, the old code limited the color to 1.0 before modulating against the texture. In the new code the color of a fragment may exceed 1.0 and then be modulated by a texture and finally truncated to 1.0. This can produce different results when the fragment is overlit (e.g. diffuse = 1.0 ambient = 1.0 and then modulated by a texture.) 10. Should try fixing the math in texture object, it is using texture size when it should be destination size when doing the 0.5 thing. Mostly is not caught as the texture is often the same size as the destination. 11. Quads and higher degree polygons are converted to triangles by the OpenGL backend prior to being sent to OpenGL. This can result in different interpolation versus the old backend. Ken Martin PhD Chairman & CFO Kitware Inc. 28 Corporate Drive Clifton Park NY 12065 ken.martin at kitware.com 518 881-4901 (w) 518 371-4573 (f) 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:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf Of *Joachim Pouderoux *Sent:* Tuesday, April 28, 2015 5:57 AM *To:* VTK Developers *Cc:* Mathieu Westphal *Subject:* [vtk-developers] OpenGL backend differences Hi, Mathieu and I were facing a tricky situation when adding a new VTK test. We basically tried to render a piece of a RTAnalyticSource. We generated the baseline image with the legacy backend and tests were failing with the OpenGL 2 backend. Attached are the images we obtained with the two backends - you can see that the color spots have not the same orientation. We finally found the origin of the problem: as the grid is made of hexahedron, the geometry filter generates a surface made of quads. For the legacy backend, rendering quads is not an issue as OpenGL allows to render (non-convex) polygons directly, so the legacy painter-mapper directly sends the quad to OpenGL for rendering. With the new backend, only triangles are transferred to the graphic board and a triangulation is implicitly performed by the mapper (actually by vtkglVBOHelper.cxx:338 - vtkgl::AppendTriangleIndexBuffer function). Note that this function respects the order of the triangulation performed by vtkQuad::Triangulate() but it seems like it is not the one implicitly performed by OpenGL (or some OpenGL implementations at least) when you render quad primitives. To fix the issue we inserted a vtkTriangleFilter between the GeometryFilter and the Mapper so that both mapper implementations end up with the same triangulated mesh to render. I think this behaviour should be documented somewhere (may be it is already? anyway now at least it is here) as I am sure this should cause problems later. Best, *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * -------------- next part -------------- An HTML attachment was scrubbed... URL: From jiac5 at uci.edu Tue Apr 28 11:35:50 2015 From: jiac5 at uci.edu (Jia Chen) Date: Tue, 28 Apr 2015 08:35:50 -0700 Subject: [vtk-developers] GSoC project: Improvements to Earth and Space Science Visualization Message-ID: Hi, All, My name is Jia Chen, and I just got notified that my proposal to GSoC project "Improvements to Earth and Space Science Visualization" has been accepted. So I am writing to introduce myself. I am currently a Ph.D student at UC Irvine, major in Computer Graphics. In this project, I would like to enhance VTK's earth and space science visualization module for geophysical data visualization. Geophysical data visualization is an important part for the study of various areas of earth science, such as oil and mineral exploration, seismic monitoring etc. Related functions have been integrated into commercial software like Avizo, Open Inventor, Geoviz, etc. But in open source community, we still lack such software to provide solution for visualizing these kinds of data. In this project, I would like to add support for visualizing geophysical objects in VTK. The full text of my proposal can be found from link . If you or your friends need such geophysical data visualization features, or you have suggestions on the project, please let me know. All suggestions are highly appreciated, and looking forward to spending an exciting summer working with you all. Best Regards, Jia -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Apr 28 12:23:06 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 28 Apr 2015 10:23:06 -0600 Subject: [vtk-developers] Need help with a crash on Kamino OSX Release mode. In-Reply-To: References: Message-ID: Hi Andrew, The stack trace provides strong evidence that TestSetGet.py is not excluding vtkView on those dashboards, as ludicrous as that sounds. c++filt -n _ZL27PyvtkView_SetRepresentationP7_objectS0_ PyvtkView_SetRepresentation(_object*, _object*) This method is only defined in vtkViewPython.cxx, and only dir(vtk.vtkView) will return this method. Calling dir() on the vtkView subclasses will not return this method. Hence, the only reason that TestSetGet.py would be calling this method is if it was testing vtkView. Perhaps someone added either a typedef or a macro that causes an additional reference to vtkView to appear in the vtk module under a different name. - David On Tue, Apr 28, 2015 at 1:42 AM, Andrew Maclean wrote: > Hi All, > I need some help here. > > I have converted TestSetGet.tcl to Python but I get a crash on the > dashboard for kamino building osx in release mode, here: > https://open.cdash.org/buildSummary.php?buildid=3789971 > and here: > https://open.cdash.org/buildSummary.php?buildid=3789950 > > In an earlier attempt, linux release on megas was also crashing in release > mode: > https://open.cdash.org/testDetails.php?test=331289192&build=3789418 > Based on this I excluded vtkScatterPlotMatrix which fixed it on megas but > not on Kamino. > So I excluded vtkChartMatrix and I still have the same errors on Kamino. > But there are no clues as to where the crash is happening. However in > looking at: > https://open.cdash.org/testDetails.php?test=331378847&build=3789950 > I think it is in vtkView - which is already excluded. > This could be the problem: > void SetRepresentation (vtkDataRepresentation *rep) > vtkDataRepresentation * GetRepresentation (int index=0) > > Can anyone help? > > I guess I can try excluding all the *View classes as documented in: > http://www.vtk.org/doc/nightly/html/classvtkView.html > Is there a less brute-force approach? > > > The code is here: > https://gitlab.kitware.com/vtk/vtk/merge_requests/151 > > Thanks in advance for any help/guidance. > > Andrew > -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Tue Apr 28 12:29:47 2015 From: majcjc at gmail.com (Lin M) Date: Tue, 28 Apr 2015 12:29:47 -0400 Subject: [vtk-developers] GSoC 2015 Project - CAD Model and Simulation Spline Visualization Message-ID: Hi all, My name is Lin, a master student in SIAT, Chinese Academy of Science. I'm now visiting the HMS lab at UPenn. It's my honor to take part in the VTK/GSoC this year. I'll give some brief descriptions about this project. This project aims at adding a few extensions to the VTK library to support spline curve- and surface-based visualizations. In this project, we will focus on rational B?zier patches which are parametric surfaces generated from the Cartesian product of two B?zier curves. Supporting this widely-used parametric representation will give VTK the ability to visualize meshes and simulations processed from CAD models. Here is the link to my proposal if anyone is interested about that. Any ideas and suggestions are very welcomed and looking forward to working with you all during this summer. Thank you! Best, Lin -------------- next part -------------- An HTML attachment was scrubbed... URL: From ashray.malhotra.1994 at gmail.com Tue Apr 28 15:10:20 2015 From: ashray.malhotra.1994 at gmail.com (Ashray Malhotra) Date: Wed, 29 Apr 2015 00:40:20 +0530 Subject: [vtk-developers] Ashray Malhotra - GSOC student :D Message-ID: Hello everyone, I am Ashray Malhotra, currently a fourth year student from IIT Bombay. I live in Mumbai, India. This is my first experience with open source, am both excited and nervous :D My major is Electrical Engineering and my specialisation is in Signal Processing. I still have a year of college of left and hope to spend a lot of that time working on awesome open source projects. My background in coding is majorly my college courses. I also had a summer intern in Goldman Sachs Technologies last year and was the Teaching Assistant for the introduction to computer science course on EdX. The project I'll be working on in GSOC is Eulerian Video Motion Magnification, which basically magnifies minute changes in videos to make them visible. This TED talk (https://youtu.be/fHfhorJnAEI) inspired me on this topic, have a look if it interests you as well. Please feel free to ping me if you think I could be of any help. Would really appreciate help from you guys in helping me getting started with the open source world. -- Regards Ashray Malhotra -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Tue Apr 28 22:07:35 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 29 Apr 2015 12:07:35 +1000 Subject: [vtk-developers] Need help with a crash on Kamino OSX Release mode. In-Reply-To: References: Message-ID: David, Thanks for your insights. Just finished testing this code on my Macbook Pro OS X Yosemite, Python 2.7.6 after building VTK in both Debug and Release mode. Everything runs Ok so I don't think it is a typedef or macro related to a release build on OS X. Has anyone else got any suggestions? Regards Andrew On Wed, Apr 29, 2015 at 2:23 AM, David Gobbi wrote: > Hi Andrew, > > The stack trace provides strong evidence that TestSetGet.py is not > excluding vtkView on those dashboards, as ludicrous as that sounds. > > c++filt -n _ZL27PyvtkView_SetRepresentationP7_objectS0_ > PyvtkView_SetRepresentation(_object*, _object*) > > This method is only defined in vtkViewPython.cxx, and only > dir(vtk.vtkView) will return this method. Calling dir() on the vtkView > subclasses will not return this method. Hence, the only reason that > TestSetGet.py would be calling this method is if it was testing vtkView. > > Perhaps someone added either a typedef or a macro that causes an > additional reference to vtkView to appear in the vtk module under a > different name. > > - David > > On Tue, Apr 28, 2015 at 1:42 AM, Andrew Maclean > wrote: > >> Hi All, >> I need some help here. >> >> I have converted TestSetGet.tcl to Python but I get a crash on the >> dashboard for kamino building osx in release mode, here: >> https://open.cdash.org/buildSummary.php?buildid=3789971 >> and here: >> https://open.cdash.org/buildSummary.php?buildid=3789950 >> >> In an earlier attempt, linux release on megas was also crashing in >> release mode: >> https://open.cdash.org/testDetails.php?test=331289192&build=3789418 >> Based on this I excluded vtkScatterPlotMatrix which fixed it on megas but >> not on Kamino. >> So I excluded vtkChartMatrix and I still have the same errors on Kamino. >> But there are no clues as to where the crash is happening. However in >> looking at: >> https://open.cdash.org/testDetails.php?test=331378847&build=3789950 >> I think it is in vtkView - which is already excluded. >> This could be the problem: >> void SetRepresentation (vtkDataRepresentation *rep) >> vtkDataRepresentation * GetRepresentation (int index=0) >> >> Can anyone help? >> >> I guess I can try excluding all the *View classes as documented in: >> http://www.vtk.org/doc/nightly/html/classvtkView.html >> Is there a less brute-force approach? >> >> >> The code is here: >> https://gitlab.kitware.com/vtk/vtk/merge_requests/151 >> >> Thanks in advance for any help/guidance. >> >> Andrew >> > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Tue Apr 28 22:58:40 2015 From: sean at rogue-research.com (Sean McBride) Date: Tue, 28 Apr 2015 22:58:40 -0400 Subject: [vtk-developers] Need help with a crash on Kamino OSX Release mode. In-Reply-To: References: Message-ID: <20150429025840.868205794@mail.rogue-research.com> Did you fix the use-after-free we discussed on this list a few weeks ago? Sean On Wed, 29 Apr 2015 12:07:35 +1000, Andrew Maclean said: >David, > Thanks for your insights. >Just finished testing this code on my Macbook Pro OS X Yosemite, Python >2.7.6 after building VTK in both Debug and Release mode. Everything runs Ok >so I don't think it is a typedef or macro related to a release build on OS >X. > >Has anyone else got any suggestions? > > >Regards > Andrew > >On Wed, Apr 29, 2015 at 2:23 AM, David Gobbi wrote: > >> Hi Andrew, >> >> The stack trace provides strong evidence that TestSetGet.py is not >> excluding vtkView on those dashboards, as ludicrous as that sounds. >> >> c++filt -n _ZL27PyvtkView_SetRepresentationP7_objectS0_ >> PyvtkView_SetRepresentation(_object*, _object*) >> >> This method is only defined in vtkViewPython.cxx, and only >> dir(vtk.vtkView) will return this method. Calling dir() on the vtkView >> subclasses will not return this method. Hence, the only reason that >> TestSetGet.py would be calling this method is if it was testing vtkView. >> >> Perhaps someone added either a typedef or a macro that causes an >> additional reference to vtkView to appear in the vtk module under a >> different name. >> >> - David >> >> On Tue, Apr 28, 2015 at 1:42 AM, Andrew Maclean > > wrote: >> >>> Hi All, >>> I need some help here. >>> >>> I have converted TestSetGet.tcl to Python but I get a crash on the >>> dashboard for kamino building osx in release mode, here: >>> https://open.cdash.org/buildSummary.php?buildid=3789971 >>> and here: >>> https://open.cdash.org/buildSummary.php?buildid=3789950 >>> >>> In an earlier attempt, linux release on megas was also crashing in >>> release mode: >>> https://open.cdash.org/testDetails.php?test=331289192&build=3789418 >>> Based on this I excluded vtkScatterPlotMatrix which fixed it on megas but >>> not on Kamino. >>> So I excluded vtkChartMatrix and I still have the same errors on Kamino. >>> But there are no clues as to where the crash is happening. However in >>> looking at: >>> https://open.cdash.org/testDetails.php?test=331378847&build=3789950 >>> I think it is in vtkView - which is already excluded. >>> This could be the problem: >>> void SetRepresentation (vtkDataRepresentation *rep) >>> vtkDataRepresentation * GetRepresentation (int index=0) >>> >>> Can anyone help? >>> >>> I guess I can try excluding all the *View classes as documented in: >>> http://www.vtk.org/doc/nightly/html/classvtkView.html >>> Is there a less brute-force approach? >>> >>> >>> The code is here: >>> https://gitlab.kitware.com/vtk/vtk/merge_requests/151 >>> >>> Thanks in advance for any help/guidance. From andrew.amaclean at gmail.com Tue Apr 28 23:32:43 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 29 Apr 2015 13:32:43 +1000 Subject: [vtk-developers] Need help with a crash on Kamino OSX Release mode. In-Reply-To: <20150429025840.868205794@mail.rogue-research.com> References: <20150429025840.868205794@mail.rogue-research.com> Message-ID: Hi Sean, Yes, vtkDataEncoder and vtkWebApplication (which uses it) are excluded form TestSetGet.py and TestEmptyInput.py. This fixed the crashes and also the crash in windows when the program was run again. I think Windows was a bit slow recovering memory. after program execution. What is puzzling is that TestGetSet excludes vtkView so vtkView.SetRepresentation() is never tested, this only fails on Kamino (release). It passes on trey (osX release) and also on megas. Regards Andrew On Wed, Apr 29, 2015 at 12:58 PM, Sean McBride wrote: > Did you fix the use-after-free we discussed on this list a few weeks ago? > > Sean > > > > On Wed, 29 Apr 2015 12:07:35 +1000, Andrew Maclean said: > > >David, > > Thanks for your insights. > >Just finished testing this code on my Macbook Pro OS X Yosemite, Python > >2.7.6 after building VTK in both Debug and Release mode. Everything runs > Ok > >so I don't think it is a typedef or macro related to a release build on OS > >X. > > > >Has anyone else got any suggestions? > > > > > >Regards > > Andrew > > > >On Wed, Apr 29, 2015 at 2:23 AM, David Gobbi > wrote: > > > >> Hi Andrew, > >> > >> The stack trace provides strong evidence that TestSetGet.py is not > >> excluding vtkView on those dashboards, as ludicrous as that sounds. > >> > >> c++filt -n _ZL27PyvtkView_SetRepresentationP7_objectS0_ > >> PyvtkView_SetRepresentation(_object*, _object*) > >> > >> This method is only defined in vtkViewPython.cxx, and only > >> dir(vtk.vtkView) will return this method. Calling dir() on the vtkView > >> subclasses will not return this method. Hence, the only reason that > >> TestSetGet.py would be calling this method is if it was testing vtkView. > >> > >> Perhaps someone added either a typedef or a macro that causes an > >> additional reference to vtkView to appear in the vtk module under a > >> different name. > >> > >> - David > >> > >> On Tue, Apr 28, 2015 at 1:42 AM, Andrew Maclean < > andrew.amaclean at gmail.com > >> > wrote: > >> > >>> Hi All, > >>> I need some help here. > >>> > >>> I have converted TestSetGet.tcl to Python but I get a crash on the > >>> dashboard for kamino building osx in release mode, here: > >>> https://open.cdash.org/buildSummary.php?buildid=3789971 > >>> and here: > >>> https://open.cdash.org/buildSummary.php?buildid=3789950 > >>> > >>> In an earlier attempt, linux release on megas was also crashing in > >>> release mode: > >>> https://open.cdash.org/testDetails.php?test=331289192&build=3789418 > >>> Based on this I excluded vtkScatterPlotMatrix which fixed it on megas > but > >>> not on Kamino. > >>> So I excluded vtkChartMatrix and I still have the same errors on > Kamino. > >>> But there are no clues as to where the crash is happening. However in > >>> looking at: > >>> https://open.cdash.org/testDetails.php?test=331378847&build=3789950 > >>> I think it is in vtkView - which is already excluded. > >>> This could be the problem: > >>> void SetRepresentation (vtkDataRepresentation *rep) > >>> vtkDataRepresentation * GetRepresentation (int index=0) > >>> > >>> Can anyone help? > >>> > >>> I guess I can try excluding all the *View classes as documented in: > >>> http://www.vtk.org/doc/nightly/html/classvtkView.html > >>> Is there a less brute-force approach? > >>> > >>> > >>> The code is here: > >>> https://gitlab.kitware.com/vtk/vtk/merge_requests/151 > >>> > >>> Thanks in advance for any help/guidance. > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Wed Apr 29 02:23:14 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 29 Apr 2015 16:23:14 +1000 Subject: [vtk-developers] Need help with a crash on Kamino OSX Release mode. In-Reply-To: References: <20150429025840.868205794@mail.rogue-research.com> Message-ID: He Sean, I should clarify this a bit more. vtkDataEncoder invokes a thread pool which doesn't clean up after use, hence the crashes after program execution, adding vtkDataEncoder to the list of excluded classes "almost" fixed this. However Windows was still crashing when the program was run again, so, adding vtkWebApplication (which is the only class that calls vtkDataEncoder), to the list of excluded classes, fixed this issue. Notwithstanding this, it is puzzling, as I said in the previous e-mail as to why on Kamino we get a SIGSEGV at 0x0 address not mapped to object since vtkView is specifically excluded. Regards Andrew On Wed, Apr 29, 2015 at 1:32 PM, Andrew Maclean wrote: > Hi Sean, > > Yes, vtkDataEncoder and vtkWebApplication (which uses it) are excluded > form TestSetGet.py and TestEmptyInput.py. This fixed the crashes and also > the crash in windows when the program was run again. I think Windows was a > bit slow recovering memory. after program execution. > > What is puzzling is that TestGetSet excludes vtkView so > vtkView.SetRepresentation() is never tested, this only fails on Kamino > (release). It passes on trey (osX release) and also on megas. > > Regards > Andrew > > > On Wed, Apr 29, 2015 at 12:58 PM, Sean McBride > wrote: > >> Did you fix the use-after-free we discussed on this list a few weeks ago? >> >> Sean >> >> >> >> On Wed, 29 Apr 2015 12:07:35 +1000, Andrew Maclean said: >> >> >David, >> > Thanks for your insights. >> >Just finished testing this code on my Macbook Pro OS X Yosemite, Python >> >2.7.6 after building VTK in both Debug and Release mode. Everything runs >> Ok >> >so I don't think it is a typedef or macro related to a release build on >> OS >> >X. >> > >> >Has anyone else got any suggestions? >> > >> > >> >Regards >> > Andrew >> > >> >On Wed, Apr 29, 2015 at 2:23 AM, David Gobbi >> wrote: >> > >> >> Hi Andrew, >> >> >> >> The stack trace provides strong evidence that TestSetGet.py is not >> >> excluding vtkView on those dashboards, as ludicrous as that sounds. >> >> >> >> c++filt -n _ZL27PyvtkView_SetRepresentationP7_objectS0_ >> >> PyvtkView_SetRepresentation(_object*, _object*) >> >> >> >> This method is only defined in vtkViewPython.cxx, and only >> >> dir(vtk.vtkView) will return this method. Calling dir() on the vtkView >> >> subclasses will not return this method. Hence, the only reason that >> >> TestSetGet.py would be calling this method is if it was testing >> vtkView. >> >> >> >> Perhaps someone added either a typedef or a macro that causes an >> >> additional reference to vtkView to appear in the vtk module under a >> >> different name. >> >> >> >> - David >> >> >> >> On Tue, Apr 28, 2015 at 1:42 AM, Andrew Maclean < >> andrew.amaclean at gmail.com >> >> > wrote: >> >> >> >>> Hi All, >> >>> I need some help here. >> >>> >> >>> I have converted TestSetGet.tcl to Python but I get a crash on the >> >>> dashboard for kamino building osx in release mode, here: >> >>> https://open.cdash.org/buildSummary.php?buildid=3789971 >> >>> and here: >> >>> https://open.cdash.org/buildSummary.php?buildid=3789950 >> >>> >> >>> In an earlier attempt, linux release on megas was also crashing in >> >>> release mode: >> >>> https://open.cdash.org/testDetails.php?test=331289192&build=3789418 >> >>> Based on this I excluded vtkScatterPlotMatrix which fixed it on megas >> but >> >>> not on Kamino. >> >>> So I excluded vtkChartMatrix and I still have the same errors on >> Kamino. >> >>> But there are no clues as to where the crash is happening. However in >> >>> looking at: >> >>> https://open.cdash.org/testDetails.php?test=331378847&build=3789950 >> >>> I think it is in vtkView - which is already excluded. >> >>> This could be the problem: >> >>> void SetRepresentation (vtkDataRepresentation *rep) >> >>> vtkDataRepresentation * GetRepresentation (int index=0) >> >>> >> >>> Can anyone help? >> >>> >> >>> I guess I can try excluding all the *View classes as documented in: >> >>> http://www.vtk.org/doc/nightly/html/classvtkView.html >> >>> Is there a less brute-force approach? >> >>> >> >>> >> >>> The code is here: >> >>> https://gitlab.kitware.com/vtk/vtk/merge_requests/151 >> >>> >> >>> Thanks in advance for any help/guidance. >> >> >> > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From goodwin.lawlor.lists at gmail.com Wed Apr 29 06:31:10 2015 From: goodwin.lawlor.lists at gmail.com (Goodwin Lawlor) Date: Wed, 29 Apr 2015 11:31:10 +0100 Subject: [vtk-developers] GSoC 2015 Project - CAD Model and Simulation Spline Visualization In-Reply-To: References: Message-ID: Hi Lin, You should take a look at this tread on vtk-dev: http://markmail.org/message/h2n6c3e3igdcqhvq Prashanth Udupa wrote a class vtkBezierSurfaceSource - source code available I believe but I'm not sure about the licence. Best of luck Goodwin -------------- next part -------------- An HTML attachment was scrubbed... URL: From abhishek.iitd16 at gmail.com Wed Apr 29 06:56:17 2015 From: abhishek.iitd16 at gmail.com (Abhishek Kumar) Date: Wed, 29 Apr 2015 16:26:17 +0530 Subject: [vtk-developers] GSOC Parallel Partitioning Project Message-ID: Hi all, I am Abhishek Kumar, 4th year computer science student from IIT Delhi. I am from New Delhi, India (GMT +5:30), but I am very much comfortable with working or replying at odd timings. I am new to Open Source and I wish to maintain a long term relationship with VTK. As I chose this project over a relatively easy project. My project has three main parts. First is to re-write a currently existing data-distribution filter using newer library for efficient implementation. Second part involves identification of ghost cells, writing unit tests and exploring possible algorithms and the last part of project is to write multithreaded code to utilize all cores on node for partitioning. My academic interest is also high performance computing. You'll be able to see me in action only after 10th May, as I am currently having my end semester exams. Feel free to provide any suggestion or feedback on my project or my mailing list etiquette. As I told you I am new to this. I look forward to give my best during this summer working with you all. -- Cheers Abhishek Kumar abhishekkumar.me Senior Undergraduate, IIT Delhi CSE -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Apr 29 08:38:55 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 29 Apr 2015 08:38:55 -0400 Subject: [vtk-developers] Need help with a crash on Kamino OSX Release mode. In-Reply-To: References: <20150429025840.868205794@mail.rogue-research.com> Message-ID: I ran a build on my machine, named trivet, a Debug 64-bit build from VS 2013, and the test fails with a single assertion failure and 10-20 mem leaks: https://open.cdash.org/testDetails.php?test=331705794&build=3791568 Perhaps the "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\INCLUDE\vector(1201) : Assertion failed: vector subscript out of range" report indicates the *real* cause of the problem on the Mac Release build. I'm not sure which class/method that comes from, but I'm about to run it and try to find out. David C. On Wed, Apr 29, 2015 at 2:23 AM, Andrew Maclean wrote: > He Sean, > > I should clarify this a bit more. > vtkDataEncoder invokes a thread pool which doesn't clean up after use, hence > the crashes after program execution, adding vtkDataEncoder to the list of > excluded classes "almost" fixed this. > However Windows was still crashing when the program was run again, so, > adding vtkWebApplication (which is the only class that calls > vtkDataEncoder), to the list of excluded classes, fixed this issue. > > Notwithstanding this, it is puzzling, as I said in the previous e-mail as to > why on Kamino we get a SIGSEGV at 0x0 address not mapped to object since > vtkView is specifically excluded. > > Regards > Andrew > > > > On Wed, Apr 29, 2015 at 1:32 PM, Andrew Maclean > wrote: >> >> Hi Sean, >> >> Yes, vtkDataEncoder and vtkWebApplication (which uses it) are excluded >> form TestSetGet.py and TestEmptyInput.py. This fixed the crashes and also >> the crash in windows when the program was run again. I think Windows was a >> bit slow recovering memory. after program execution. >> >> What is puzzling is that TestGetSet excludes vtkView so >> vtkView.SetRepresentation() is never tested, this only fails on Kamino >> (release). It passes on trey (osX release) and also on megas. >> >> Regards >> Andrew >> >> >> On Wed, Apr 29, 2015 at 12:58 PM, Sean McBride >> wrote: >>> >>> Did you fix the use-after-free we discussed on this list a few weeks ago? >>> >>> Sean >>> >>> >>> >>> On Wed, 29 Apr 2015 12:07:35 +1000, Andrew Maclean said: >>> >>> >David, >>> > Thanks for your insights. >>> >Just finished testing this code on my Macbook Pro OS X Yosemite, Python >>> >2.7.6 after building VTK in both Debug and Release mode. Everything runs >>> > Ok >>> >so I don't think it is a typedef or macro related to a release build on >>> > OS >>> >X. >>> > >>> >Has anyone else got any suggestions? >>> > >>> > >>> >Regards >>> > Andrew >>> > >>> >On Wed, Apr 29, 2015 at 2:23 AM, David Gobbi >>> > wrote: >>> > >>> >> Hi Andrew, >>> >> >>> >> The stack trace provides strong evidence that TestSetGet.py is not >>> >> excluding vtkView on those dashboards, as ludicrous as that sounds. >>> >> >>> >> c++filt -n _ZL27PyvtkView_SetRepresentationP7_objectS0_ >>> >> PyvtkView_SetRepresentation(_object*, _object*) >>> >> >>> >> This method is only defined in vtkViewPython.cxx, and only >>> >> dir(vtk.vtkView) will return this method. Calling dir() on the >>> >> vtkView >>> >> subclasses will not return this method. Hence, the only reason that >>> >> TestSetGet.py would be calling this method is if it was testing >>> >> vtkView. >>> >> >>> >> Perhaps someone added either a typedef or a macro that causes an >>> >> additional reference to vtkView to appear in the vtk module under a >>> >> different name. >>> >> >>> >> - David >>> >> >>> >> On Tue, Apr 28, 2015 at 1:42 AM, Andrew Maclean >>> >> >> >> > wrote: >>> >> >>> >>> Hi All, >>> >>> I need some help here. >>> >>> >>> >>> I have converted TestSetGet.tcl to Python but I get a crash on the >>> >>> dashboard for kamino building osx in release mode, here: >>> >>> https://open.cdash.org/buildSummary.php?buildid=3789971 >>> >>> and here: >>> >>> https://open.cdash.org/buildSummary.php?buildid=3789950 >>> >>> >>> >>> In an earlier attempt, linux release on megas was also crashing in >>> >>> release mode: >>> >>> https://open.cdash.org/testDetails.php?test=331289192&build=3789418 >>> >>> Based on this I excluded vtkScatterPlotMatrix which fixed it on megas >>> >>> but >>> >>> not on Kamino. >>> >>> So I excluded vtkChartMatrix and I still have the same errors on >>> >>> Kamino. >>> >>> But there are no clues as to where the crash is happening. However in >>> >>> looking at: >>> >>> https://open.cdash.org/testDetails.php?test=331378847&build=3789950 >>> >>> I think it is in vtkView - which is already excluded. >>> >>> This could be the problem: >>> >>> void SetRepresentation (vtkDataRepresentation *rep) >>> >>> vtkDataRepresentation * GetRepresentation (int index=0) >>> >>> >>> >>> Can anyone help? >>> >>> >>> >>> I guess I can try excluding all the *View classes as documented in: >>> >>> http://www.vtk.org/doc/nightly/html/classvtkView.html >>> >>> Is there a less brute-force approach? >>> >>> >>> >>> >>> >>> The code is here: >>> >>> https://gitlab.kitware.com/vtk/vtk/merge_requests/151 >>> >>> >>> >>> Thanks in advance for any help/guidance. >>> >>> >> >> >> >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ > > > > > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From aashish.chaudhary at kitware.com Wed Apr 29 08:48:13 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Wed, 29 Apr 2015 08:48:13 -0400 Subject: [vtk-developers] GSoC project: Improvements to Earth and Space Science Visualization In-Reply-To: References: Message-ID: Welcome to the list Jia. Looking forward to working with you on the GSOC. Thanks for introducing yourself. Best, Aashish On Tue, Apr 28, 2015 at 11:35 AM, Jia Chen wrote: > Hi, All, > > My name is Jia Chen, and I just got notified that my proposal to GSoC > project "Improvements to Earth and Space Science Visualization" has been > accepted. So I am writing to introduce myself. I am currently a Ph.D > student at UC Irvine, major in Computer Graphics. In this project, I would > like to enhance VTK's earth and space science visualization module for > geophysical data visualization. > > Geophysical data visualization is an important part for the study of > various areas of earth science, such as oil and mineral exploration, > seismic monitoring etc. Related functions have been integrated into > commercial software like Avizo, Open Inventor, Geoviz, etc. But in open > source community, we still lack such software to provide solution for > visualizing these kinds of data. In this project, I would like to add > support for visualizing geophysical objects in VTK. The full text of my > proposal can be found from link > . > > > If you or your friends need such geophysical data visualization features, > or you have suggestions on the project, please let me know. All > suggestions are highly appreciated, and looking forward to spending an > exciting summer working with you all. > > Best Regards, > Jia > > > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Apr 29 08:57:54 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 29 Apr 2015 08:57:54 -0400 Subject: [vtk-developers] Need help with a crash on Kamino OSX Release mode. In-Reply-To: References: <20150429025840.868205794@mail.rogue-research.com> Message-ID: The call stack for the out of range subscript assertion is: msvcp120d.dll!00007fff4d2765d6() Unknown vtkChartsCore-6.3.dll!std::vector,std::allocator > >::operator[](unsigned __int64 _Pos) Line 1202 C++ vtkChartsCore-6.3.dll!vtkChartMatrix::GetChart(const vtkVector2i & position) Line 223 C++ vtkChartsCore-6.3.dll!vtkScatterPlotMatrix::SetActivePlot(const vtkVector2i & pos) Line 402 C++ > vtkChartsCorePython27D-6.3.dll!PyvtkScatterPlotMatrix_SetActivePlot(_object * self, _object * args) Line 213 C++ python27.dll!000000001e0c2199() Unknown Looks like vtkScatterPlotMatrix_SetActivePlot can't be called from this test because other stuff that it depends on for proper operation is not usable as-initialized. This indicates to me that it may only be luck when it succeeds on non-VS-Debug builds, since the uninitialized variables, assuming that's what the cause is, will contain random contents when the test runs. When I add "vtkScatterPlotMatrix" as a Windows exception, the test passes on this build. I always love running Debug Visual Studio builds for catching easy errors like uninitialized variables and out of subscript references... HTH, D On Wed, Apr 29, 2015 at 8:38 AM, David Cole wrote: > I ran a build on my machine, named trivet, a Debug 64-bit build from > VS 2013, and the test fails with a single assertion failure and 10-20 > mem leaks: > > https://open.cdash.org/testDetails.php?test=331705794&build=3791568 > > Perhaps the "C:\Program Files (x86)\Microsoft Visual Studio > 12.0\VC\INCLUDE\vector(1201) : Assertion failed: vector subscript out > of range" report indicates the *real* cause of the problem on the Mac > Release build. I'm not sure which class/method that comes from, but > I'm about to run it and try to find out. > > > David C. > > > > On Wed, Apr 29, 2015 at 2:23 AM, Andrew Maclean > wrote: >> He Sean, >> >> I should clarify this a bit more. >> vtkDataEncoder invokes a thread pool which doesn't clean up after use, hence >> the crashes after program execution, adding vtkDataEncoder to the list of >> excluded classes "almost" fixed this. >> However Windows was still crashing when the program was run again, so, >> adding vtkWebApplication (which is the only class that calls >> vtkDataEncoder), to the list of excluded classes, fixed this issue. >> >> Notwithstanding this, it is puzzling, as I said in the previous e-mail as to >> why on Kamino we get a SIGSEGV at 0x0 address not mapped to object since >> vtkView is specifically excluded. >> >> Regards >> Andrew >> >> >> >> On Wed, Apr 29, 2015 at 1:32 PM, Andrew Maclean >> wrote: >>> >>> Hi Sean, >>> >>> Yes, vtkDataEncoder and vtkWebApplication (which uses it) are excluded >>> form TestSetGet.py and TestEmptyInput.py. This fixed the crashes and also >>> the crash in windows when the program was run again. I think Windows was a >>> bit slow recovering memory. after program execution. >>> >>> What is puzzling is that TestGetSet excludes vtkView so >>> vtkView.SetRepresentation() is never tested, this only fails on Kamino >>> (release). It passes on trey (osX release) and also on megas. >>> >>> Regards >>> Andrew >>> >>> >>> On Wed, Apr 29, 2015 at 12:58 PM, Sean McBride >>> wrote: >>>> >>>> Did you fix the use-after-free we discussed on this list a few weeks ago? >>>> >>>> Sean >>>> >>>> >>>> >>>> On Wed, 29 Apr 2015 12:07:35 +1000, Andrew Maclean said: >>>> >>>> >David, >>>> > Thanks for your insights. >>>> >Just finished testing this code on my Macbook Pro OS X Yosemite, Python >>>> >2.7.6 after building VTK in both Debug and Release mode. Everything runs >>>> > Ok >>>> >so I don't think it is a typedef or macro related to a release build on >>>> > OS >>>> >X. >>>> > >>>> >Has anyone else got any suggestions? >>>> > >>>> > >>>> >Regards >>>> > Andrew >>>> > >>>> >On Wed, Apr 29, 2015 at 2:23 AM, David Gobbi >>>> > wrote: >>>> > >>>> >> Hi Andrew, >>>> >> >>>> >> The stack trace provides strong evidence that TestSetGet.py is not >>>> >> excluding vtkView on those dashboards, as ludicrous as that sounds. >>>> >> >>>> >> c++filt -n _ZL27PyvtkView_SetRepresentationP7_objectS0_ >>>> >> PyvtkView_SetRepresentation(_object*, _object*) >>>> >> >>>> >> This method is only defined in vtkViewPython.cxx, and only >>>> >> dir(vtk.vtkView) will return this method. Calling dir() on the >>>> >> vtkView >>>> >> subclasses will not return this method. Hence, the only reason that >>>> >> TestSetGet.py would be calling this method is if it was testing >>>> >> vtkView. >>>> >> >>>> >> Perhaps someone added either a typedef or a macro that causes an >>>> >> additional reference to vtkView to appear in the vtk module under a >>>> >> different name. >>>> >> >>>> >> - David >>>> >> >>>> >> On Tue, Apr 28, 2015 at 1:42 AM, Andrew Maclean >>>> >> >>> >> > wrote: >>>> >> >>>> >>> Hi All, >>>> >>> I need some help here. >>>> >>> >>>> >>> I have converted TestSetGet.tcl to Python but I get a crash on the >>>> >>> dashboard for kamino building osx in release mode, here: >>>> >>> https://open.cdash.org/buildSummary.php?buildid=3789971 >>>> >>> and here: >>>> >>> https://open.cdash.org/buildSummary.php?buildid=3789950 >>>> >>> >>>> >>> In an earlier attempt, linux release on megas was also crashing in >>>> >>> release mode: >>>> >>> https://open.cdash.org/testDetails.php?test=331289192&build=3789418 >>>> >>> Based on this I excluded vtkScatterPlotMatrix which fixed it on megas >>>> >>> but >>>> >>> not on Kamino. >>>> >>> So I excluded vtkChartMatrix and I still have the same errors on >>>> >>> Kamino. >>>> >>> But there are no clues as to where the crash is happening. However in >>>> >>> looking at: >>>> >>> https://open.cdash.org/testDetails.php?test=331378847&build=3789950 >>>> >>> I think it is in vtkView - which is already excluded. >>>> >>> This could be the problem: >>>> >>> void SetRepresentation (vtkDataRepresentation *rep) >>>> >>> vtkDataRepresentation * GetRepresentation (int index=0) >>>> >>> >>>> >>> Can anyone help? >>>> >>> >>>> >>> I guess I can try excluding all the *View classes as documented in: >>>> >>> http://www.vtk.org/doc/nightly/html/classvtkView.html >>>> >>> Is there a less brute-force approach? >>>> >>> >>>> >>> >>>> >>> The code is here: >>>> >>> https://gitlab.kitware.com/vtk/vtk/merge_requests/151 >>>> >>> >>>> >>> Thanks in advance for any help/guidance. >>>> >>>> >>> >>> >>> >>> -- >>> ___________________________________________ >>> Andrew J. P. Maclean >>> >>> ___________________________________________ >> >> >> >> >> -- >> ___________________________________________ >> Andrew J. P. Maclean >> >> ___________________________________________ >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> From majcjc at gmail.com Wed Apr 29 10:33:37 2015 From: majcjc at gmail.com (Lin M) Date: Wed, 29 Apr 2015 10:33:37 -0400 Subject: [vtk-developers] GSoC 2015 Project - CAD Model and Simulation Spline Visualization In-Reply-To: References: Message-ID: Hi Goodwin, Thank you! I'll take a look at it. Best, Lin On Wed, Apr 29, 2015 at 6:31 AM, Goodwin Lawlor < goodwin.lawlor.lists at gmail.com> wrote: > Hi Lin, > > You should take a look at this tread on vtk-dev: > http://markmail.org/message/h2n6c3e3igdcqhvq > > Prashanth Udupa wrote a class vtkBezierSurfaceSource - source code > available I believe but I'm not sure about the licence. > > Best of luck > > Goodwin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Apr 29 13:50:53 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 29 Apr 2015 13:50:53 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... Message-ID: The commit message here: https://gitlab.kitware.com/vtk/vtk/commit/7247da0ecf23c2c52e90acc86dda2e2bbf33461a claims there was some sort of problem with make_pair and double. What exactly was the problem? With what exact version of MSVC? (I don't buy that there's a general problem with make_pair and double...) And then the follow on commit message: https://gitlab.kitware.com/vtk/vtk/commit/e3d0653de443435533ebfb2db3fa6513e3b5c86b seems a bit accusatory towards poor old closed-source MSVC. This code compiles just fine for me with Visual Studio 2013: bool TestMakePair() { const double value = 0.0; vtkTextProperty *prop = NULL; std::pair pairOne = std::make_pair(value, prop); return true; } Of course, make_pair deduces its types from the supplied arguments, so passing "NULL" as the second arg is not exactly well defined across all OSes and compilers. Not sure why you would expect that. Anyhow.... This email is simply a request to remove the disparaging remarks about "Windows" and MSVC from the comments, and to be kinder and gentler in future commit messages. Writing thoughtful explanatory commit messages is nearly as important as writing the code for a widely used public open source project. Nobody likes dealing with "the other platforms" that they don't work on daily, but we all love how VTK works awesomely on so many platforms. It's worth the extra effort to get code just right so it compiles cleanly everywhere, and commentary like this just turns me off. Thanks for listening, David C. From david.lonie at kitware.com Wed Apr 29 14:12:07 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 29 Apr 2015 14:12:07 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... In-Reply-To: References: Message-ID: On Wed, Apr 29, 2015 at 1:50 PM, David Cole wrote: > The commit message here: > > > https://gitlab.kitware.com/vtk/vtk/commit/7247da0ecf23c2c52e90acc86dda2e2bbf33461a > > claims there was some sort of problem with make_pair and double. What > exactly was the problem? With what exact version of MSVC? (I don't buy > that there's a general problem with make_pair and double...) > > And then the follow on commit message: > > > https://gitlab.kitware.com/vtk/vtk/commit/e3d0653de443435533ebfb2db3fa6513e3b5c86b > > seems a bit accusatory towards poor old closed-source MSVC. > This code compiles just fine for me with Visual Studio 2013: > > bool TestMakePair() > { > const double value = 0.0; > vtkTextProperty *prop = NULL; > > std::pair pairOne = > std::make_pair(value, prop); > > return true; > } > Now try std::make_pair(value, NULL). > Of course, make_pair deduces its types from the supplied arguments, so > passing "NULL" as the second arg is not exactly well defined across > all OSes and compilers. Not sure why you would expect that. > Telling it the first argument is explicitly a double and the second is a pointer, and then having it complain about the double with one syntax and the pointer in the other (both while being explicitly declared in the template arguements) is a tad ridiculous, IMO. > Anyhow.... This email is simply a request to remove the disparaging > remarks about "Windows" and MSVC from the comments, and to be kinder > and gentler in future commit messages. Writing thoughtful explanatory > commit messages is nearly as important as writing the code for a > widely used public open source project. > Not sure they can be removed. I don't think this warrants rewriting the commit history. > Nobody likes dealing with "the other platforms" that they don't work > on daily, but we all love how VTK works awesomely on so many > platforms. It's worth the extra effort to get code just right so it > compiles cleanly everywhere, and I don't mind, actually, But if something ridiculous happens, I'm going to find it ridiculous. Besides, "putting in the extra effort to get code right" is exactly what those commits are doing...? > commentary like this just turns me > off. > Sorry to turn you off, Dave. I meant no offense, but apologize for any that was taken. Writing code that works on every platform but one, and then fails in two distinct ways on different version of the primary compiler for that platform is surely frustrating, no? If GCC was behaving similarly, I'd have similar frustrations. I'm not trying to play favorites and disparage anyone's favorite platform. There are annoyances with every compiler (admittedly, some more than others!), and I view my commit messages as harmless venting. I still don't see them as expressing anything offensive, just frustration at a couple of idiosyncrasies. Less than absolutely professional? Sure. Restrained expression of legitimate frustration? I'd say "sure" to that as well. Offensive? Well, that's a bit of a stretch IMO. Different strokes. Regardless, I'll make an effort to adopt a more neutral tone in my commit messages. Have a great day, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Wed Apr 29 14:37:29 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Wed, 29 Apr 2015 14:37:29 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... In-Reply-To: References: Message-ID: I would say to Dave Cole's point that I have personally seen several problems in the very modest development efforts I have been doing on Windows (e.g., vtkSMPTools related) mostly in the CMake files, etc. Every compiler/platform has something good to say and we need to listen. This ensures that our software remains world class, despite our personal religious beliefs :-) Actually I actually think more of us need to build on Windows/MSVC because stuff is falling through the cracks. W On Wed, Apr 29, 2015 at 2:12 PM, David Lonie wrote: > On Wed, Apr 29, 2015 at 1:50 PM, David Cole wrote: > >> The commit message here: >> >> >> https://gitlab.kitware.com/vtk/vtk/commit/7247da0ecf23c2c52e90acc86dda2e2bbf33461a >> >> claims there was some sort of problem with make_pair and double. What >> exactly was the problem? With what exact version of MSVC? (I don't buy >> that there's a general problem with make_pair and double...) >> >> And then the follow on commit message: >> >> >> https://gitlab.kitware.com/vtk/vtk/commit/e3d0653de443435533ebfb2db3fa6513e3b5c86b >> >> seems a bit accusatory towards poor old closed-source MSVC. > > >> This code compiles just fine for me with Visual Studio 2013: >> >> bool TestMakePair() >> { >> const double value = 0.0; >> vtkTextProperty *prop = NULL; >> >> std::pair pairOne = >> std::make_pair(value, prop); >> >> return true; >> } >> > > Now try std::make_pair(value, NULL). > > >> Of course, make_pair deduces its types from the supplied arguments, so >> passing "NULL" as the second arg is not exactly well defined across >> all OSes and compilers. Not sure why you would expect that. >> > > Telling it the first argument is explicitly a double and the second is a > pointer, and then having it complain about the double with one syntax and > the pointer in the other (both while being explicitly declared in the > template arguements) is a tad ridiculous, IMO. > > >> Anyhow.... This email is simply a request to remove the disparaging >> remarks about "Windows" and MSVC from the comments, and to be kinder >> and gentler in future commit messages. Writing thoughtful explanatory >> commit messages is nearly as important as writing the code for a >> widely used public open source project. >> > > Not sure they can be removed. I don't think this warrants rewriting the > commit history. > > >> Nobody likes dealing with "the other platforms" that they don't work >> on daily, but we all love how VTK works awesomely on so many >> platforms. It's worth the extra effort to get code just right so it >> compiles cleanly everywhere, and > > > I don't mind, actually, But if something ridiculous happens, I'm going to > find it ridiculous. Besides, "putting in the extra effort to get code > right" is exactly what those commits are doing...? > > >> commentary like this just turns me >> off. >> > > Sorry to turn you off, Dave. I meant no offense, but apologize for any > that was taken. Writing code that works on every platform but one, and then > fails in two distinct ways on different version of the primary compiler for > that platform is surely frustrating, no? If GCC was behaving similarly, I'd > have similar frustrations. > > I'm not trying to play favorites and disparage anyone's favorite platform. > There are annoyances with every compiler (admittedly, some more than > others!), and I view my commit messages as harmless venting. I still don't > see them as expressing anything offensive, just frustration at a couple of > idiosyncrasies. Less than absolutely professional? Sure. Restrained > expression of legitimate frustration? I'd say "sure" to that as well. > Offensive? Well, that's a bit of a stretch IMO. Different strokes. > > Regardless, I'll make an effort to adopt a more neutral tone in my commit > messages. > > Have a great day, > Dave > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 DLRdave at aol.com Wed Apr 29 14:40:09 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 29 Apr 2015 14:40:09 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... In-Reply-To: References: Message-ID: I understand frustration, and venting. I'm not super offended, just slightly turned off... And asking you to do future venting outside the VTK git commit history. I'm not asking you to re-write the commit history now. What's done is done there -- but I am still asking two specific questions, that got lost in my "too many words" of the first email: (1) what was the problem with double and make_pair -- or was that a misleading commit message because the problem was always with the use of NULL ... ? (2) Will you please rephrase the comment here in a future commit? https://gitlab.kitware.com/vtk/vtk/commit/e3d0653de443435533ebfb2db3fa6513e3b5c86b#7d40499821cd2f098d779d9b0da192039787a70a_587_594 because it's simply not true. My code snippet proves that MSVC 2013's make_pair does NOT have a problem with double -- it has a problem with arguments of poorly defined type. NULL is possibly just "0" under some circumstances, which has type "int." If you construct a local variable of the correct type, with value NULL, then make_pair has no problem deducing the correct type. Thanks, David C. On Wed, Apr 29, 2015 at 2:12 PM, David Lonie wrote: > On Wed, Apr 29, 2015 at 1:50 PM, David Cole wrote: >> >> The commit message here: >> >> >> https://gitlab.kitware.com/vtk/vtk/commit/7247da0ecf23c2c52e90acc86dda2e2bbf33461a >> >> claims there was some sort of problem with make_pair and double. What >> exactly was the problem? With what exact version of MSVC? (I don't buy >> that there's a general problem with make_pair and double...) >> >> And then the follow on commit message: >> >> >> https://gitlab.kitware.com/vtk/vtk/commit/e3d0653de443435533ebfb2db3fa6513e3b5c86b >> >> seems a bit accusatory towards poor old closed-source MSVC. >> >> >> This code compiles just fine for me with Visual Studio 2013: >> >> bool TestMakePair() >> { >> const double value = 0.0; >> vtkTextProperty *prop = NULL; >> >> std::pair pairOne = >> std::make_pair(value, prop); >> >> return true; >> } > > > Now try std::make_pair(value, NULL). > >> >> Of course, make_pair deduces its types from the supplied arguments, so >> passing "NULL" as the second arg is not exactly well defined across >> all OSes and compilers. Not sure why you would expect that. > > > Telling it the first argument is explicitly a double and the second is a > pointer, and then having it complain about the double with one syntax and > the pointer in the other (both while being explicitly declared in the > template arguements) is a tad ridiculous, IMO. > >> >> Anyhow.... This email is simply a request to remove the disparaging >> remarks about "Windows" and MSVC from the comments, and to be kinder >> and gentler in future commit messages. Writing thoughtful explanatory >> commit messages is nearly as important as writing the code for a >> widely used public open source project. > > > Not sure they can be removed. I don't think this warrants rewriting the > commit history. > >> >> Nobody likes dealing with "the other platforms" that they don't work >> on daily, but we all love how VTK works awesomely on so many >> platforms. It's worth the extra effort to get code just right so it >> compiles cleanly everywhere, and > > > I don't mind, actually, But if something ridiculous happens, I'm going to > find it ridiculous. Besides, "putting in the extra effort to get code right" > is exactly what those commits are doing...? > >> >> commentary like this just turns me >> off. > > > Sorry to turn you off, Dave. I meant no offense, but apologize for any that > was taken. Writing code that works on every platform but one, and then fails > in two distinct ways on different version of the primary compiler for that > platform is surely frustrating, no? If GCC was behaving similarly, I'd have > similar frustrations. > > I'm not trying to play favorites and disparage anyone's favorite platform. > There are annoyances with every compiler (admittedly, some more than > others!), and I view my commit messages as harmless venting. I still don't > see them as expressing anything offensive, just frustration at a couple of > idiosyncrasies. Less than absolutely professional? Sure. Restrained > expression of legitimate frustration? I'd say "sure" to that as well. > Offensive? Well, that's a bit of a stretch IMO. Different strokes. > > Regardless, I'll make an effort to adopt a more neutral tone in my commit > messages. > > Have a great day, > Dave From david.lonie at kitware.com Wed Apr 29 14:50:17 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 29 Apr 2015 14:50:17 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... In-Reply-To: References: Message-ID: On Wed, Apr 29, 2015 at 2:40 PM, David Cole wrote: > (1) what was the problem with double and make_pair -- or was that a > misleading commit message because the problem was always with the use > of NULL ... ? > Nope, it was with the double. See below. > (2) Will you please rephrase the comment here in a future commit? > > https://gitlab.kitware.com/vtk/vtk/commit/e3d0653de443435533ebfb2db3fa6513e3b5c86b#7d40499821cd2f098d779d9b0da192039787a70a_587_594 No can do, it was merged before the complaint was made: https://github.com/Kitware/VTK/commit/e3d0653de443435533ebfb2db3fa6513e3b5c86b because it's simply not true. My code snippet proves that MSVC 2013's > make_pair does NOT have a problem with double -- it has a problem with > arguments of poorly defined type. NULL is possibly just "0" under some > circumstances, which has type "int." If you construct a local variable > of the correct type, with value NULL, then make_pair has no problem > deducing the correct type. The first issue was with double: https://open.cdash.org/viewBuildError.php?buildid=3784595 error C2664: 'std::pair std::make_pair(_Ty1 &&,_Ty2 &&)' : cannot convert argument 1 from 'double' to 'double &&' Try the change I suggested to your test snippet in the previous email and it should trigger this. There was a discussion on some windows support forum where they said their implementation did strictly follow the standard and they won't change the compiler, which is fair enough. But I don't think anyone would find that behavior intuitive or expected :P On Wed, Apr 29, 2015 at 2:37 PM, Will Schroeder wrote: > I would say to Dave Cole's point that I have personally seen several > problems in the very modest development efforts I have been doing on > Windows (e.g., vtkSMPTools related) mostly in the CMake files, etc. Every > compiler/platform has something good to say and we need to listen. This > ensures that our software remains world class, despite our personal > religious beliefs :-) Actually I actually think more of us need to build on > Windows/MSVC because stuff is falling through the cracks. > Agreed that all platforms should be well tested and supported. I think the real question with your issue is, why didn't the dashboards catch these problems? Is there some way we could have caught them with a nightly/continuous test? Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcus.hanwell at kitware.com Wed Apr 29 15:31:16 2015 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 29 Apr 2015 15:31:16 -0400 Subject: [vtk-developers] Welcoming Google Summer of Code students Message-ID: Hi, I wanted to take this opportunity to welcome our new Google Summer of Code students to the list. We have six student projects this year, twice what we had last year. If you haven't already introduced yourself and your project please do, you can check out the list here, http://www.google-melange.com/gsoc/org2/google/gsoc2015/vtk You can also see the student's primary mentor, and click on the individual projects for a short description. We will be encouraging our students to report progress to the development list, and get changes merged early where possible. Dave DeMarle and I are the project administrators this year. Please welcome our students, and feel free to chip in if you have any advice for them as they get started. This is our third summer of code as VTK, and I am looking forward to working with our new students over the summer. Best, Marcus From sean at rogue-research.com Wed Apr 29 15:44:07 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 29 Apr 2015 15:44:07 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... In-Reply-To: References: Message-ID: <20150429194407.1570541337@mail.rogue-research.com> On Wed, 29 Apr 2015 13:50:53 -0400, David Cole via vtk-developers said: >claims there was some sort of problem with make_pair and double. What >exactly was the problem? With what exact version of MSVC? (I don't buy >that there's a general problem with make_pair and double...) I'll steer clear of the larger point... :) but will just say: when adding workarounds for problematic compilers / OSes, it would be very appreciated to be clear about which versions. As someone who has gone through VTK to expunge obsolete workarounds, it's sometimes been hard to know what's obsolete and what's not. A lot of workaround notes say things like "on Apple this is broken", but which OS version is not stated... Try to think of the future in commit messages and code comments. :) 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 david.lonie at kitware.com Wed Apr 29 15:54:16 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 29 Apr 2015 15:54:16 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... In-Reply-To: <20150429194407.1570541337@mail.rogue-research.com> References: <20150429194407.1570541337@mail.rogue-research.com> Message-ID: On Wed, Apr 29, 2015 at 3:44 PM, Sean McBride wrote: > On Wed, 29 Apr 2015 13:50:53 -0400, David Cole via vtk-developers said: > > >claims there was some sort of problem with make_pair and double. What > >exactly was the problem? With what exact version of MSVC? (I don't buy > >that there's a general problem with make_pair and double...) > > I'll steer clear of the larger point... :) but will just say: when adding > workarounds for problematic compilers / OSes, it would be very appreciated > to be clear about which versions. As someone who has gone through VTK to > expunge obsolete workarounds, it's sometimes been hard to know what's > obsolete and what's not. A lot of workaround notes say things like "on > Apple this is broken", but which OS version is not stated... > > Try to think of the future in commit messages and code comments. :) +1. In this case, the workaround is still valid code, no alternate paths, and just a slight change in syntax, so we won't have to worry about removing it in the future :D I did leave a note in-line warning future maintainers that the line is troublesome for MSVC and should be treated with caution. I am somewhat curious what version of the compiler this was too, I can't really tell from the CDash page: https://open.cdash.org/viewBuildError.php?buildid=3784595 IIRC, we used to have this prominently displayed in the build name. Looks like that got dropped somewhere along the way. I'll see if we can get that info back in. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Wed Apr 29 15:58:11 2015 From: david.lonie at kitware.com (David Lonie) Date: Wed, 29 Apr 2015 15:58:11 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... In-Reply-To: References: <20150429194407.1570541337@mail.rogue-research.com> Message-ID: On Wed, Apr 29, 2015 at 3:54 PM, David Lonie wrote: > On Wed, Apr 29, 2015 at 3:44 PM, Sean McBride > wrote: > >> On Wed, 29 Apr 2015 13:50:53 -0400, David Cole via vtk-developers said: >> >> >claims there was some sort of problem with make_pair and double. What >> >exactly was the problem? With what exact version of MSVC? (I don't buy >> >that there's a general problem with make_pair and double...) >> >> I'll steer clear of the larger point... :) but will just say: when >> adding workarounds for problematic compilers / OSes, it would be very >> appreciated to be clear about which versions. As someone who has gone >> through VTK to expunge obsolete workarounds, it's sometimes been hard to >> know what's obsolete and what's not. A lot of workaround notes say things >> like "on Apple this is broken", but which OS version is not stated... >> >> Try to think of the future in commit messages and code comments. :) > > > +1. In this case, the workaround is still valid code, no alternate paths, > and just a slight change in syntax, so we won't have to worry about > removing it in the future :D I did leave a note in-line warning future > maintainers that the line is troublesome for MSVC and should be treated > with caution. > > I am somewhat curious what version of the compiler this was too, I can't > really tell from the CDash page: > > https://open.cdash.org/viewBuildError.php?buildid=3784595 > It was MSVC 13, for anyone who's curious. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Wed Apr 29 16:04:09 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Wed, 29 Apr 2015 16:04:09 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... In-Reply-To: References: <20150429194407.1570541337@mail.rogue-research.com> Message-ID: It has to be 2012 or newer as this is a noted break in functionality between C++98 and C++11 ( and forward ). Here is the excerpt on what has changed: " Following a breaking change between the C++98/03 and C++11 standards, using explicit template arguments to call make_pair()?as in make_pair(x, y)?typically does not compile in Visual C++ in Visual Studio 2012. The solution is to always call make_pair() without explicit template arguments?as in make_pair(x, y). Providing explicit template arguments defeats the purpose of the function. If you require precise control over the resulting type, use pair instead of make_pair?as in pair(int1, int2). Another breaking change between the C++98/03 and C++11 standards: When A is implicitly convertible to B and B is implicitly convertible to C, but A is not implicitly convertible to C, C++98/03 and Visual C++ 2010 permitted pair to be converted (implicitly or explicitly) to pair. (The other type, X, is not of interest here, and this is not specific to the first type in the pair.) Because C++11 and Visual C++ in Visual Studio 2012 detect that A is not implicitly convertible to C, they remove the pair conversion from overload resolution. This is a positive change for many scenarios. For example, overloading func(const pair&) and func(const pair&), and calling func() with pair will compile with this change. However, this change breaks code that relied on aggressive pair conversions. Such code can typically be fixed by performing one part of the conversion explicitly?for example, by passing make_pair(static_cast(a), x) to a function that expects pair. " The reason that we haven't seen this with other compilers is either they haven't enabled C++11 (with c++11 standard library) or they compile options are lax and allow this behavior. This is the challenge of supporting Visual Studio 2010 and forward, they only compile with C++11 enabled which causes these very subtle issues. Note because we require C++98 support we can't use the approach that Visual Studio recommends article: https://msdn.microsoft.com/en-us/library/vstudio/bb531344%28v=vs.110%29.aspx On Wed, Apr 29, 2015 at 3:54 PM, David Lonie wrote: > On Wed, Apr 29, 2015 at 3:44 PM, Sean McBride > wrote: >> >> On Wed, 29 Apr 2015 13:50:53 -0400, David Cole via vtk-developers said: >> >> >claims there was some sort of problem with make_pair and double. What >> >exactly was the problem? With what exact version of MSVC? (I don't buy >> >that there's a general problem with make_pair and double...) >> >> I'll steer clear of the larger point... :) but will just say: when adding >> workarounds for problematic compilers / OSes, it would be very appreciated >> to be clear about which versions. As someone who has gone through VTK to >> expunge obsolete workarounds, it's sometimes been hard to know what's >> obsolete and what's not. A lot of workaround notes say things like "on >> Apple this is broken", but which OS version is not stated... >> >> Try to think of the future in commit messages and code comments. :) > > > +1. In this case, the workaround is still valid code, no alternate paths, > and just a slight change in syntax, so we won't have to worry about removing > it in the future :D I did leave a note in-line warning future maintainers > that the line is troublesome for MSVC and should be treated with caution. > > I am somewhat curious what version of the compiler this was too, I can't > really tell from the CDash page: > > https://open.cdash.org/viewBuildError.php?buildid=3784595 > > IIRC, we used to have this prominently displayed in the build name. Looks > like that got dropped somewhere along the way. I'll see if we can get that > info back in. > > Dave > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > From DLRdave at aol.com Wed Apr 29 17:52:42 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 29 Apr 2015 17:52:42 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... In-Reply-To: References: <20150429194407.1570541337@mail.rogue-research.com> Message-ID: Thanks for the discussion. I did try what you said, and I do reproduce the error you saw, ... but I still say it's not a general problem with double and make_pair. make_pair ought to be use-able without specifying types. If you have to specify the type of a pair, then you should just use pair directly as you've ended up with. The extra cast you needed for VS2010 is the real shame. There would be 4 alternative ways to write the same line of code that do use make_pair. All of these work with VS 2013, and I suspect they would also work with VS 2010. (I'll verify if you would like me to.) vtkTextProperty *prop = NULL; std::make_pair(value, prop); std::make_pair(value, reinterpret_cast(NULL)); std::make_pair(value, static_cast(NULL)); std::make_pair(value, (vtkTextProperty*) NULL); More discussion of the general issue: http://stackoverflow.com/questions/9270563/purpose-of-stdmake-pair I will propose a patch that rephrases the in-code comments about this if nobody else has the time to do so. Thanks, David C. On Wed, Apr 29, 2015 at 4:04 PM, Robert Maynard wrote: > It has to be 2012 or newer as this is a noted break in functionality > between C++98 and C++11 ( and forward ). > > Here is the excerpt on what has changed: > " > > Following a breaking change between the C++98/03 and C++11 standards, > using explicit template arguments to call make_pair()?as in > make_pair(x, y)?typically does not compile in Visual C++ in > Visual Studio 2012. The solution is to always call make_pair() without > explicit template arguments?as in make_pair(x, y). Providing explicit > template arguments defeats the purpose of the function. If you require > precise control over the resulting type, use pair instead > of make_pair?as in pair(int1, int2). > > > Another breaking change between the C++98/03 and C++11 standards: When > A is implicitly convertible to B and B is implicitly convertible to C, > but A is not implicitly convertible to C, C++98/03 and Visual C++ 2010 > permitted pair to be converted (implicitly or explicitly) to > pair. (The other type, X, is not of interest here, and this is > not specific to the first type in the pair.) Because C++11 and Visual > C++ in Visual Studio 2012 detect that A is not implicitly convertible > to C, they remove the pair conversion from overload resolution. This > is a positive change for many scenarios. For example, overloading > func(const pair&) and func(const pair&), and > calling func() with pair will compile with > this change. However, this change breaks code that relied on > aggressive pair conversions. Such code can typically be fixed by > performing one part of the conversion explicitly?for example, by > passing make_pair(static_cast(a), x) to a function that expects > pair. > > " > The reason that we haven't seen this with other compilers is either > they haven't enabled C++11 (with c++11 standard library) or they > compile options are lax and allow this behavior. This is the challenge > of supporting Visual Studio 2010 and forward, they only compile with > C++11 enabled which causes these very subtle issues. > > Note because we require C++98 support we can't use the approach that > Visual Studio recommends > > article: https://msdn.microsoft.com/en-us/library/vstudio/bb531344%28v=vs.110%29.aspx > > On Wed, Apr 29, 2015 at 3:54 PM, David Lonie wrote: >> On Wed, Apr 29, 2015 at 3:44 PM, Sean McBride >> wrote: >>> >>> On Wed, 29 Apr 2015 13:50:53 -0400, David Cole via vtk-developers said: >>> >>> >claims there was some sort of problem with make_pair and double. What >>> >exactly was the problem? With what exact version of MSVC? (I don't buy >>> >that there's a general problem with make_pair and double...) >>> >>> I'll steer clear of the larger point... :) but will just say: when adding >>> workarounds for problematic compilers / OSes, it would be very appreciated >>> to be clear about which versions. As someone who has gone through VTK to >>> expunge obsolete workarounds, it's sometimes been hard to know what's >>> obsolete and what's not. A lot of workaround notes say things like "on >>> Apple this is broken", but which OS version is not stated... >>> >>> Try to think of the future in commit messages and code comments. :) >> >> >> +1. In this case, the workaround is still valid code, no alternate paths, >> and just a slight change in syntax, so we won't have to worry about removing >> it in the future :D I did leave a note in-line warning future maintainers >> that the line is troublesome for MSVC and should be treated with caution. >> >> I am somewhat curious what version of the compiler this was too, I can't >> really tell from the CDash page: >> >> https://open.cdash.org/viewBuildError.php?buildid=3784595 >> >> IIRC, we used to have this prominently displayed in the build name. Looks >> like that got dropped somewhere along the way. I'll see if we can get that >> info back in. >> >> Dave >> >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From andrew.amaclean at gmail.com Wed Apr 29 20:09:05 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Thu, 30 Apr 2015 10:09:05 +1000 Subject: [vtk-developers] Need help with a crash on Kamino OSX Release mode. In-Reply-To: References: <20150429025840.868205794@mail.rogue-research.com> Message-ID: Hi David, Thanks for this. I have just added vtkScatterPlotMatrix along with vtkChartMatrix back, oddly enough my windows machine never picked it up but one of the linux buildbots did once. Then I took it out and everything seemed ok, it's back in now. I totally agree with you over the usefulness of Debug Visual Studio! It is my main bug catcher. I use a little utility called Path Editor to reorder the release and debug lib and bin paths in the environment variables (PYTHONPATH and PATH). Regards Andrew On Wed, Apr 29, 2015 at 10:57 PM, David Cole wrote: > The call stack for the out of range subscript assertion is: > > msvcp120d.dll!00007fff4d2765d6() Unknown > > vtkChartsCore-6.3.dll!std::vector,std::allocator > > >::operator[](unsigned __int64 _Pos) Line 1202 C++ > vtkChartsCore-6.3.dll!vtkChartMatrix::GetChart(const vtkVector2i & > position) Line 223 C++ > vtkChartsCore-6.3.dll!vtkScatterPlotMatrix::SetActivePlot(const > vtkVector2i & pos) Line 402 C++ > > > vtkChartsCorePython27D-6.3.dll!PyvtkScatterPlotMatrix_SetActivePlot(_object > * self, _object * args) Line 213 C++ > python27.dll!000000001e0c2199() Unknown > > Looks like vtkScatterPlotMatrix_SetActivePlot can't be called from > this test because other stuff that it depends on for proper operation > is not usable as-initialized. This indicates to me that it may only be > luck when it succeeds on non-VS-Debug builds, since the uninitialized > variables, assuming that's what the cause is, will contain random > contents when the test runs. > > When I add "vtkScatterPlotMatrix" as a Windows exception, the test > passes on this build. > > I always love running Debug Visual Studio builds for catching easy > errors like uninitialized variables and out of subscript references... > > > HTH, > D > > > On Wed, Apr 29, 2015 at 8:38 AM, David Cole wrote: > > I ran a build on my machine, named trivet, a Debug 64-bit build from > > VS 2013, and the test fails with a single assertion failure and 10-20 > > mem leaks: > > > > https://open.cdash.org/testDetails.php?test=331705794&build=3791568 > > > > Perhaps the "C:\Program Files (x86)\Microsoft Visual Studio > > 12.0\VC\INCLUDE\vector(1201) : Assertion failed: vector subscript out > > of range" report indicates the *real* cause of the problem on the Mac > > Release build. I'm not sure which class/method that comes from, but > > I'm about to run it and try to find out. > > > > > > David C. > > > > > > > > On Wed, Apr 29, 2015 at 2:23 AM, Andrew Maclean > > wrote: > >> He Sean, > >> > >> I should clarify this a bit more. > >> vtkDataEncoder invokes a thread pool which doesn't clean up after use, > hence > >> the crashes after program execution, adding vtkDataEncoder to the list > of > >> excluded classes "almost" fixed this. > >> However Windows was still crashing when the program was run again, so, > >> adding vtkWebApplication (which is the only class that calls > >> vtkDataEncoder), to the list of excluded classes, fixed this issue. > >> > >> Notwithstanding this, it is puzzling, as I said in the previous e-mail > as to > >> why on Kamino we get a SIGSEGV at 0x0 address not mapped to object since > >> vtkView is specifically excluded. > >> > >> Regards > >> Andrew > >> > >> > >> > >> On Wed, Apr 29, 2015 at 1:32 PM, Andrew Maclean < > andrew.amaclean at gmail.com> > >> wrote: > >>> > >>> Hi Sean, > >>> > >>> Yes, vtkDataEncoder and vtkWebApplication (which uses it) are excluded > >>> form TestSetGet.py and TestEmptyInput.py. This fixed the crashes and > also > >>> the crash in windows when the program was run again. I think Windows > was a > >>> bit slow recovering memory. after program execution. > >>> > >>> What is puzzling is that TestGetSet excludes vtkView so > >>> vtkView.SetRepresentation() is never tested, this only fails on Kamino > >>> (release). It passes on trey (osX release) and also on megas. > >>> > >>> Regards > >>> Andrew > >>> > >>> > >>> On Wed, Apr 29, 2015 at 12:58 PM, Sean McBride < > sean at rogue-research.com> > >>> wrote: > >>>> > >>>> Did you fix the use-after-free we discussed on this list a few weeks > ago? > >>>> > >>>> Sean > >>>> > >>>> > >>>> > >>>> On Wed, 29 Apr 2015 12:07:35 +1000, Andrew Maclean said: > >>>> > >>>> >David, > >>>> > Thanks for your insights. > >>>> >Just finished testing this code on my Macbook Pro OS X Yosemite, > Python > >>>> >2.7.6 after building VTK in both Debug and Release mode. Everything > runs > >>>> > Ok > >>>> >so I don't think it is a typedef or macro related to a release build > on > >>>> > OS > >>>> >X. > >>>> > > >>>> >Has anyone else got any suggestions? > >>>> > > >>>> > > >>>> >Regards > >>>> > Andrew > >>>> > > >>>> >On Wed, Apr 29, 2015 at 2:23 AM, David Gobbi > >>>> > wrote: > >>>> > > >>>> >> Hi Andrew, > >>>> >> > >>>> >> The stack trace provides strong evidence that TestSetGet.py is not > >>>> >> excluding vtkView on those dashboards, as ludicrous as that sounds. > >>>> >> > >>>> >> c++filt -n _ZL27PyvtkView_SetRepresentationP7_objectS0_ > >>>> >> PyvtkView_SetRepresentation(_object*, _object*) > >>>> >> > >>>> >> This method is only defined in vtkViewPython.cxx, and only > >>>> >> dir(vtk.vtkView) will return this method. Calling dir() on the > >>>> >> vtkView > >>>> >> subclasses will not return this method. Hence, the only reason > that > >>>> >> TestSetGet.py would be calling this method is if it was testing > >>>> >> vtkView. > >>>> >> > >>>> >> Perhaps someone added either a typedef or a macro that causes an > >>>> >> additional reference to vtkView to appear in the vtk module under a > >>>> >> different name. > >>>> >> > >>>> >> - David > >>>> >> > >>>> >> On Tue, Apr 28, 2015 at 1:42 AM, Andrew Maclean > >>>> >> >>>> >> > wrote: > >>>> >> > >>>> >>> Hi All, > >>>> >>> I need some help here. > >>>> >>> > >>>> >>> I have converted TestSetGet.tcl to Python but I get a crash on the > >>>> >>> dashboard for kamino building osx in release mode, here: > >>>> >>> https://open.cdash.org/buildSummary.php?buildid=3789971 > >>>> >>> and here: > >>>> >>> https://open.cdash.org/buildSummary.php?buildid=3789950 > >>>> >>> > >>>> >>> In an earlier attempt, linux release on megas was also crashing in > >>>> >>> release mode: > >>>> >>> > https://open.cdash.org/testDetails.php?test=331289192&build=3789418 > >>>> >>> Based on this I excluded vtkScatterPlotMatrix which fixed it on > megas > >>>> >>> but > >>>> >>> not on Kamino. > >>>> >>> So I excluded vtkChartMatrix and I still have the same errors on > >>>> >>> Kamino. > >>>> >>> But there are no clues as to where the crash is happening. > However in > >>>> >>> looking at: > >>>> >>> > https://open.cdash.org/testDetails.php?test=331378847&build=3789950 > >>>> >>> I think it is in vtkView - which is already excluded. > >>>> >>> This could be the problem: > >>>> >>> void SetRepresentation (vtkDataRepresentation *rep) > >>>> >>> vtkDataRepresentation * GetRepresentation (int index=0) > >>>> >>> > >>>> >>> Can anyone help? > >>>> >>> > >>>> >>> I guess I can try excluding all the *View classes as documented > in: > >>>> >>> http://www.vtk.org/doc/nightly/html/classvtkView.html > >>>> >>> Is there a less brute-force approach? > >>>> >>> > >>>> >>> > >>>> >>> The code is here: > >>>> >>> https://gitlab.kitware.com/vtk/vtk/merge_requests/151 > >>>> >>> > >>>> >>> Thanks in advance for any help/guidance. > >>>> > >>>> > >>> > >>> > >>> > >>> -- > >>> ___________________________________________ > >>> Andrew J. P. Maclean > >>> > >>> ___________________________________________ > >> > >> > >> > >> > >> -- > >> ___________________________________________ > >> Andrew J. P. Maclean > >> > >> ___________________________________________ > >> > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > >> > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From 2130220212 at email.szu.edu.cn Thu Apr 30 07:20:32 2015 From: 2130220212 at email.szu.edu.cn (Jason) Date: Thu, 30 Apr 2015 04:20:32 -0700 (MST) Subject: [vtk-developers] vtkImageReslice with the problem of slice original In-Reply-To: <1430357911572-5731694.post@n5.nabble.com> References: <1430357911572-5731694.post@n5.nabble.com> Message-ID: <1430392832059-5731695.post@n5.nabble.com> I have read David Gobbi's tips in http://vtk.1045678.n5.nabble.com/vtkImageReslice-class-td1233015.html#a1233022 it use x = T*M*x' where "T" is ResliceTransform and "M" is ResliceMatrix to calculate the position in 3D volume(x) by the point position in 2D slice(x') but I'm still wondering that the slice we need cut through and how to use the ResliceTransform(vtkAbstractTransform) to calculate the point position in 3D coordinate. Does just make the x'=(x0,y0,0,1) , M=ResliceAxes ? what about T ? I cannot get its matirx. -- View this message in context: http://vtk.1045678.n5.nabble.com/vtkImageReslice-with-the-problem-of-slice-original-tp5731694p5731695.html Sent from the VTK - Dev mailing list archive at Nabble.com. From david.lonie at kitware.com Thu Apr 30 08:02:10 2015 From: david.lonie at kitware.com (David Lonie) Date: Thu, 30 Apr 2015 08:02:10 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... In-Reply-To: References: <20150429194407.1570541337@mail.rogue-research.com> Message-ID: On Wed, Apr 29, 2015 at 4:04 PM, Robert Maynard wrote: > " > Following a breaking change between the C++98/03 and C++11 standards, > using explicit template arguments to call make_pair()?as in > make_pair(x, y)?typically does not compile in Visual C++ in > Visual Studio 2012. The solution is to always call make_pair() without > explicit template arguments?as in make_pair(x, y). Providing explicit > template arguments defeats the purpose of the function. If you require > precise control over the resulting type, use pair instead > of make_pair?as in pair(int1, int2). > Thanks for finding that. That explains why the std::make_pair(double, X*) call failed. Strange, but I see they're justifying it. Another breaking change between the C++98/03 and C++11 standards: When > A is implicitly convertible to B and B is implicitly convertible to C, > but A is not implicitly convertible to C, C++98/03 and Visual C++ 2010 > permitted pair to be converted (implicitly or explicitly) to > pair. (The other type, X, is not of interest here, and this is > not specific to the first type in the pair.) Because C++11 and Visual > C++ in Visual Studio 2012 detect that A is not implicitly convertible > to C, they remove the pair conversion from overload resolution. This > is a positive change for many scenarios. For example, overloading > func(const pair&) and func(const pair&), and > calling func() with pair will compile with > this change. However, this change breaks code that relied on > aggressive pair conversions. Such code can typically be fixed by > performing one part of the conversion explicitly?for example, by > passing make_pair(static_cast(a), x) to a function that expects > pair. > " > I'm still missing something here. One on of my attempts to get this to compile simultaneously across all of our windows dashboards, this call was failing: std::pair(someDouble, NULL); As I understand it, if NULL is defined as either (int)0, (void*)0, or nullptr (depending on implementation/standard), all of those expressions are implicitly convertible to X* without going through an intermediate, right? To fix it, I had to explicitly cast the NULL to X* for compilation to succeed. What am I missing here? > The reason that we haven't seen this with other compilers is either > they haven't enabled C++11 (with c++11 standard library) or they > compile options are lax and allow this behavior. My guess is the latter. Backward compatibility is a nice thing to have in a compiler ;) On Wed, Apr 29, 2015 at 5:52 PM, David Cole wrote: > Thanks for the discussion. > > I did try what you said, and I do reproduce the error you saw, ... but > I still say it's not a general problem with double and make_pair. > Correct. It'll happen with any explicit type specification on make_pair. > make_pair ought to be use-able without specifying types. If you have > to specify the type of a pair, then you should just use pair type2> directly as you've ended up with. The extra cast you needed for > VS2010 is the real shame. > Agreed. I only added the explicit template arguments as a hint that the NULL should be cast to X*. You can imagine my surprise when that failed because it didn't like the 'double'! I will propose a patch that rephrases the in-code comments about this > if nobody else has the time to do so. > I can see about making the comment I introduced more palatable (I thought you were referring to the commit message earlier...). BTW, if my comments were enough of a turn-off to spark this thread, you may want to grep the code for things like "stupid", "dumb", "moron", "idiot", "s***" and "f***". These all appear in our source code (albeit the stronger language is in contributed modules) and are significantly stronger than any language introduced by my patch. Some are even directed at poor ol' Windows. Might want to check those out and see if you want to air any further grievances ;) Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Thu Apr 30 08:28:02 2015 From: david.lonie at kitware.com (David Lonie) Date: Thu, 30 Apr 2015 08:28:02 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... In-Reply-To: References: <20150429194407.1570541337@mail.rogue-research.com> Message-ID: On Thu, Apr 30, 2015 at 8:02 AM, David Lonie wrote: > On Wed, Apr 29, 2015 at 5:52 PM, David Cole wrote: > >> I will propose a patch that rephrases the in-code comments about this >> > if nobody else has the time to do so. >> > > I can see about making the comment I introduced more palatable (I thought > you were referring to the commit message earlier...). > I put a gitlab patch up here: https://gitlab.kitware.com/vtk/vtk/merge_requests/161 I tried to add you (Dave) as a reviewer, but it looks like you do not have a gitlab account yet. Let me know if this is satisfactory. Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Apr 30 08:52:16 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 30 Apr 2015 08:52:16 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... In-Reply-To: References: <20150429194407.1570541337@mail.rogue-research.com> Message-ID: > > I'm still missing something here. One on of my attempts to get this to > compile simultaneously across all of our windows dashboards, this call was > failing: > > std::pair(someDouble, NULL); > > As I understand it, if NULL is defined as either (int)0, (void*)0, or > nullptr (depending on implementation/standard), all of those expressions are > implicitly convertible to X* without going through an intermediate, right? > To fix it, I had to explicitly cast the NULL to X* for compilation to > succeed. What am I missing here? Sorry I was unclear, I was mainly referring to the usage of make_pair with explicit template parameters. As far as I am aware MSVC 2010 has an issue with pair where it doesn't respect all the different null pointer conversion types ( int(), 0, nullptr, std::nullptr_t(), etc) but only would convert nullptr and std::nullptr_t. This issue of pointer conversion was fixed in MSVC 2012, but the rules about make_pair exist for all versions of MSVC from 2010 and forward. From david.gobbi at gmail.com Thu Apr 30 10:02:11 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 30 Apr 2015 08:02:11 -0600 Subject: [vtk-developers] vtkImageReslice with the problem of slice original In-Reply-To: <1430392832059-5731695.post@n5.nabble.com> References: <1430357911572-5731694.post@n5.nabble.com> <1430392832059-5731695.post@n5.nabble.com> Message-ID: On Thu, Apr 30, 2015 at 5:20 AM, Jason <2130220212 at email.szu.edu.cn> wrote: > I have read David Gobbi's tips in > > http://vtk.1045678.n5.nabble.com/vtkImageReslice-class-td1233015.html#a1233022 > > it use x = T*M*x' where "T" is ResliceTransform and "M" is > ResliceMatrix > to calculate the position in 3D volume(x) by the point position in 2D > slice(x') > > but I'm still wondering that the slice we need cut through and how to use > the ResliceTransform(vtkAbstractTransform) to calculate the point position > in 3D coordinate. > > Does just make the x'=(x0,y0,0,1) , M=ResliceAxes ? what about T ? I cannot > get its matirx. > Yes, M is ResliceAxes. And T is identity unless you call SetResliceTransform. The slice is defined with SetOutputOrigin(x0,y0,z0), SetOutputSpacing(dx,dy,dz), and SetOutputExtent(0,xn-1,0,yn-1,0,0) where: (x0,y0,z0) is the corner of the slice (in x' coords, not x coords, usually z0=0) dx, dy, dz is the voxel spacing (in x' coords, usually dz=dy=dx) xn * yn are the dimensions of the slice (number of columns and rows) So imagine a for loop over the rows and columns of the slice: for i = 0 to xn-1 for j = 0 to yn-1 x' = (x0 + i*dx, y0 + j*dy, z0, 1) x = T*M*x' The x values generated by this loop are the sample points for the slice. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Thu Apr 30 10:08:45 2015 From: DLRdave at aol.com (David Cole) Date: Thu, 30 Apr 2015 10:08:45 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... In-Reply-To: References: <20150429194407.1570541337@mail.rogue-research.com> Message-ID: On Thu, Apr 30, 2015 at 8:02 AM, David Lonie wrote: > To fix it, I had to explicitly cast the NULL to X* for compilation to > succeed. What am I missing here? That in some implementations NULL is defined simply as 0. Stupidly, but still a fact. If you do use Visual Studio, you can highlight some code in any source code file in your project and hit the F12 key to jump to where it's defined and see its definition (or right click and choose "Go To Definition"). Even in VS 2013, with __cplusplus defined, NULL is simply #define'd to 0. > I can see about making the comment I introduced more palatable (I thought > you were referring to the commit message earlier...). > Thanks, that and being more judicious on future commit messages is all I'm asking. > BTW, if my comments were enough of a turn-off to spark this thread, you may > want to grep the code for things like "stupid", "dumb", "moron", "idiot", > "s***" and "f***". Thanks ... ? Maybe I'll save that one for a Monday, when I have a full week ahead of me to dedicate to community service. I am (just recently) on Kitware's new gitlab server as dlrdave. I'll go on and take a look at your patch. Thank you, David C. From brad.king at kitware.com Thu Apr 30 10:17:34 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Apr 2015 10:17:34 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... In-Reply-To: References: <20150429194407.1570541337@mail.rogue-research.com> Message-ID: <5542397E.60309@kitware.com> On 04/30/2015 10:08 AM, David Cole via vtk-developers wrote: > That in some implementations NULL is defined simply as 0. Stupidly, > but still a fact. > > Even in VS 2013, with __cplusplus defined, NULL is simply #define'd to 0. IIRC the C++ standard *requires* that NULL be just "0". Its conversion problems are why C++11 introduced nullptr. -Brad From brad.king at kitware.com Thu Apr 30 10:26:19 2015 From: brad.king at kitware.com (Brad King) Date: Thu, 30 Apr 2015 10:26:19 -0400 Subject: [vtk-developers] C++ NULL definition (was: Request for a gentler tone in commit message verbiage...) In-Reply-To: References: <20150429194407.1570541337@mail.rogue-research.com> <5542397E.60309@kitware.com> Message-ID: <55423B8B.3020203@kitware.com> On 04/30/2015 10:20 AM, Robert Maynard wrote: > Actually the definition of NULL is left up to each compiler. The C++11 > draft states "The macro NULL < snip> is an implementation-defined C++ > null pointer constant" C++98 18.1/4 says it is implementation defined but has a footnote that does not leave much room: 180) Possible definitions include 0 and 0L, but not (void*)0. The reason plain C's "((void*)0)" does not work in C++ is because C++ is strict about pointer conversions where C is tolerant. -Brad From robert.maynard at kitware.com Thu Apr 30 10:20:26 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 30 Apr 2015 10:20:26 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... In-Reply-To: <5542397E.60309@kitware.com> References: <20150429194407.1570541337@mail.rogue-research.com> <5542397E.60309@kitware.com> Message-ID: Actually the definition of NULL is left up to each compiler. The C++11 draft states "The macro NULL < snip> is an implementation-defined C++ null pointer constant" On Thu, Apr 30, 2015 at 10:17 AM, Brad King wrote: > On 04/30/2015 10:08 AM, David Cole via vtk-developers wrote: >> That in some implementations NULL is defined simply as 0. Stupidly, >> but still a fact. >> >> Even in VS 2013, with __cplusplus defined, NULL is simply #define'd to 0. > > IIRC the C++ standard *requires* that NULL be just "0". > Its conversion problems are why C++11 introduced nullptr. > > -Brad > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the 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 bill.lorensen at gmail.com Thu Apr 30 10:29:45 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Thu, 30 Apr 2015 10:29:45 -0400 Subject: [vtk-developers] C++ NULL definition (was: Request for a gentler tone in commit message verbiage...) In-Reply-To: <55423B8B.3020203@kitware.com> References: <20150429194407.1570541337@mail.rogue-research.com> <5542397E.60309@kitware.com> <55423B8B.3020203@kitware.com> Message-ID: In ITK we define ITK_NULLPTR which is nullptr for c++11 and NULL for earlier c++'s. we use #if __cplusplus >= 201103L to detect c++11. All NULL's in ITK have been changed to ITK_NULLPTR. Here is the code snippet we use: #if __cplusplus >= 201103L // In c++11 the override keyword allows you to explicity define that a function // is intended to override the base-class version. This makes the code more // managable and fixes a set of common hard-to-find bugs. #define ITK_OVERRIDE override // In c++11 there is an explicit nullptr type that introduces a new keyword to // serve as a distinguished null pointer constant: nullptr. It is of type // nullptr_t, which is implicitly convertible and comparable to any pointer type // or pointer-to-member type. It is not implicitly convertible or comparable to // integral types, except for bool. #define ITK_NULLPTR nullptr // In C++11 the throw-list specification has been deprecated, // replaces with the noexcept specifier. Using this function // specification adds the run-time check that the method does not // throw, if it does throw then std::terminate will be called. // Use cautiously. #define ITK_NOEXCEPT noexcept #else #define ITK_OVERRIDE #define ITK_NULLPTR NULL #define ITK_NOEXCEPT throw() #endif On Thu, Apr 30, 2015 at 10:26 AM, Brad King wrote: > On 04/30/2015 10:20 AM, Robert Maynard wrote: >> Actually the definition of NULL is left up to each compiler. The C++11 >> draft states "The macro NULL < snip> is an implementation-defined C++ >> null pointer constant" > > C++98 18.1/4 says it is implementation defined but has a footnote > that does not leave much room: > > 180) Possible definitions include 0 and 0L, but not (void*)0. > > The reason plain C's "((void*)0)" does not work in C++ is because > C++ is strict about pointer conversions where C is tolerant. > > -Brad > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the 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 david.lonie at kitware.com Thu Apr 30 10:33:09 2015 From: david.lonie at kitware.com (David Lonie) Date: Thu, 30 Apr 2015 10:33:09 -0400 Subject: [vtk-developers] Request for a gentler tone in commit message verbiage... In-Reply-To: References: <20150429194407.1570541337@mail.rogue-research.com> <5542397E.60309@kitware.com> Message-ID: Also, as Robert pointed out earlier, there is an obscure, known issue concerning NULL conversion and pair constructors in MSVC 2010 that contributed to this debacle. It is my understanding that NULL (even defined as (int)0) should convert cleanly to a pointer type, so long as the pointer type is deducible from template arguments or other contextual information. In any case, the code is happily functioning on all of our support platforms now, and I've spent far, far too much time writing, rewriting, rewriting again, documenting, and redocumenting this single line of code for my taste. Hopefully the pending merge request will quell any outstanding concerns. Dave On Thu, Apr 30, 2015 at 10:20 AM, Robert Maynard wrote: > Actually the definition of NULL is left up to each compiler. The C++11 > draft states "The macro NULL < snip> is an implementation-defined C++ > null pointer constant" > > On Thu, Apr 30, 2015 at 10:17 AM, Brad King wrote: > > On 04/30/2015 10:08 AM, David Cole via vtk-developers wrote: > >> That in some implementations NULL is defined simply as 0. Stupidly, > >> but still a fact. > >> > >> Even in VS 2013, with __cplusplus defined, NULL is simply #define'd to > 0. > > > > IIRC the C++ standard *requires* that NULL be just "0". > > Its conversion problems are why C++11 introduced nullptr. > > > > -Brad > > > > _______________________________________________ > > Powered by www.kitware.com > > > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > > > Search the 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 arnaudgelas at gmail.com Thu Apr 30 10:47:46 2015 From: arnaudgelas at gmail.com (Arnaud Gelas) Date: Thu, 30 Apr 2015 16:47:46 +0200 Subject: [vtk-developers] QVTKInteractorAdapter and QWheelEvent Message-ID: Hi all, Please, correct me if I am mistaken! In one QVTKWidget, when user use the mouse wheel. For each QWheelEvent, there is one vtkMouseWheel * Event (forward/backward) [1]. The problem is that Qt is sending less QWheelEvent than expected by vtk. Indeed QWheelEvent::delta returns the distance that the wheel is rotated [2], and so less QWheelEvent are sent. So in applications, when changing image slices (with large data sets), it requires lots of mouse wheel to go from one side to the other one. Am I correct? If so, to your opinion what would be the best way to address this issue? Thanks! Best regards, Arnaud [1] https://github.com/Kitware/VTK/blob/master/GUISupport/Qt/QVTKInteractorAdapter.cxx#L258-L277 [2] http://doc.qt.io/qt-4.8/qwheelevent.html#delta -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.maynard at kitware.com Thu Apr 30 10:41:33 2015 From: robert.maynard at kitware.com (Robert Maynard) Date: Thu, 30 Apr 2015 10:41:33 -0400 Subject: [vtk-developers] C++ NULL definition (was: Request for a gentler tone in commit message verbiage...) In-Reply-To: <55423B8B.3020203@kitware.com> References: <20150429194407.1570541337@mail.rogue-research.com> <5542397E.60309@kitware.com> <55423B8B.3020203@kitware.com> Message-ID: The base of the confusion is that the definition of what NULL represents changed between C++98 and C++11. The original topic was discussing issues with MSVC 2010 and above which are C++11 compilers, and so in that regard we should be using the C++11 definition of NULL. While the standard list that 0 and 0L as possible implementations, it doesn't exclude things such as std::nullptr_t which are also valid. On Thu, Apr 30, 2015 at 10:26 AM, Brad King wrote: > On 04/30/2015 10:20 AM, Robert Maynard wrote: >> Actually the definition of NULL is left up to each compiler. The C++11 >> draft states "The macro NULL < snip> is an implementation-defined C++ >> null pointer constant" > > C++98 18.1/4 says it is implementation defined but has a footnote > that does not leave much room: > > 180) Possible definitions include 0 and 0L, but not (void*)0. > > The reason plain C's "((void*)0)" does not work in C++ is because > C++ is strict about pointer conversions where C is tolerant. > > -Brad > From 2130220212 at email.szu.edu.cn Thu Apr 30 14:19:13 2015 From: 2130220212 at email.szu.edu.cn (Jason) Date: Thu, 30 Apr 2015 11:19:13 -0700 (MST) Subject: [vtk-developers] vtkImageReslice with the problem of slice original In-Reply-To: References: <1430357911572-5731694.post@n5.nabble.com> <1430392832059-5731695.post@n5.nabble.com> Message-ID: <1430417953698-5731718.post@n5.nabble.com> Hi, David I cannot set the parameters like SetOutputOrigin, SetOutputSpacing,and SetOutputExtent for vtkImageReslice, as I get a slice image by the cosin value and one point's position.It will get a wrong slice if I set these paremeters for vtkImageReslice, and here is my code: static double axialElements[16] = { 1, 0, 0, 0, 0, 0.866025, -0.5, 0, 0, 0.5, 0.866025, 0, 0, 0, 0, 1 }; vtkSmartPointer resliceAxes = vtkSmartPointer::New(); resliceAxes->DeepCopy(axialElements); resliceAxes->SetElement(0, 3, 10); resliceAxes->SetElement(1, 3, 10); resliceAxes->SetElement(2, 3, 10); vtkSmartPointer reslice = vtkSmartPointer::New(); reslice->SetInput(connector->GetOutput()); reslice->SetOutputDimensionality(2); reslice->SetResliceAxes(resliceAxes); reslice->SetInterpolationModeToLinear(); reslice->AutoCropOutputOn(); vtkSmartPointer colorTable = vtkSmartPointer::New(); colorTable->SetRange(0, 1000); colorTable->SetValueRange(0.0, 1.0); colorTable->SetSaturationRange(0.0, 0.0); colorTable->SetRampToLinear(); colorTable->Build(); My purpose is to calculate the origin of image(2D) in 3D volume position,and I can only get the bounds of the slice image through vtkImageActor : vtkSmartPointer colorMap = vtkSmartPointer::New(); colorMap->SetLookupTable(colorTable); colorMap->SetInputConnection(reslice->GetOutputPort()); vtkSmartPointer imgActor = vtkSmartPointer::New(); imgActor->SetInput(colorMap->GetOutput()); double extent[6]={0}; imgActor->GetBounds(extent); Can I take point'(extent[0],extet[2]) as the original position of the slice image ? And calculate its corresponding position in 3D volume by point = M*point' ? I'm not so sure if this is right or not. Maybe there is a way to get the original position(2D) by vtkImageReslice itself. -- View this message in context: http://vtk.1045678.n5.nabble.com/vtkImageReslice-with-the-problem-of-slice-original-tp5731694p5731718.html Sent from the VTK - Dev mailing list archive at Nabble.com. From majcjc at gmail.com Thu Apr 30 20:13:15 2015 From: majcjc at gmail.com (Lin M) Date: Thu, 30 Apr 2015 20:13:15 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> Message-ID: Hi Dr. Thompson, Is there any dataset for precomputed Bezier interpolation? I'm currently comparing the result with my manual calculating. In this way I can not test many examples and it's quite low efficient. Best, Lin On Mon, Apr 27, 2015 at 1:46 PM, David Thompson wrote: > Hi Lin, > > > ... I changed the method to compute binomial coefficient from > vtkMath::Binomial to vtkMath::Factorial using our memoization improvement > and tried to merge from Lin.Ma/filter-bezier to Spline/filter-bezier. > > Great! I can see that you were able to merge to the branch. > > > What do you think is the proper thing to do next? > > Right now, it looks like TestPatchInterpolation is modifying the array > holding control point coordinates. I think it would be a good idea to write > the interpolated points to a separate array and then make the test verify > that Bernstein polynomial is being computed properly. > > There are 2 ways to verify things: value tests and image tests. > > 1. Value testing. Interpolate a few different r values on a few different > sets of control points and compare the resulting point coordinates to > values you know are good. The comparison must allow for small differences > due to the differences in floating-point arithmetic implementations on > different platforms. > > 2. Image testing. Plot the interpolated points and compare the rendering > of the interpolated points to one you have verified is correct. While not > as accurate as value testing, it can often be easier to debug a failing > test with a rendered image. VTK provides utilities for comparing images > (also allowing for small differences due to floating-point math, OpenGL > implementations, and so on). The image baselines that get compared to your > test's rendering are stored outside of the git repository to keep the > repository from getting bloated. Instead, the MD5 sum of the baseline > images are stored in the git repository and the images are stored > separately on Kitware's servers, which can be queried to find a file with a > given MD5 sum. > > Please take a look at this documentation on adding test data and baseline > images to VTK: > > > https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/data.md > > and see if you can add an image-based test of the patch interpolation. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Thu Apr 30 22:09:01 2015 From: cory.quammen at kitware.com (Cory Quammen) Date: Thu, 30 Apr 2015 22:09:01 -0400 Subject: [vtk-developers] Bug fix for boolean operations filter Message-ID: Hi all, Today I committed a bug fix to vtkImplicitPolyDataDistance that should fix at least some of the known problems with vtkBooleanOperationPolyDataFilter. commit 67122e8421c833769fff90c8a0a113007e0383cf Author: Cory Quammen Date: Wed Apr 29 23:02:34 2015 -0400 BUG: Fixed error in area-weighted normal When the closest point on a surface to a test point is on an edge, the area-weighted normal is the average of the normals of the faces adjacent to the edge. The contribution from one of the faces was being added twice, producing the incorrect area-weighted normal. This resulted in the wrong sign for the signed distance in some cases. This patch fixes the error. Changed TestImplicitPolyDataDistance.cxx to fail prior to this change and pass after the change. The previous test exercised vtkImplicityPolyDataDistance but did not check the results. The new test checks against a baseline. For anyone who has tried to use the boolean operations filter but found it to be buggy, especially where it added extraneous triangles to the output, I encourage you to check out the current VTK master branch and see if this fixes your problem. If not, please let me know. There is still a known problem for input geometries that have long skinny triangles [1], but I think today's bug fix should take care of many of the problems people have reported. Thanks, Cory [1] http://www.paraview.org/Bug/view.php?id=13708 -- Cory Quammen R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: