From brad.king at kitware.com Mon Jun 1 08:35:31 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Jun 2015 08:35:31 -0400 Subject: [vtk-developers] Minor syntax error in vtk_common.cmake? In-Reply-To: <20150529210608.24644284@mail.rogue-research.com> References: <20150529210608.24644284@mail.rogue-research.com> Message-ID: <556C5193.5040107@kitware.com> On 05/29/2015 05:06 PM, Sean McBride wrote: > Syntax Warning in cmake code at > /Users/builder/external/_scripts/vtk_common.cmake:426:21 > Argument not separated from preceding token by whitespace. > > Syntax Warning in cmake code at > /Users/builder/external/_scripts/vtk_common.cmake:431:21 > Argument not separated from preceding token by whitespace. Fixed here: vtk_common: Add missing space to fix CMake syntax warning https://gitlab.kitware.com/vtk/vtk/commit/8b4bd0bf See commit message for details. Thanks, -Brad From sean at rogue-research.com Mon Jun 1 09:55:16 2015 From: sean at rogue-research.com (Sean McBride) Date: Mon, 1 Jun 2015 09:55:16 -0400 Subject: [vtk-developers] Minor syntax error in vtk_common.cmake? In-Reply-To: <556C5193.5040107@kitware.com> References: <20150529210608.24644284@mail.rogue-research.com> <556C5193.5040107@kitware.com> Message-ID: <20150601135516.1250304968@mail.rogue-research.com> On Mon, 1 Jun 2015 08:35:31 -0400, Brad King said: >On 05/29/2015 05:06 PM, Sean McBride wrote: >> Syntax Warning in cmake code at >> /Users/builder/external/_scripts/vtk_common.cmake:426:21 >> Argument not separated from preceding token by whitespace. >> >> Syntax Warning in cmake code at >> /Users/builder/external/_scripts/vtk_common.cmake:431:21 >> Argument not separated from preceding token by whitespace. > >Fixed here: > > vtk_common: Add missing space to fix CMake syntax warning > https://gitlab.kitware.com/vtk/vtk/commit/8b4bd0bf > >See commit message for details. Thanks! How did none of us notice this since CMake 3.0? :( Is there a further bug that this didn't appear on the dashboards? 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 brad.king at kitware.com Mon Jun 1 10:17:28 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Jun 2015 10:17:28 -0400 Subject: [vtk-developers] Minor syntax error in vtk_common.cmake? In-Reply-To: <20150601135516.1250304968@mail.rogue-research.com> References: <20150529210608.24644284@mail.rogue-research.com> <556C5193.5040107@kitware.com> <20150601135516.1250304968@mail.rogue-research.com> Message-ID: <556C6978.3040503@kitware.com> On 06/01/2015 09:55 AM, Sean McBride wrote: > Is there a further bug that this didn't appear on the dashboards? The message is in the local dashboard script output on each client. The only way for it to appear on the dashboard would be to have something capture and submit it, but then that would be another dashboard layer that would not have messages reported. As long as the info we need appears on the dashboard I do not think we need to spend more time on this. Thanks, -Brad From lonni.besancon at gmail.com Mon Jun 1 11:36:35 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Mon, 1 Jun 2015 08:36:35 -0700 (MST) Subject: [vtk-developers] VTK, CMake error with android build In-Reply-To: <1432885655008-5732053.post@n5.nabble.com> References: <1432823354028-5732043.post@n5.nabble.com> <1432823412633-5732044.post@n5.nabble.com> <1432885558912-5732052.post@n5.nabble.com> <1432885655008-5732053.post@n5.nabble.com> Message-ID: <1433172995158-5732086.post@n5.nabble.com> Does anyone have some inputs on this? -- View this message in context: http://vtk.1045678.n5.nabble.com/VTK-CMake-error-with-android-build-tp5732043p5732086.html Sent from the VTK - Dev mailing list archive at Nabble.com. From brad.king at kitware.com Mon Jun 1 14:09:20 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Jun 2015 14:09:20 -0400 Subject: [vtk-developers] gitlab.kitware.com maintenance at 4pm EDT 2015-06-01 Message-ID: <556C9FD0.6040707@kitware.com> Hi Folks, We will be shutting down gitlab.kitware.com for a little while at 4pm EDT in order to upgrade the GitLab version. I will post again when normal service is restored. -Brad From dan.lipsa at kitware.com Mon Jun 1 15:18:40 2015 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Mon, 1 Jun 2015 15:18:40 -0400 Subject: [vtk-developers] clean-up VTK_LEGACY code Message-ID: Hello VTK Developers, I am removing code marked as deprecated for VTK versions 6.1 (this was released on 2014-01-21) and earlier. This means that any code marked as deprecated after that date is still in, so people will still have plenty of time to change their code. VTK 6.2 was released 2015-03-02 which I though would be to short of a notice for removing code marked as legacy. Do you have any comments or concerns related to this. Thank you, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Mon Jun 1 15:26:19 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 1 Jun 2015 15:26:19 -0400 Subject: [vtk-developers] clean-up VTK_LEGACY code In-Reply-To: References: Message-ID: On Mon, Jun 1, 2015 at 3:18 PM, Dan Lipsa wrote: > VTK 6.2 was released 2015-03-02 which I though would be to short of a > notice for removing code marked as legacy. Sounds fine to me. Removing code that has been deprecated for at least one release is the stated deprecation policy after all. See http://www.vtk.org/wp-content/uploads/2015/01/TheVTKSoftwareProcess.pdf David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Jun 1 15:58:31 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 1 Jun 2015 15:58:31 -0400 Subject: [vtk-developers] clean-up VTK_LEGACY code In-Reply-To: References: Message-ID: Can you provide a list of the code to be removed? Perhaps a notice to the users and developers lists on how to test for the removed code? On Mon, Jun 1, 2015 at 3:26 PM, David E DeMarle wrote: > > On Mon, Jun 1, 2015 at 3:18 PM, Dan Lipsa wrote: >> >> VTK 6.2 was released 2015-03-02 which I though would be to short of a >> notice for removing code marked as legacy. > > > Sounds fine to me. > > Removing code that has been deprecated for at least one release is the > stated deprecation policy after all. See > http://www.vtk.org/wp-content/uploads/2015/01/TheVTKSoftwareProcess.pdf > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 Jun 1 16:05:37 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 01 Jun 2015 20:05:37 +0000 Subject: [vtk-developers] [Paraview-developers] gitlab.kitware.com maintenance at 4pm EDT 2015-06-01 In-Reply-To: <556C9FD0.6040707@kitware.com> References: <556C9FD0.6040707@kitware.com> Message-ID: Since Gitlab is down for maintenance, I've stopped the buildbot server as well to avoid failed dashboard builds. I'll restart the buildbot server once Gitlab server comes online. Utkarsh On Mon, Jun 1, 2015 at 2:09 PM Brad King wrote: > Hi Folks, > > We will be shutting down gitlab.kitware.com for a little while at > 4pm EDT in order to upgrade the GitLab version. I will post again > when normal service is restored. > > -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=Paraview-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/paraview-developers > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brad.king at kitware.com Mon Jun 1 16:21:14 2015 From: brad.king at kitware.com (Brad King) Date: Mon, 01 Jun 2015 16:21:14 -0400 Subject: [vtk-developers] gitlab.kitware.com maintenance at 4pm EDT 2015-06-01 In-Reply-To: <556C9FD0.6040707@kitware.com> References: <556C9FD0.6040707@kitware.com> Message-ID: <556CBEBA.3090909@kitware.com> On 06/01/2015 02:09 PM, Brad King wrote: > We will be shutting down gitlab.kitware.com for a little while at > 4pm EDT in order to upgrade the GitLab version. I will post again > when normal service is restored. Done. -Brad From m.sejna at pc-progress.com Mon Jun 1 16:34:03 2015 From: m.sejna at pc-progress.com (Mirek) Date: Mon, 1 Jun 2015 13:34:03 -0700 (MST) Subject: [vtk-developers] Optimization of vtkClipDataSet and vtkProbeFilter for large data? Message-ID: <1433190843126-5732100.post@n5.nabble.com> Dear VTK developers, Filters like vtkClipDataSet and vtkProbeFilter, interpolating values of vtkDataSetAttributes, work perfectly for relatively small data, i.e. if the clipping is fast and you can have all vtkDataSetAttributes in memory. However, it looks like there is no option to optimize these filters for large data. In my case (see details (*) below), data of each quantity is loaded "on demand" from the disk. The problem is that vtkClipDataSet cannot interpolate new vtkDataSetAttributes into the existing (clipped) unstructured grid without recalculating everything, which is unnecessary and slow. In my old program, all "interpolated points" had information how to recalculate values of a new quantity (now vtkPointData scalars), which actually is a simple and fast operation. In case of a tetrahedral mesh, you just need to have IDs of 4 original mesh nodes and their weights for the linear interpolation. I have spent several days by debugging VTK and looking for a standard solution. Unfortunately, I have not found any way how to get and save the interpolation factors so that I could reuse them. The interpolation of vtkDataSetAttributes is implemented in vtkTetra::Clip and most of important functions (vtkTetra::Clip, vtkDataSetAttributes::InterpolateEdge, ...) are not virtual => it will not be easy to modify the filter. Before investing time into the development of a new filter, I'd like to ask: Did I miss something? Is there an existing solution for this problem? Thank you Mirek (*) In my case the data can be really large: unstructured FE-meshes with up to 50 mil. nodes and time-varying results (10-200 different quantities defined by values at mesh nodes, while there can be 100 - 10000 time layers). -- View this message in context: http://vtk.1045678.n5.nabble.com/Optimization-of-vtkClipDataSet-and-vtkProbeFilter-for-large-data-tp5732100.html Sent from the VTK - Dev mailing list archive at Nabble.com. From utkarsh.ayachit at kitware.com Mon Jun 1 16:36:54 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 01 Jun 2015 20:36:54 +0000 Subject: [vtk-developers] [Paraview-developers] gitlab.kitware.com maintenance at 4pm EDT 2015-06-01 In-Reply-To: References: <556C9FD0.6040707@kitware.com> Message-ID: > > I'll restart the buildbot server once Gitlab server comes online. > Buildbot server has been restarted as well. Utkarsh -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Mon Jun 1 16:45:38 2015 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Mon, 1 Jun 2015 16:45:38 -0400 Subject: [vtk-developers] clean-up VTK_LEGACY code In-Reply-To: References: Message-ID: On Mon, Jun 1, 2015 at 3:58 PM, Bill Lorensen wrote: > Can you provide a list of the code to be removed? Here is the merge request. https://gitlab.kitware.com/vtk/vtk/merge_requests/235 > Perhaps a notice to > the users and developers lists on how to test for the removed code? > Users who update VTK regularly are warned using the VTK_LEGACY_REPLACED_BODY mechanism if they call a deprecated function. If they want, users can define VTK_LEGACY_REMOVE to remove all deprecated code from VTK. Some code is only removed if VTK_LEGACY_REMOVE is defined, so it may be harder to know if one uses it. So, the best way to test for deprecated code seems to be to define VTK_LEGACY_REMOVE. Users moving from old versions of VTK where the code was not deprecated to a new version where the code has been removed will get a compiler error for functions that have changed name or have been removed. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Mon Jun 1 16:53:42 2015 From: sean at rogue-research.com (Sean McBride) Date: Mon, 1 Jun 2015 16:53:42 -0400 Subject: [vtk-developers] clean-up VTK_LEGACY code In-Reply-To: References: Message-ID: <20150601205342.796128989@mail.rogue-research.com> On Mon, 1 Jun 2015 16:45:38 -0400, Dan Lipsa said: >Here is the merge request. > >https://gitlab.kitware.com/vtk/vtk/merge_requests/235 This is great. Some of that stuff is long overdue for getting removed. 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 utkarsh.ayachit at kitware.com Mon Jun 1 17:05:27 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Mon, 01 Jun 2015 21:05:27 +0000 Subject: [vtk-developers] clean-up VTK_LEGACY code In-Reply-To: References: Message-ID: > > So, the best way to test for deprecated code seems to be to > define VTK_LEGACY_REMOVE. > Note that VTK_LEGACY_REMOVE is a CMake option that can be turned on when building VTK. Utkarsh -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Jun 1 17:43:07 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 1 Jun 2015 17:43:07 -0400 Subject: [vtk-developers] clean-up VTK_LEGACY code In-Reply-To: References: Message-ID: We should announce to both lists to turn on this flag. Do not assume that our customers are not using this code. On Jun 1, 2015 5:05 PM, "Utkarsh Ayachit" wrote: > So, the best way to test for deprecated code seems to be to >> define VTK_LEGACY_REMOVE. >> > > Note that VTK_LEGACY_REMOVE is a CMake option that can be turned on when > building VTK. > > Utkarsh > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Tue Jun 2 09:35:32 2015 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 2 Jun 2015 09:35:32 -0400 Subject: [vtk-developers] merging Message-ID: <6d72d6d031aead90a34ab44eb2c4fa68@mail.gmail.com> I think something may be off with merging in gitlab since the upgrade (or I lack the required patience). See https://gitlab.kitware.com/vtk/vtk/merge_requests/265 I even tried ... Do: merge_this_one_for_me_bro_really and that did not work and that always works ;-) 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 mathieu.westphal at kitware.com Tue Jun 2 09:44:23 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Tue, 2 Jun 2015 15:44:23 +0200 Subject: [vtk-developers] merging In-Reply-To: <6d72d6d031aead90a34ab44eb2c4fa68@mail.gmail.com> References: <6d72d6d031aead90a34ab44eb2c4fa68@mail.gmail.com> Message-ID: Same problem here: https://gitlab.kitware.com/vtk/vtk/merge_requests/263 Mathieu Westphal On Tue, Jun 2, 2015 at 3:35 PM, Ken Martin wrote: > I think something may be off with merging in gitlab since the upgrade (or > I lack the required patience). See > > > > https://gitlab.kitware.com/vtk/vtk/merge_requests/265 > > > > I even tried ... > > > > Do: merge_this_one_for_me_bro_really > > > > and that did not work and that always works ;-) > > > > 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 will.schroeder at kitware.com Tue Jun 2 09:59:05 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Tue, 2 Jun 2015 09:59:05 -0400 Subject: [vtk-developers] Optimization of vtkClipDataSet and vtkProbeFilter for large data? In-Reply-To: <1433190843126-5732100.post@n5.nabble.com> References: <1433190843126-5732100.post@n5.nabble.com> Message-ID: If I understand you correctly, it seems that your solution is to save in memory the interpolation factors so that you can rapidly clip new attribute data. Here's a probably crazy alternative suggestion that may have merit in the long run. You could take advantage of (emerging) parallel hardware and recalculate the interpolation factors anyway; i.e., do extra work but with lots of processors it may be simpler and faster. There are currently several folks working on these sorts of algorithms (including clipping) but the results will not be available until later this year. If you can afford to be patient, or want to to try your hand at writing some parallel algorithms, I'm sure we can point you in the right direction. W On Mon, Jun 1, 2015 at 4:34 PM, Mirek wrote: > Dear VTK developers, > > Filters like vtkClipDataSet and vtkProbeFilter, interpolating values of > vtkDataSetAttributes, work perfectly for relatively small data, i.e. if the > clipping is fast and you can have all vtkDataSetAttributes in memory. > However, it looks like there is no option to optimize these filters for > large data. In my case (see details (*) below), data of each quantity is > loaded "on demand" from the disk. The problem is that vtkClipDataSet cannot > interpolate new vtkDataSetAttributes into the existing (clipped) > unstructured grid without recalculating everything, which is unnecessary > and > slow. In my old program, all "interpolated points" had information how to > recalculate values of a new quantity (now vtkPointData scalars), which > actually is a simple and fast operation. In case of a tetrahedral mesh, you > just need to have IDs of 4 original mesh nodes and their weights for the > linear interpolation. > > I have spent several days by debugging VTK and looking for a standard > solution. Unfortunately, I have not found any way how to get and save the > interpolation factors so that I could reuse them. The interpolation of > vtkDataSetAttributes is implemented in vtkTetra::Clip and most of important > functions (vtkTetra::Clip, vtkDataSetAttributes::InterpolateEdge, ...) are > not virtual => it will not be easy to modify the filter. Before investing > time into the development of a new filter, I'd like to ask: Did I miss > something? Is there an existing solution for this problem? > > Thank you > Mirek > > (*) In my case the data can be really large: unstructured FE-meshes with up > to 50 mil. nodes and time-varying results (10-200 different quantities > defined by values at mesh nodes, while there can be 100 - 10000 time > layers). > > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Optimization-of-vtkClipDataSet-and-vtkProbeFilter-for-large-data-tp5732100.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- 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 utkarsh.ayachit at kitware.com Tue Jun 2 10:12:58 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 02 Jun 2015 14:12:58 +0000 Subject: [vtk-developers] merging In-Reply-To: References: <6d72d6d031aead90a34ab44eb2c4fa68@mail.gmail.com> Message-ID: The good sysadmins are on it. We'll hear back soon. The issue started after upgrading Gitlab. Utkarsh On Tue, Jun 2, 2015 at 9:44 AM Mathieu Westphal < mathieu.westphal at kitware.com> wrote: > Same problem here: > https://gitlab.kitware.com/vtk/vtk/merge_requests/263 > > Mathieu Westphal > > On Tue, Jun 2, 2015 at 3:35 PM, Ken Martin wrote: > >> I think something may be off with merging in gitlab since the upgrade (or >> I lack the required patience). See >> >> >> >> https://gitlab.kitware.com/vtk/vtk/merge_requests/265 >> >> >> >> I even tried ... >> >> >> >> Do: merge_this_one_for_me_bro_really >> >> >> >> and that did not work and that always works ;-) >> >> >> >> 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 >> >> >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 shawn.waldon at kitware.com Tue Jun 2 10:42:29 2015 From: shawn.waldon at kitware.com (Shawn Waldon) Date: Tue, 2 Jun 2015 10:42:29 -0400 Subject: [vtk-developers] merging In-Reply-To: References: <6d72d6d031aead90a34ab44eb2c4fa68@mail.gmail.com> Message-ID: The buildbot master runs on the same machine and so it will also be offline until the problem is solved. --Shawn On Tue, Jun 2, 2015 at 10:12 AM, Utkarsh Ayachit < utkarsh.ayachit at kitware.com> wrote: > The good sysadmins are on it. We'll hear back soon. The issue started > after upgrading Gitlab. > > Utkarsh > > On Tue, Jun 2, 2015 at 9:44 AM Mathieu Westphal < > mathieu.westphal at kitware.com> wrote: > >> Same problem here: >> https://gitlab.kitware.com/vtk/vtk/merge_requests/263 >> >> Mathieu Westphal >> >> On Tue, Jun 2, 2015 at 3:35 PM, Ken Martin >> wrote: >> >>> I think something may be off with merging in gitlab since the upgrade >>> (or I lack the required patience). See >>> >>> >>> >>> https://gitlab.kitware.com/vtk/vtk/merge_requests/265 >>> >>> >>> >>> I even tried ... >>> >>> >>> >>> Do: merge_this_one_for_me_bro_really >>> >>> >>> >>> and that did not work and that always works ;-) >>> >>> >>> >>> 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 >>> >>> >>> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Tue Jun 2 11:15:50 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 02 Jun 2015 15:15:50 +0000 Subject: [vtk-developers] Merging changes in temporarily offline Message-ID: Folks, As many of you may know, we upgraded our GitLab installation yesterday. As with many things one doesn't expect to have any issues, we have had some issues :). While we figure things out, merging branches will be temporarily offline. Things should be back online by tomorrow. The following things will be affected: + Do:check, Do: merge will not work. + Pushing new baselines or data files (using the gitlab-push) will not work. For now, if you are intending to push a branch/commit that changes baselines or data files, it may be better to just hold on to it and push it after things are working again. Folks should still be able to do manual reviews and solicit feedback from your peers. Also, Buildbot will be online, so you can request tests on your merge requests (as long as no new baselines/data files are being added). Thanks for your patience. Utkarsh -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Tue Jun 2 15:46:49 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 2 Jun 2015 15:46:49 -0400 Subject: [vtk-developers] Call For Papers: LDAV 2015, The 5th IEEE Symposium on Large Data Analysis and Visualization Message-ID: Subject: Call For Papers: LDAV 2015, The 5th IEEE Symposium on Large Data Analysis and Visualization LDAV 2015 The 5th IEEE Symposium on Large Data Analysis and Visualization, co-located with IEEE VIS 2015, October 25-26, 2015, Chicago, Illinois, USA http://www.ldav.org/ Contact: papers at ldav.org Modern large-scale scientific simulations, sensor networks, and experiments are generating enormous datasets, with some projects approaching the multiple exabyte range in the near term. Managing and analyzing large data in order to transform it into insight is critical for a variety of disciplines including climate science, nuclear physics, security, materials design, transportation, and urban planning. This is currently referred to as the Big Data Challenge. The tools and approaches needed to mine, analyze, and visualize data at extreme scales can be fully realized only if we have end-to-end solutions, which demands collective, interdisciplinary efforts. The 5th IEEE Large Scale Data Analysis and Visualization (LDAV) symposium, to be held in conjunction with IEEE VIS 2015, is specifically targeting possible end-to-end solutions. The LDAV symposium will bring together domain scientists, data analysts, visualization researchers, users, designers and artists, to foster common ground for solving both near- and long-term problems. Scope: We are looking for original research contributions on a broad-range of topics related to collection, analysis, manipulation or visualization of large-scale data. We also welcome position papers on these topics. Topics of interest include, but are not limited to: * Data collection, management and curation * Innovative approaches combining information visualization, visual analytics, and scientific visualization * Streaming methods for analysis, collection and visualization * Novel, extreme or innovative methods for understanding and interacting with data * Advanced hardware for data handling or visualization * Distributed, parallel or multi-threaded approaches * MapReduce-based and database-related methods, algorithms or approaches * Hierarchical data storage, retrieval or rendering * Collaboration or co-design of data analysis with domain scientists * Topics in cognitive issues specific to manipulating and understanding large data * Application case studies * Industry solutions for big data * End-to-end system solutions Submission Instructions: Submitted manuscripts may not exceed 8 pages. The manuscripts can be 4-8 pages, with the authors determining length based on the content. The manuscripts should be formatted according to guidelines from IEEE VGTC. Submission site note: Go to the submission site ( https://precisionconference.com/~vgtc), log in, go to 'new submissions', and select 'LDAV 2015 Papers'. Proceedings: The proceedings of the symposium will be published together with the VIS proceedings and via the IEEE Xplore Digital Library. Best Paper: The LDAV Program Committee will present a Best Paper award to the authors whose submission is deemed the strongest according to the reviewing criteria. This award will be announced in conjunction with VIS 2015. Important Dates: (Please note the abstract and paper deadlines are firm and no extensions will be granted). Abstract Deadline (firm): June 17, 2015 Paper Submission (firm): June 24, 2015 11:59 PM (AOE) Author Notification: August 13, 2015 Camera-Ready Deadline: August 21, 2015 -------------- next part -------------- An HTML attachment was scrubbed... URL: From zhangliyuan at cust.edu.cn Wed Jun 3 02:32:25 2015 From: zhangliyuan at cust.edu.cn (zhangliyuan at cust.edu.cn) Date: Wed, 3 Jun 2015 14:32:25 +0800 (GMT+08:00) Subject: [vtk-developers] How to make multiple masks (label is more than three)? Message-ID: <48b6c01d.12a9.14db81ef48e.Coremail.zhangliyuan@cust.edu.cn> Dear VTK developers, I want to consult about SetMaskTypeToLabelMap(). void vtkGPUVolumeRayCastMapper::SetMaskTypeToLabelMap() This type of mask is allowed to contain only 3 labels(values of 0,1 and 2) in your documentation. However, I'd like to ask: How to make multiple masks (label is more than three)? Is there an existing solution for this problem? Looking forward to your reply! -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.sejna at pc-progress.com Wed Jun 3 03:46:23 2015 From: m.sejna at pc-progress.com (Dr. Miroslav Sejna) Date: Wed, 3 Jun 2015 07:46:23 +0000 Subject: [vtk-developers] Optimization of vtkClipDataSet and vtkProbeFilter for large data? In-Reply-To: References: <1433190843126-5732100.post@n5.nabble.com> Message-ID: <753ef07b36e840668e424571a1050546@PCP-EXH1.pc-progress.com> Thank you, Will. I'll definitely be interested in parallelization of my code, which will be done in a next step. Yesterday I fortunately found a simple solution for my problem. It is based on a custom additional array in PointData and overriding its virtual method "InterpolateTuple". This is the place where I can get all interpolation factors and save them for later re-use. The rest was just a routine programming. Now I'm able to display scalars and vectors (defined at nodes of the original FE-mesh) on modified VTK meshes (clipping/slicing/...) without recalculating these filters. It works exactly as I wanted. VTK is a great library - thanks again. Mirek From: Will Schroeder [mailto:will.schroeder at kitware.com] Sent: Tuesday, June 02, 2015 3:59 PM To: Dr. Miroslav Sejna Cc: vtk-developers Subject: Re: [vtk-developers] Optimization of vtkClipDataSet and vtkProbeFilter for large data? If I understand you correctly, it seems that your solution is to save in memory the interpolation factors so that you can rapidly clip new attribute data. Here's a probably crazy alternative suggestion that may have merit in the long run. You could take advantage of (emerging) parallel hardware and recalculate the interpolation factors anyway; i.e., do extra work but with lots of processors it may be simpler and faster. There are currently several folks working on these sorts of algorithms (including clipping) but the results will not be available until later this year. If you can afford to be patient, or want to to try your hand at writing some parallel algorithms, I'm sure we can point you in the right direction. W On Mon, Jun 1, 2015 at 4:34 PM, Mirek > wrote: Dear VTK developers, Filters like vtkClipDataSet and vtkProbeFilter, interpolating values of vtkDataSetAttributes, work perfectly for relatively small data, i.e. if the clipping is fast and you can have all vtkDataSetAttributes in memory. However, it looks like there is no option to optimize these filters for large data. In my case (see details (*) below), data of each quantity is loaded "on demand" from the disk. The problem is that vtkClipDataSet cannot interpolate new vtkDataSetAttributes into the existing (clipped) unstructured grid without recalculating everything, which is unnecessary and slow. In my old program, all "interpolated points" had information how to recalculate values of a new quantity (now vtkPointData scalars), which actually is a simple and fast operation. In case of a tetrahedral mesh, you just need to have IDs of 4 original mesh nodes and their weights for the linear interpolation. I have spent several days by debugging VTK and looking for a standard solution. Unfortunately, I have not found any way how to get and save the interpolation factors so that I could reuse them. The interpolation of vtkDataSetAttributes is implemented in vtkTetra::Clip and most of important functions (vtkTetra::Clip, vtkDataSetAttributes::InterpolateEdge, ...) are not virtual => it will not be easy to modify the filter. Before investing time into the development of a new filter, I'd like to ask: Did I miss something? Is there an existing solution for this problem? Thank you Mirek (*) In my case the data can be really large: unstructured FE-meshes with up to 50 mil. nodes and time-varying results (10-200 different quantities defined by values at mesh nodes, while there can be 100 - 10000 time layers). -- View this message in context: http://vtk.1045678.n5.nabble.com/Optimization-of-vtkClipDataSet-and-vtkProbeFilter-for-large-data-tp5732100.html Sent from the VTK - Dev mailing list archive at Nabble.com. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -- 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 biddisco at cscs.ch Wed Jun 3 04:43:25 2015 From: biddisco at cscs.ch (Biddiscombe, John A.) Date: Wed, 3 Jun 2015 08:43:25 +0000 Subject: [vtk-developers] Optimization of vtkClipDataSet and vtkProbeFilter for large data? In-Reply-To: <753ef07b36e840668e424571a1050546@PCP-EXH1.pc-progress.com> References: <1433190843126-5732100.post@n5.nabble.com> <753ef07b36e840668e424571a1050546@PCP-EXH1.pc-progress.com> Message-ID: <50320452A334BD42A5EC72BAD21450992A7ED93A@MBX110.d.ethz.ch> Mirek I?m not sure I followed your explanation, but in case you?re doing more work than you need to... It is possible to compute interpolation weights and reuse them here I have computed weights for an interpolation (in the weights array) https://github.com/biddisco/pv-meshless/blob/master/vtkSPHProbeFilter.cxx#L944 and then pass them to the attribute arrays for computing the new values for each field at the point Id. (I use this on very large datasets, no problem) JB From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Dr. Miroslav Sejna Sent: 03 June 2015 09:46 To: Will Schroeder Cc: vtk-developers Subject: Re: [vtk-developers] Optimization of vtkClipDataSet and vtkProbeFilter for large data? Thank you, Will. I'll definitely be interested in parallelization of my code, which will be done in a next step. Yesterday I fortunately found a simple solution for my problem. It is based on a custom additional array in PointData and overriding its virtual method "InterpolateTuple". This is the place where I can get all interpolation factors and save them for later re-use. The rest was just a routine programming. Now I'm able to display scalars and vectors (defined at nodes of the original FE-mesh) on modified VTK meshes (clipping/slicing/...) without recalculating these filters. It works exactly as I wanted. VTK is a great library - thanks again. Mirek From: Will Schroeder [mailto:will.schroeder at kitware.com] Sent: Tuesday, June 02, 2015 3:59 PM To: Dr. Miroslav Sejna Cc: vtk-developers Subject: Re: [vtk-developers] Optimization of vtkClipDataSet and vtkProbeFilter for large data? If I understand you correctly, it seems that your solution is to save in memory the interpolation factors so that you can rapidly clip new attribute data. Here's a probably crazy alternative suggestion that may have merit in the long run. You could take advantage of (emerging) parallel hardware and recalculate the interpolation factors anyway; i.e., do extra work but with lots of processors it may be simpler and faster. There are currently several folks working on these sorts of algorithms (including clipping) but the results will not be available until later this year. If you can afford to be patient, or want to to try your hand at writing some parallel algorithms, I'm sure we can point you in the right direction. W On Mon, Jun 1, 2015 at 4:34 PM, Mirek > wrote: Dear VTK developers, Filters like vtkClipDataSet and vtkProbeFilter, interpolating values of vtkDataSetAttributes, work perfectly for relatively small data, i.e. if the clipping is fast and you can have all vtkDataSetAttributes in memory. However, it looks like there is no option to optimize these filters for large data. In my case (see details (*) below), data of each quantity is loaded "on demand" from the disk. The problem is that vtkClipDataSet cannot interpolate new vtkDataSetAttributes into the existing (clipped) unstructured grid without recalculating everything, which is unnecessary and slow. In my old program, all "interpolated points" had information how to recalculate values of a new quantity (now vtkPointData scalars), which actually is a simple and fast operation. In case of a tetrahedral mesh, you just need to have IDs of 4 original mesh nodes and their weights for the linear interpolation. I have spent several days by debugging VTK and looking for a standard solution. Unfortunately, I have not found any way how to get and save the interpolation factors so that I could reuse them. The interpolation of vtkDataSetAttributes is implemented in vtkTetra::Clip and most of important functions (vtkTetra::Clip, vtkDataSetAttributes::InterpolateEdge, ...) are not virtual => it will not be easy to modify the filter. Before investing time into the development of a new filter, I'd like to ask: Did I miss something? Is there an existing solution for this problem? Thank you Mirek (*) In my case the data can be really large: unstructured FE-meshes with up to 50 mil. nodes and time-varying results (10-200 different quantities defined by values at mesh nodes, while there can be 100 - 10000 time layers). -- View this message in context: http://vtk.1045678.n5.nabble.com/Optimization-of-vtkClipDataSet-and-vtkProbeFilter-for-large-data-tp5732100.html Sent from the VTK - Dev mailing list archive at Nabble.com. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Wed Jun 3 05:35:47 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Wed, 3 Jun 2015 05:35:47 -0400 Subject: [vtk-developers] Optimization of vtkClipDataSet and vtkProbeFilter for large data? In-Reply-To: <753ef07b36e840668e424571a1050546@PCP-EXH1.pc-progress.com> References: <1433190843126-5732100.post@n5.nabble.com> <753ef07b36e840668e424571a1050546@PCP-EXH1.pc-progress.com> Message-ID: Great. Watch this space regarding parallel computing. There is a ton of work going on (vtkSMPTools:threading; VTK-m:GPU & co-processors; and new algorithms using both). W On Wed, Jun 3, 2015 at 3:46 AM, Dr. Miroslav Sejna wrote: > Thank you, Will. I'll definitely be interested in parallelization of my > code, which will be done in a next step. > > > > Yesterday I fortunately found a simple solution for my problem. It is > based on a custom additional array in PointData and overriding its virtual > method "InterpolateTuple". This is the place where I can get all > interpolation factors and save them for later re-use. The rest was just a > routine programming. Now I'm able to display scalars and vectors (defined > at nodes of the original FE-mesh) on modified VTK meshes > (clipping/slicing/...) without recalculating these filters. It works > exactly as I wanted. VTK is a great library - thanks again. > > > > Mirek > > > > *From:* Will Schroeder [mailto:will.schroeder at kitware.com] > *Sent:* Tuesday, June 02, 2015 3:59 PM > *To:* Dr. Miroslav Sejna > *Cc:* vtk-developers > *Subject:* Re: [vtk-developers] Optimization of vtkClipDataSet and > vtkProbeFilter for large data? > > > > If I understand you correctly, it seems that your solution is to save in > memory the interpolation factors so that you can rapidly clip new attribute > data. Here's a probably crazy alternative suggestion that may have merit in > the long run. > > > > You could take advantage of (emerging) parallel hardware and recalculate > the interpolation factors anyway; i.e., do extra work but with lots of > processors it may be simpler and faster. There are currently several folks > working on these sorts of algorithms (including clipping) but the results > will not be available until later this year. If you can afford to be > patient, or want to to try your hand at writing some parallel algorithms, > I'm sure we can point you in the right direction. > > > > W > > > > On Mon, Jun 1, 2015 at 4:34 PM, Mirek wrote: > > Dear VTK developers, > > Filters like vtkClipDataSet and vtkProbeFilter, interpolating values of > vtkDataSetAttributes, work perfectly for relatively small data, i.e. if the > clipping is fast and you can have all vtkDataSetAttributes in memory. > However, it looks like there is no option to optimize these filters for > large data. In my case (see details (*) below), data of each quantity is > loaded "on demand" from the disk. The problem is that vtkClipDataSet cannot > interpolate new vtkDataSetAttributes into the existing (clipped) > unstructured grid without recalculating everything, which is unnecessary > and > slow. In my old program, all "interpolated points" had information how to > recalculate values of a new quantity (now vtkPointData scalars), which > actually is a simple and fast operation. In case of a tetrahedral mesh, you > just need to have IDs of 4 original mesh nodes and their weights for the > linear interpolation. > > I have spent several days by debugging VTK and looking for a standard > solution. Unfortunately, I have not found any way how to get and save the > interpolation factors so that I could reuse them. The interpolation of > vtkDataSetAttributes is implemented in vtkTetra::Clip and most of important > functions (vtkTetra::Clip, vtkDataSetAttributes::InterpolateEdge, ...) are > not virtual => it will not be easy to modify the filter. Before investing > time into the development of a new filter, I'd like to ask: Did I miss > something? Is there an existing solution for this problem? > > Thank you > Mirek > > (*) In my case the data can be really large: unstructured FE-meshes with up > to 50 mil. nodes and time-varying results (10-200 different quantities > defined by values at mesh nodes, while there can be 100 - 10000 time > layers). > > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Optimization-of-vtkClipDataSet-and-vtkProbeFilter-for-large-data-tp5732100.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > > > > -- > > William J. Schroeder, PhD > Kitware, Inc. > 28 Corporate Drive > Clifton Park, NY 12065 > will.schroeder at kitware.com > http://www.kitware.com > (518) 881-4902 > -- William J. Schroeder, PhD Kitware, Inc. 28 Corporate Drive Clifton Park, NY 12065 will.schroeder at kitware.com http://www.kitware.com (518) 881-4902 -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.sejna at pc-progress.com Wed Jun 3 08:27:17 2015 From: m.sejna at pc-progress.com (Dr. Miroslav Sejna) Date: Wed, 3 Jun 2015 12:27:17 +0000 Subject: [vtk-developers] Optimization of vtkClipDataSet and vtkProbeFilter for large data? In-Reply-To: <50320452A334BD42A5EC72BAD21450992A7ED93A@MBX110.d.ethz.ch> References: <1433190843126-5732100.post@n5.nabble.com> <753ef07b36e840668e424571a1050546@PCP-EXH1.pc-progress.com> <50320452A334BD42A5EC72BAD21450992A7ED93A@MBX110.d.ethz.ch> Message-ID: <0e01ad29a500434ba2b6e74f48db5460@PCP-EXH1.pc-progress.com> John, this is interesting, thank you. When I was searching for a solution, I noticed several your discussions (e.g. "Useless triangulation in unstructured grid rendering") but did not find vtkSPHProbeFilter. I will have a look at it. My solution already works fine for PointData (not yet for CellData) and seems to be sufficient for now. I also believe that it is an universal solution for all filters that internally use "vtkDataArray::InterpolateTuple" (i.e. vtkClipDataSet and vtkProbeFilter, but there is more such filters). However, it is too early to make any conclusions - I will need more time for thorough testing. Thanks Mirek From: Biddiscombe, John A. [mailto:biddisco at cscs.ch] Sent: Wednesday, June 03, 2015 10:43 AM To: Dr. Miroslav Sejna; Will Schroeder Cc: vtk-developers Subject: RE: [vtk-developers] Optimization of vtkClipDataSet and vtkProbeFilter for large data? Mirek I?m not sure I followed your explanation, but in case you?re doing more work than you need to... It is possible to compute interpolation weights and reuse them here I have computed weights for an interpolation (in the weights array) https://github.com/biddisco/pv-meshless/blob/master/vtkSPHProbeFilter.cxx#L944 and then pass them to the attribute arrays for computing the new values for each field at the point Id. (I use this on very large datasets, no problem) JB -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Wed Jun 3 09:25:22 2015 From: majcjc at gmail.com (Lin M) Date: Wed, 3 Jun 2015 09:25:22 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> Message-ID: Hi Dr. Thompson, Is there any example for 2- and 3-d Bezier Interpolation? Best, Lin On Sat, May 30, 2015 at 1:54 PM, Lin M wrote: > Hi Dr. Thompson, > > I have written a helper function to generate control points for arbitrary > ellipse and modified the PatchInterpolation.py test to image test which > contains line, circle and ellipse. > > A question about the push the data. I followed the instruction in > https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/data.md, > but I didn't see the message when doing the commit step. > > Some/Module/Testing/Data/Baseline/MyTest.png.md5: Added content to Git at refs/data/MD5/... > Some/Module/Testing/Data/Baseline/MyTest.png.md5: Added content to local store at .ExternalData/MD5/... > Content link Some/Module/Testing/Data/Baseline/MyTest.png.md5 -> .ExternalData/MD5/... > > The image test runs correctly in my local machine. > > Best, > Lin > > On Sat, May 23, 2015 at 12:16 AM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hi Lin, >> >> I believe VTK expects each test to generate a single baseline image whose >> filename matches the Python script name (e.g., >> TestSynchronizedTemplates3D.py >> must >> have its baseline image named TestSynchronizedTemplates3D. >> png >> in the Data/Baselines directory). >> >> David >> >> On May 22, 2015, at 23:15, Lin M wrote: >> >> Hi Dr. Thompson >> >> I changed the python test to baseline image and followed the instructions >> in the VTK Data page, but running CMake doesn't seem to make the .md5 >> files. Do you have any idea about that? >> >> I outputed two images named bezier-circle.png and bezier-line.png and put >> them in source-tree/Filters/Bezier/Testing/Data/Baseline. >> >> Best, >> Lin >> >> >> On Tue, May 19, 2015 at 1:52 PM, David Thompson < >> david.thompson at kitware.com> wrote: >> >>> Hi Lin, >>> >>> A few additional things that might help: >>> >>> 1. When you are done reviewing the merge request I assigned to you, >>> please click "Accept merge request" or add a "+1" comment so that it will >>> become part of the splines/filter-bezier branch. >>> >>> 2. A good pattern to follow for the image-based test is >>> Filters/Sources/Testing/Python/TestPlatonicSolids.py . You can see how it >>> obtains the path to img_file and calls vtk.test.Testing.compareImage to >>> perform a rendering to compare. The baseline image that the rendering is >>> compared against is not stored in the VTK git repo. Instead, MD5 checksums >>> of images are stored in the git repo and the images are uploaded >>> separately. See >>> >>> >>> https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/data.md >>> >>> for a description of how to generate a test image, add its MD5 sum, and >>> upload it with your merge request. >>> >>> 3. If you are going to generate helper methods to create conic sections, >>> then be aware that you'll have to return multiple sets of control points >>> because ellipses cannot be represented with a single patch (it is best to >>> return one patch per quadrant) because of the way they are parameterized. >>> >>> David >>> >>> > On May 18, 2015, at 10:45 PM, Lin M wrote: >>> > >>> > Hi Dr. Thompson >>> > >>> > Thanks! I'll look into that and implement the test asap. >>> > >>> > Best, >>> > Lin >>> > >>> > On Mon, May 18, 2015 at 10:36 PM, David Thompson < >>> david.thompson at kitware.com> wrote: >>> > Hi Lin, >>> > >>> > Sorry for the slow reply. >>> > >>> > > 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. >>> > >>> > I've pushed a merge request to the project that adds a couple simple >>> test cases. I'll add some more over the next few days. You can run the test >>> by building VTK with the VTK_WRAP_PYTHON option turned ON and then running: >>> > >>> > make >>> > ./bin/vtkpython >>> /path/to/src/Filters/Bezier/Testing/Python/PatchInterpolation.py >>> > >>> > If you uncomment the lines below the "For debugging, ..." message in >>> PatchInterpolation.py, running the test will create some files (named >>> bezier-circle.vtk and bezier-line.vtk) that you can load into ParaView. >>> > >>> > 1. As I mentioned earlier, it would be great to do image-based >>> testing. A good exercise would be to modify the Python test into an image >>> test version. >>> > >>> > 2. Another good exercise would be to generate control points for other >>> conic sections such as hyperbolas, parabolas, and the more generate case of >>> ellipses. I recommend "The NURBS Book" by Les Piegl; the circle quadrant >>> example in the Python test is from pp. 26--32 of the book. It would be >>> really nice to have a utility that would create control points given a few >>> shape parameters. For example: >>> > >>> > ctrlPts, prange = ellipse(major_radius=2, minor_radius=1) >>> > ctrlPts, prange = hyperbola(semi_major_axis=2/3, eccentricity=1) >>> > >>> > Once we have the 1-, 2-, and 3-d Bezier interpolation tested, we can >>> work on converting B-splines into B?zier patches and testing that. >>> > >>> > David >>> > >>> > > >>> > > On Mon, Apr 27, 2015 at 1:46 PM, David Thompson < >>> david.thompson at kitware.com> 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 brad.king at kitware.com Wed Jun 3 10:26:44 2015 From: brad.king at kitware.com (Brad King) Date: Wed, 03 Jun 2015 10:26:44 -0400 Subject: [vtk-developers] Merging changes in temporarily offline In-Reply-To: References: Message-ID: <556F0EA4.1050001@kitware.com> On 06/02/2015 11:15 AM, Utkarsh Ayachit wrote: > As many of you may know, we upgraded our GitLab installation yesterday. > As with many things one doesn't expect to have any issues, we have had > some issues :). While we figure things out, merging branches will be > temporarily offline. Things should be back online by tomorrow. Service should be back to normal now. For those interested, the problem was that the new GitLab version (incorrectly) ignores some remote API query parameters that the old version (correctly) honored, but it only mattered in certain cases. This is why some actions worked and others didn't. We've taught our client to tolerate this bug. -Brad From utkarsh.ayachit at kitware.com Wed Jun 3 10:28:00 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Wed, 03 Jun 2015 14:28:00 +0000 Subject: [vtk-developers] Merging changes in temporarily offline In-Reply-To: <556F0EA4.1050001@kitware.com> References: <556F0EA4.1050001@kitware.com> Message-ID: Awesome! Thanks for the fix, Brad. Utkarsh On Wed, Jun 3, 2015 at 10:26 AM Brad King wrote: > On 06/02/2015 11:15 AM, Utkarsh Ayachit wrote: > > As many of you may know, we upgraded our GitLab installation yesterday. > > As with many things one doesn't expect to have any issues, we have had > > some issues :). While we figure things out, merging branches will be > > temporarily offline. Things should be back online by tomorrow. > > Service should be back to normal now. > > For those interested, the problem was that the new GitLab version > (incorrectly) ignores some remote API query parameters that the old > version (correctly) honored, but it only mattered in certain cases. > This is why some actions worked and others didn't. We've taught our > client to tolerate this bug. > > -Brad > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Jun 3 16:35:47 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 3 Jun 2015 16:35:47 -0400 Subject: [vtk-developers] Long standing freak VTK tear down crash Message-ID: <20150603203547.13079634@mail.rogue-research.com> Hi all, For literally years, we have received rare, intermittent, and non-reproducible crash reports from our customers involving VTK tear down. The backtrace is always something like: Application Specific Information: *** error for object 0x111b15930: double free Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 libsystem_kernel.dylib 0x00007fff999d9286 __pthread_kill + 10 1 libsystem_c.dylib 0x00007fff9593fb53 abort + 129 2 libsystem_malloc.dylib 0x00007fff8c625e06 szone_error + 625 3 GLEngine 0x00007fff8fc22ea7 gleUnbindDeleteHashNamesAndObjects + 252 4 GLEngine 0x00007fff8fb21766 glDeleteTextures_Exec + 749 5 com.rogue-research.brainsight2 0x00000001009bf5f4 vtkCocoaRenderWindow::DestroyWindow() + 164 6 com.rogue-research.brainsight2 0x00000001009bfae1 vtkCocoaRenderWindow::~vtkCocoaRenderWindow() + 273 .... etc. I know there's next to nothing to go on here :(, but anyone else ever see this? Or have any ideas? We've seen it in-house a couple of times, but have never caught it with valgrind or similar memory debugging tools. :( 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 majcjc at gmail.com Wed Jun 3 18:52:31 2015 From: majcjc at gmail.com (Lin M) Date: Wed, 3 Jun 2015 18:52:31 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> Message-ID: Hi Dr. Thompson, I have added helper functions for ellipse and hyperbola to generate control points for these curves. The NURBS book gives a 2-d bezier interpolation case which is a cylinder and I will added this to the current test soon. Best, Lin On Wed, Jun 3, 2015 at 9:25 AM, Lin M wrote: > Hi Dr. Thompson, > > Is there any example for 2- and 3-d Bezier Interpolation? > > Best, > Lin > > On Sat, May 30, 2015 at 1:54 PM, Lin M wrote: > >> Hi Dr. Thompson, >> >> I have written a helper function to generate control points for arbitrary >> ellipse and modified the PatchInterpolation.py test to image test which >> contains line, circle and ellipse. >> >> A question about the push the data. I followed the instruction in >> https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/data.md, >> but I didn't see the message when doing the commit step. >> >> Some/Module/Testing/Data/Baseline/MyTest.png.md5: Added content to Git at refs/data/MD5/... >> Some/Module/Testing/Data/Baseline/MyTest.png.md5: Added content to local store at .ExternalData/MD5/... >> Content link Some/Module/Testing/Data/Baseline/MyTest.png.md5 -> .ExternalData/MD5/... >> >> The image test runs correctly in my local machine. >> >> Best, >> Lin >> >> On Sat, May 23, 2015 at 12:16 AM, David Thompson < >> david.thompson at kitware.com> wrote: >> >>> Hi Lin, >>> >>> I believe VTK expects each test to generate a single baseline image >>> whose filename matches the Python script name (e.g., >>> TestSynchronizedTemplates3D.py >>> must >>> have its baseline image named TestSynchronizedTemplates3D. >>> png >>> in the Data/Baselines directory). >>> >>> David >>> >>> On May 22, 2015, at 23:15, Lin M wrote: >>> >>> Hi Dr. Thompson >>> >>> I changed the python test to baseline image and followed the >>> instructions in the VTK Data page, but running CMake doesn't seem to make >>> the .md5 files. Do you have any idea about that? >>> >>> I outputed two images named bezier-circle.png and bezier-line.png and >>> put them in source-tree/Filters/Bezier/Testing/Data/Baseline. >>> >>> Best, >>> Lin >>> >>> >>> On Tue, May 19, 2015 at 1:52 PM, David Thompson < >>> david.thompson at kitware.com> wrote: >>> >>>> Hi Lin, >>>> >>>> A few additional things that might help: >>>> >>>> 1. When you are done reviewing the merge request I assigned to you, >>>> please click "Accept merge request" or add a "+1" comment so that it will >>>> become part of the splines/filter-bezier branch. >>>> >>>> 2. A good pattern to follow for the image-based test is >>>> Filters/Sources/Testing/Python/TestPlatonicSolids.py . You can see how it >>>> obtains the path to img_file and calls vtk.test.Testing.compareImage to >>>> perform a rendering to compare. The baseline image that the rendering is >>>> compared against is not stored in the VTK git repo. Instead, MD5 checksums >>>> of images are stored in the git repo and the images are uploaded >>>> separately. See >>>> >>>> >>>> https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/data.md >>>> >>>> for a description of how to generate a test image, add its MD5 sum, and >>>> upload it with your merge request. >>>> >>>> 3. If you are going to generate helper methods to create conic >>>> sections, then be aware that you'll have to return multiple sets of control >>>> points because ellipses cannot be represented with a single patch (it is >>>> best to return one patch per quadrant) because of the way they are >>>> parameterized. >>>> >>>> David >>>> >>>> > On May 18, 2015, at 10:45 PM, Lin M wrote: >>>> > >>>> > Hi Dr. Thompson >>>> > >>>> > Thanks! I'll look into that and implement the test asap. >>>> > >>>> > Best, >>>> > Lin >>>> > >>>> > On Mon, May 18, 2015 at 10:36 PM, David Thompson < >>>> david.thompson at kitware.com> wrote: >>>> > Hi Lin, >>>> > >>>> > Sorry for the slow reply. >>>> > >>>> > > 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. >>>> > >>>> > I've pushed a merge request to the project that adds a couple simple >>>> test cases. I'll add some more over the next few days. You can run the test >>>> by building VTK with the VTK_WRAP_PYTHON option turned ON and then running: >>>> > >>>> > make >>>> > ./bin/vtkpython >>>> /path/to/src/Filters/Bezier/Testing/Python/PatchInterpolation.py >>>> > >>>> > If you uncomment the lines below the "For debugging, ..." message in >>>> PatchInterpolation.py, running the test will create some files (named >>>> bezier-circle.vtk and bezier-line.vtk) that you can load into ParaView. >>>> > >>>> > 1. As I mentioned earlier, it would be great to do image-based >>>> testing. A good exercise would be to modify the Python test into an image >>>> test version. >>>> > >>>> > 2. Another good exercise would be to generate control points for >>>> other conic sections such as hyperbolas, parabolas, and the more generate >>>> case of ellipses. I recommend "The NURBS Book" by Les Piegl; the circle >>>> quadrant example in the Python test is from pp. 26--32 of the book. It >>>> would be really nice to have a utility that would create control points >>>> given a few shape parameters. For example: >>>> > >>>> > ctrlPts, prange = ellipse(major_radius=2, minor_radius=1) >>>> > ctrlPts, prange = hyperbola(semi_major_axis=2/3, eccentricity=1) >>>> > >>>> > Once we have the 1-, 2-, and 3-d Bezier interpolation tested, we can >>>> work on converting B-splines into B?zier patches and testing that. >>>> > >>>> > David >>>> > >>>> > > >>>> > > On Mon, Apr 27, 2015 at 1:46 PM, David Thompson < >>>> david.thompson at kitware.com> 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 guillaume.du.roy at gmail.com Wed Jun 3 19:23:33 2015 From: guillaume.du.roy at gmail.com (Guillaume du Roy) Date: Thu, 4 Jun 2015 01:23:33 +0200 Subject: [vtk-developers] VES build error Message-ID: <52A515CA-70CA-4BB4-82B4-ACF1A65D351A@gmail.com> i get this error whilst making the VES build folder : Guillaumes-MacBook-Pro:vesbuild Guillaume$ make -j4 [ 9%] [ 9%] [ 10%] Built target eigen [ 18%] Performing update step for 'curl-download' Built target vtk-host Performing update step for 'libarchive-download' [ 19%] [ 20%] Performing build step for 'vtk-ios-device' Performing configure step for 'vtk-ios-simulator' [ 21%] loading initial cache file /Users/Guillaume/Desktop/VES/CMake/toolchains/TryRunResults.cmake No configure step for 'libarchive-download' -- -- Using iOS SDK: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator8.3.sdk [ 22%] No build step for 'libarchive-download' [ 1%] Built target vtksys [ 23%] No install step for 'libarchive-download' [ 1%] Built target vtkDICOMParser [ 24%] Completed 'libarchive-download' [ 2%] -- The C compiler identification is AppleClang 6.1.0.6020049 Built target vtkalglib [ 27%] Built target libarchive-download [ 3%] Built target vtkzlib [ 3%] Built target vtkjsoncpp [ 28%] Performing configure step for 'libarchive-ios-device' [ 6%] -- The CXX compiler identification is AppleClang 6.1.0.6020049 -- -- Using iOS SDK: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.3.sdk Built target vtkjpeg -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc CMake Warning (dev) at CMakeLists.txt:87 (IF): Policy CMP0054 is not set: Only interpret if() arguments as variables or keywords when unquoted. Run "cmake --help-policy CMP0054" for policy details. Use the cmake_policy command to set the policy and suppress this warning. Quoted variables like "CMAKE_C_COMPILER_ID" will no longer be dereferenced when the policy is set to NEW. Since the policy is not set the OLD behavior will be used. This warning is for project developers. Use -Wno-dev to suppress it. [ 7%] Built target vtkpng -- Found ZLIB: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.3.sdk/usr/lib/libz.dylib (found version "1.2.5") [ 10%] Built target vtktiff -- Found BZip2: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.3.sdk/usr/lib/libbz2.dylib (found version "1.0.6") -- Looking for BZ2_bzCompressInit in /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS8.3.sdk/usr/lib/libbz2.dylib -- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc -- broken CMake Error at /opt/local/share/cmake-3.2/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc" is not able to compile a simple test program. It fails with the following output: Change Dir: /Users/Guillaume/Desktop/vesbuild/CMakeExternals/Build/vtk-ios-simulator/CMakeFiles/CMakeTmp Run Build Command:"/usr/bin/make" "cmTryCompileExec3556854147/fast" /Applications/Xcode.app/Contents/Developer/usr/bin/make -f CMakeFiles/cmTryCompileExec3556854147.dir/build.make CMakeFiles/cmTryCompileExec3556854147.dir/build /opt/local/bin/cmake -E cmake_progress_report /Users/Guillaume/Desktop/vesbuild/CMakeExternals/Build/vtk-ios-simulator/CMakeFiles/CMakeTmp/CMakeFiles 1 Building C [ 13%] object CMakeFiles/cmTryCompileExec3556854147.dir/testCCompiler.c.o /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc -fvisibility=hidden -fvisibility-inlines-hidden -D__PHONE_OS_VERSION_MIN_REQIORED=50000 -fvisibility=hidden -fvisibility-inlines-hidden -D__PHONE_OS_VERSION_MIN_REQIORED=50000 -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator8.3.sdk -o CMakeFiles/cmTryCompileExec3556854147.dir/testCCompiler.c.o -c /Users/Guillaume/Desktop/vesbuild/CMakeExternals/Build/vtk-ios-simulator/CMakeFiles/CMakeTmp/testCCompiler.c Linking C executable cmTryCompileExec3556854147 /opt/local/bin/cmake -E cmake_link_script CMakeFiles/cmTryCompileExec3556854147.dir/link.txt --verbose=1 /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/gcc -fvisibility=hidden -fvisibility-inlines-hidden -D__PHONE_OS_VERSION_MIN_REQIORED=50000 -fvisibility=hidden -fvisibility-inlines-hidden -D__PHONE_OS_VERSION_MIN_REQIORED=50000 -arch i386 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator8.3.sdk -Wl,-headerpad_max_install_names CMakeFiles/cmTryCompileExec3556854147.dir/testCCompiler.c.o -o cmTryCompileExec3556854147 ld: building for MacOSX, but linking against dylib built for iOS Simulator file '/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator8.3.sdk/usr/lib/libSystem.dylib' for architecture i386 clang: error: linker command failed with exit code 1 (use -v to see invocation) make[4]: *** [cmTryCompileExec3556854147] Error 1 make[3]: *** [cmTryCompileExec3556854147/fast] Error 2 CMake will not be able to correctly generate this project. Call Stack (most recent call first): CMakeLists.txt:3 (project) Built target vtklibxml2 -- Configuring incomplete, errors occurred! See also "/Users/Guillaume/Desktop/vesbuild/CMakeExternals/Build/vtk-ios-simulator/CMakeFiles/CMakeOutput.log". See also "/Users/Guillaume/Desktop/vesbuild/CMakeExternals/Build/vtk-ios-simulator/CMakeFiles/CMakeError.log". make[2]: *** [CMakeExternals/Stamp/vtk-ios-simulator/vtk-ios-simulator-configure] Error 1 make[1]: *** [CMakeFiles/vtk-ios-simulator.dir/all] Error 2 make[1]: *** Waiting for unfinished jobs.... -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Thu Jun 4 05:01:28 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Thu, 4 Jun 2015 02:01:28 -0700 (MST) Subject: [vtk-developers] Compiling VTK for Android: issues on all platform Message-ID: <1433408488492-5732162.post@n5.nabble.com> Hello. I am lucky enough to have multiple platforms available in mylab so that I can try and build VTK for android on all of them. However, so far I have been unsuccessful on MAC, Windows 8 and Ubuntu. But let's focus on ubuntu and mac as they are my primary platforms. So I have used Cmake in the way describe in a blog post and you can see here the output of my terminal when trying to make. output I really do not know what I can do to solve this. If you want to see my CMakeCache here it is: CMakeCache.txt -- View this message in context: http://vtk.1045678.n5.nabble.com/Compiling-VTK-for-Android-issues-on-all-platform-tp5732162.html Sent from the VTK - Dev mailing list archive at Nabble.com. From david.thompson at kitware.com Thu Jun 4 10:38:15 2015 From: david.thompson at kitware.com (David Thompson) Date: Thu, 4 Jun 2015 10:38: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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> Message-ID: <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> Hi Lin, > I have written a helper function to generate control points for arbitrary ellipse and modified the PatchInterpolation.py test to image test which contains line, circle and ellipse. Excellent! I will do a detailed review of the changes this evening. At a quick glance, some things that would be nice are: 1. Being able to specify ellipses in 3D with vectors (see Common/DataModel/vtkVector.h) representing the center, major axis, and minor axis (both direction and length). The minor axis would have to be orthogonalized using Gram-Shmidt orthonormalization ( https://en.wikipedia.org/wiki/Gram%E2%80%93Schmidt_process ). 2. Being able to return multiple patches so that an entire ellipse could be generated at once. Then, besides the 3 vectors (center, major, minor), two angles could be accepted indicating where the patch could start and stop. This would mean outputting multiple patch points. It will also require a subdivision algorithm to split a patch at a given parameter value (which we will use in several other places later this summer). In terms of further development, in order to render 2-D splines properly, we will need a method to evaluate surface normals for patches. More generally, it would be nice to have an additional evaluation method that computes the derivative as well as the coordinates of the B?zier patch at the input points. (Note that the derivative is a vector with the same dimension as the parameter-space of the patch.) > A question about the push the data. I followed the instruction in https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/data.md, but I didn't see the message when doing the commit step. That's OK, we'll figure it out when it comes time to submit the patch for review and inclusion into VTK. Hopefully we can do that next week. Thanks, David From dan.lipsa at kitware.com Thu Jun 4 11:03:25 2015 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Thu, 04 Jun 2015 15:03:25 +0000 Subject: [vtk-developers] clean-up VTK_LEGACY code In-Reply-To: References: Message-ID: I sent an email to the VTK users list. It would be nice to make it more obvious when people are using deprecated code, for instance using #warning preprocessor option. Right now users get run-time messages and possible no message at all if code is only excluded using VTK_LEGACY_REMOVE. They have to recompile their code using VTK_LEGACY_REMOVE cmake option to see that they use deprecated code. On Mon, Jun 1, 2015 at 5:43 PM Bill Lorensen wrote: > We should announce to both lists to turn on this flag. Do not assume that > our customers are not using this code. > On Jun 1, 2015 5:05 PM, "Utkarsh Ayachit" > wrote: > >> So, the best way to test for deprecated code seems to be to >>> define VTK_LEGACY_REMOVE. >>> >> >> Note that VTK_LEGACY_REMOVE is a CMake option that can be turned on when >> building VTK. >> >> Utkarsh >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aashish.chaudhary at kitware.com Thu Jun 4 12:05:27 2015 From: aashish.chaudhary at kitware.com (Aashish Chaudhary) Date: Thu, 4 Jun 2015 12:05:27 -0400 Subject: [vtk-developers] Volume Rendering Update In-Reply-To: References: Message-ID: Hi All, Just wanted to let you know that we merged another branch earlier this morning and that should improve volume rendering shading performance by upto 300% (results may vary depending on the OS, datatype, and what features are used and enabled). If you run into slowness or any other bottleneck, please feel free to contact us. Thanks, Aashish On Fri, May 29, 2015 at 5:31 PM, Aashish Chaudhary < aashish.chaudhary at kitware.com> wrote: > Folks, > > We made some recent improvements to VTK volume rendering including fixes > to related components. Here is a list of those changes: > > 1) Now new GPU Volume Mapper respect Interpolation Type (Linear or > Nearest). Default is Nearest as in the last GPU mapper. > > 2) Shading is now twice as fast as before. There will be another branch to > make it even faster. > > 3) Fixed lighting bug (number of lights kept on increasing with change in > volume property) > > 4) Saving and Restoring GL state properly for textures > > 5) Bias and Scale are now performed in Shader. > > 6) We changed some GL texture format information to support OpenGL 3 > context > > 7) Fixed extensions were not reported correctly on GL2 context > > 8) Fixed few failing tests specifically on Mesa > > 9) Removed VolumeOpenGLNew module as it was not as usable with OpenGL2 > getting ready for primetime > > 10) Added convenience API to SmartVolume Mapper > > 11) Cleaned up logic for dealing with context changes in Volume Mapper > > > Please let us know if you have any questions. > > Thanks, > > > -- > > > > *| Aashish Chaudhary | Technical Leader | Kitware Inc. * > *| http://www.kitware.com/company/team/chaudhary.html > * > -- *| Aashish Chaudhary | Technical Leader | Kitware Inc. * *| http://www.kitware.com/company/team/chaudhary.html * -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Fri Jun 5 04:33:22 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Fri, 5 Jun 2015 01:33:22 -0700 (MST) Subject: [vtk-developers] VES build error In-Reply-To: <52A515CA-70CA-4BB4-82B4-ACF1A65D351A@gmail.com> References: <52A515CA-70CA-4BB4-82B4-ACF1A65D351A@gmail.com> Message-ID: <1433493202101-5732174.post@n5.nabble.com> Hello, I am a complete newbie but here is what I have to say about your output. Apparently the gcc compiler doesn't work. Have you checked it is present in /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/. If it is cane try and compile with it? Also, VTK now supports android and iOS. You should give up on VES. -- View this message in context: http://vtk.1045678.n5.nabble.com/VES-build-error-tp5732157p5732174.html Sent from the VTK - Dev mailing list archive at Nabble.com. From bill.lorensen at gmail.com Sat Jun 6 12:48:14 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 6 Jun 2015 12:48:14 -0400 Subject: [vtk-developers] vtkPentagonalPrism Bug Message-ID: Folks, I've been working on a Unit test for linear cells. So far I have found a few bugs that I could easily fix. My testing has uncovered a problem with vtkPentagonalPrism that I cannot fix on my own. If I compute the real center from the parametric center, the real center is not within the bounds of the cell. This is the only cell that fails this test. I have attached a small program and cmake file that illustrates the problem. Bill -------------- next part -------------- cmake_minimum_required(VERSION 2.8) PROJECT(PentagonalPrismBug) find_package(VTK REQUIRED) include(${VTK_USE_FILE}) add_executable(PentagonalPrismBug MACOSX_BUNDLE PentagonalPrismBug) target_link_libraries(PentagonalPrismBug ${VTK_LIBRARIES}) -------------- next part -------------- A non-text attachment was scrubbed... Name: PentagonalPrismBug.cxx Type: text/x-c++src Size: 2553 bytes Desc: not available URL: From bill.lorensen at gmail.com Sun Jun 7 13:35:12 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sun, 7 Jun 2015 13:35:12 -0400 Subject: [vtk-developers] Continuous Dashboards? Message-ID: The last continuous dashboard was Wednesday? Whazz up? From bill.lorensen at gmail.com Sun Jun 7 14:40:27 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sun, 7 Jun 2015 14:40:27 -0400 Subject: [vtk-developers] vtkPentagonalPrism Bug In-Reply-To: References: Message-ID: Sorry, the posted code was incorrect, but the results are still wrong... On Sat, Jun 6, 2015 at 12:48 PM, Bill Lorensen wrote: > Folks, > > I've been working on a Unit test for linear cells. So far I have found > a few bugs that I could easily fix. > > My testing has uncovered a problem with vtkPentagonalPrism that I > cannot fix on my own. > > If I compute the real center from the parametric center, the real > center is not within the bounds of the cell. This is the only cell > that fails this test. > > I have attached a small program and cmake file that illustrates the problem. > > Bill -- Unpaid intern in BillsBasement at noware dot com -------------- next part -------------- A non-text attachment was scrubbed... Name: PentagonalPrismBug.cxx Type: text/x-c++src Size: 2547 bytes Desc: not available URL: From ashray.malhotra.1994 at gmail.com Sun Jun 7 14:53:53 2015 From: ashray.malhotra.1994 at gmail.com (Ashray Malhotra) Date: Mon, 8 Jun 2015 00:23:53 +0530 Subject: [vtk-developers] Sharing a build issue solution - Multiple Message-ID: Hello all, I wasted a lot of time on a silly VTK building issue and wanted to share it with you guys to make sure none of you run into the same issue. I had built VTK and everything was running perfectly on my system. I was just experimenting with the VTK code and tried to compile it, but just to check I compiled it with the configuration of OpenGL2. But then after this my codes didn't compile(not even those that used to work earlier). After this I reverted back to building using OpenGL, again did a cmake for the new configuration. In both the steps I had done make install to copy the files to /usr/local(I use OS X). Even after building VTK with OpenGL multiple times(using slightly different configurations), none of the previously working codes were compiling, make was unsuccessful. I did make clean and git clean -df to get back to the previous working state and then built VTK again but alas even this failed. Finally I figured out that the error was that VTK while running was still using the OpenGL2 files from the /usr/local since make install did not remove the older VTK files in that directory. Hence I manually removed all the vtk associated files from that directory(using terminal). I followed it by a make install which successfully. I wasted over 2 days of productive time trying to figure this out, I hope it will help you guys save your time if you ever fall into this problem. Thanks. -- Regards Ashray Malhotra -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.lipsa at kitware.com Sun Jun 7 15:49:00 2015 From: dan.lipsa at kitware.com (Dan Lipsa) Date: Sun, 07 Jun 2015 19:49:00 +0000 Subject: [vtk-developers] Continuous Dashboards? In-Reply-To: References: Message-ID: Hi Bill, We plan to convert the machines that run on the continuous dashboard to buildbot machines that will test individual changes. dash3 was converted on Friday, but it seems there is something wrong with it. I'll convert dash1win7, kargad on Monday probably. Dan On Sun, Jun 7, 2015 at 1:35 PM Bill Lorensen wrote: > The last continuous dashboard was Wednesday? > > Whazz up? > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Mon Jun 8 03:59:42 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Mon, 8 Jun 2015 17:59:42 +1000 Subject: [vtk-developers] vtkPentagonalPrism Bug Message-ID: Hi Bill, Just guessing. Could it be that the pentagonal faces have to be regular for this sort of formula to work? I.e. the five points defining the pentagonal face must lie on a circle and be equidistant from each other. Regards Andrew > ---------- Forwarded message ---------- > From: Bill Lorensen > To: VTK Developers > Cc: Mathieu Malaterre > Date: Sat, 6 Jun 2015 12:48:14 -0400 > Subject: [vtk-developers] vtkPentagonalPrism Bug > Folks, > > I've been working on a Unit test for linear cells. So far I have found > a few bugs that I could easily fix. > > My testing has uncovered a problem with vtkPentagonalPrism that I > cannot fix on my own. > > If I compute the real center from the parametric center, the real > center is not within the bounds of the cell. This is the only cell > that fails this test. > > I have attached a small program and cmake file that illustrates the problem. > > Bill > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Mon Jun 8 22:32:37 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 8 Jun 2015 22:32:37 -0400 Subject: [vtk-developers] Sharing a build issue solution - Multiple In-Reply-To: References: Message-ID: Ouch - painful, thanks for sharing. Probably because of reasons like this I habitually use build tree. About the only time I ever run make install is at release time testing out release candidates. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Sun, Jun 7, 2015 at 2:53 PM, Ashray Malhotra < ashray.malhotra.1994 at gmail.com> wrote: > Hello all, > > I wasted a lot of time on a silly VTK building issue and wanted to share > it with you guys to make sure none of you run into the same issue. > > I had built VTK and everything was running perfectly on my system. I was > just experimenting with the VTK code and tried to compile it, but just to > check I compiled it with the configuration of OpenGL2. But then after this > my codes didn't compile(not even those that used to work earlier). After > this I reverted back to building using OpenGL, again did a cmake for the > new configuration. In both the steps I had done make install to copy the > files to /usr/local(I use OS X). > > Even after building VTK with OpenGL multiple times(using slightly > different configurations), none of the previously working codes were > compiling, make was unsuccessful. I did make clean and git clean -df to get > back to the previous working state and then built VTK again but alas even > this failed. > > Finally I figured out that the error was that VTK while running was still > using the OpenGL2 files from the /usr/local since make install did not > remove the older VTK files in that directory. Hence I manually removed all > the vtk associated files from that directory(using terminal). I followed it > by a make install which successfully. > > I wasted over 2 days of productive time trying to figure this out, I hope > it will help you guys save your time if you ever fall into this problem. > > Thanks. > > -- > Regards > Ashray Malhotra > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Tue Jun 9 03:14:34 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 9 Jun 2015 17:14:34 +1000 Subject: [vtk-developers] vtkPentagonalPrism Bug Message-ID: Hi Bill, I played around with it today and I am pretty sure that the problem lies with the EXPRA ... EXPRN defines in vtkPentagonalPrism.cxx. These are used in InterpolationFunctions(), InterpolationDerivs(). EvaluateLocation() uses InterpolationFunctions() to determine the weights. I don't understand the mathematical basis for the calculation of these and a web search has not revealed anything. Regards Andrew > ---------- Forwarded message ---------- > From: Bill Lorensen > To: VTK Developers > Cc: Mathieu Malaterre > Date: Sun, 7 Jun 2015 14:40:27 -0400 > Subject: Re: [vtk-developers] vtkPentagonalPrism Bug > Sorry, the posted code was incorrect, but the results are still wrong... > > > On Sat, Jun 6, 2015 at 12:48 PM, Bill Lorensen > wrote: > > Folks, > > > > I've been working on a Unit test for linear cells. So far I have found > > a few bugs that I could easily fix. > > > > My testing has uncovered a problem with vtkPentagonalPrism that I > > cannot fix on my own. > > > > If I compute the real center from the parametric center, the real > > center is not within the bounds of the cell. This is the only cell > > that fails this test. > > > > I have attached a small program and cmake file that illustrates the > problem. > > > > Bill > > > > -- > Unpaid intern in BillsBasement at noware dot com > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Tue Jun 9 08:26:38 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 9 Jun 2015 08:26:38 -0400 Subject: [vtk-developers] vtkPentagonalPrism Bug In-Reply-To: References: Message-ID: Andrew, It is definitely as issue with the shape functions. I have played with them a bit and also looked for info on the web. I believe the sf's should sum to 1. But currently they only sum to one at the vertices of the cell. I made a change to normalize them each time they are computed. That fixes the computed center issue, but causes other problems. I'm hoping one of the original authors will respond. Thanks for looking at it, Bill On Tue, Jun 9, 2015 at 3:14 AM, Andrew Maclean wrote: > Hi Bill, > I played around with it today and I am pretty sure that the problem lies > with the EXPRA ... EXPRN defines in vtkPentagonalPrism.cxx. These are used > in InterpolationFunctions(), InterpolationDerivs(). > > EvaluateLocation() uses InterpolationFunctions() to determine the weights. > > I don't understand the mathematical basis for the calculation of these and a > web search has not revealed anything. > > Regards > Andrew > >> >> ---------- Forwarded message ---------- >> From: Bill Lorensen >> To: VTK Developers >> Cc: Mathieu Malaterre >> Date: Sun, 7 Jun 2015 14:40:27 -0400 >> Subject: Re: [vtk-developers] vtkPentagonalPrism Bug >> Sorry, the posted code was incorrect, but the results are still wrong... >> >> >> On Sat, Jun 6, 2015 at 12:48 PM, Bill Lorensen >> wrote: >> > Folks, >> > >> > I've been working on a Unit test for linear cells. So far I have found >> > a few bugs that I could easily fix. >> > >> > My testing has uncovered a problem with vtkPentagonalPrism that I >> > cannot fix on my own. >> > >> > If I compute the real center from the parametric center, the real >> > center is not within the bounds of the cell. This is the only cell >> > that fails this test. >> > >> > I have attached a small program and cmake file that illustrates the >> > problem. >> > >> > Bill >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> >> > -- > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ -- Unpaid intern in BillsBasement at noware dot com From bill.lorensen at gmail.com Tue Jun 9 09:07:26 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 9 Jun 2015 09:07:26 -0400 Subject: [vtk-developers] vtkPentagonalPrism Bug In-Reply-To: References: Message-ID: There was a change made a while back to force the sum of the weights to be 1 and drives to be 0. I believe that change is flawed. But, the original code also fails to compute a valid center point. If I normalize the weights, the center is computed properly, but the EvaluatePosition code that uses the derivatives fails. On Tue, Jun 9, 2015 at 8:38 AM, Mathieu Malaterre wrote: > Hi Bill, > > I wrote that a long time ago. I used the same approach in the 5-case and the > 6-case. So formulation should be very similar in the other prism (hexa one). > Since the points are chosen on a circle, I do not understand why it would > fail your test. > > Are the formulations the same, or were they changed by someone else ? > > -2cts > > On Tue, Jun 9, 2015 at 2:26 PM, Bill Lorensen > wrote: >> >> Andrew, >> >> It is definitely as issue with the shape functions. I have played with >> them a bit and also looked for info on the web. I believe the sf's >> should sum to 1. But currently they only sum to one at the vertices of >> the cell. >> >> I made a change to normalize them each time they are computed. That >> fixes the computed center issue, but causes other problems. >> >> I'm hoping one of the original authors will respond. >> >> Thanks for looking at it, >> >> Bill >> >> On Tue, Jun 9, 2015 at 3:14 AM, Andrew Maclean >> wrote: >> > Hi Bill, >> > I played around with it today and I am pretty sure that the problem >> > lies >> > with the EXPRA ... EXPRN defines in vtkPentagonalPrism.cxx. These are >> > used >> > in InterpolationFunctions(), InterpolationDerivs(). >> > >> > EvaluateLocation() uses InterpolationFunctions() to determine the >> > weights. >> > >> > I don't understand the mathematical basis for the calculation of these >> > and a >> > web search has not revealed anything. >> > >> > Regards >> > Andrew >> > >> >> >> >> ---------- Forwarded message ---------- >> >> From: Bill Lorensen >> >> To: VTK Developers >> >> Cc: Mathieu Malaterre >> >> Date: Sun, 7 Jun 2015 14:40:27 -0400 >> >> Subject: Re: [vtk-developers] vtkPentagonalPrism Bug >> >> Sorry, the posted code was incorrect, but the results are still >> >> wrong... >> >> >> >> >> >> On Sat, Jun 6, 2015 at 12:48 PM, Bill Lorensen >> >> >> >> wrote: >> >> > Folks, >> >> > >> >> > I've been working on a Unit test for linear cells. So far I have >> >> > found >> >> > a few bugs that I could easily fix. >> >> > >> >> > My testing has uncovered a problem with vtkPentagonalPrism that I >> >> > cannot fix on my own. >> >> > >> >> > If I compute the real center from the parametric center, the real >> >> > center is not within the bounds of the cell. This is the only cell >> >> > that fails this test. >> >> > >> >> > I have attached a small program and cmake file that illustrates the >> >> > problem. >> >> > >> >> > Bill >> >> >> >> >> >> >> >> -- >> >> Unpaid intern in BillsBasement at noware dot com >> >> >> >> >> > -- >> > ___________________________________________ >> > Andrew J. P. Maclean >> > >> > ___________________________________________ >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com > > > > > -- > Mathieu -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Tue Jun 9 09:10:27 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 9 Jun 2015 09:10:27 -0400 Subject: [vtk-developers] vtkPentagonalPrism Bug In-Reply-To: References: Message-ID: I CC'ed Jean, who seems to be the true original author of this code. Maybe he'll have something to add. -berk On Tue, Jun 9, 2015 at 9:07 AM, Bill Lorensen wrote: > There was a change made a while back to force the sum of the weights > to be 1 and drives to be 0. I believe that change is flawed. > > But, the original code also fails to compute a valid center point. If > I normalize the weights, the center is computed properly, but the > EvaluatePosition code that uses the derivatives fails. > > On Tue, Jun 9, 2015 at 8:38 AM, Mathieu Malaterre > wrote: > > Hi Bill, > > > > I wrote that a long time ago. I used the same approach in the 5-case and > the > > 6-case. So formulation should be very similar in the other prism (hexa > one). > > Since the points are chosen on a circle, I do not understand why it would > > fail your test. > > > > Are the formulations the same, or were they changed by someone else ? > > > > -2cts > > > > On Tue, Jun 9, 2015 at 2:26 PM, Bill Lorensen > > wrote: > >> > >> Andrew, > >> > >> It is definitely as issue with the shape functions. I have played with > >> them a bit and also looked for info on the web. I believe the sf's > >> should sum to 1. But currently they only sum to one at the vertices of > >> the cell. > >> > >> I made a change to normalize them each time they are computed. That > >> fixes the computed center issue, but causes other problems. > >> > >> I'm hoping one of the original authors will respond. > >> > >> Thanks for looking at it, > >> > >> Bill > >> > >> On Tue, Jun 9, 2015 at 3:14 AM, Andrew Maclean > >> wrote: > >> > Hi Bill, > >> > I played around with it today and I am pretty sure that the problem > >> > lies > >> > with the EXPRA ... EXPRN defines in vtkPentagonalPrism.cxx. These are > >> > used > >> > in InterpolationFunctions(), InterpolationDerivs(). > >> > > >> > EvaluateLocation() uses InterpolationFunctions() to determine the > >> > weights. > >> > > >> > I don't understand the mathematical basis for the calculation of these > >> > and a > >> > web search has not revealed anything. > >> > > >> > Regards > >> > Andrew > >> > > >> >> > >> >> ---------- Forwarded message ---------- > >> >> From: Bill Lorensen > >> >> To: VTK Developers > >> >> Cc: Mathieu Malaterre > >> >> Date: Sun, 7 Jun 2015 14:40:27 -0400 > >> >> Subject: Re: [vtk-developers] vtkPentagonalPrism Bug > >> >> Sorry, the posted code was incorrect, but the results are still > >> >> wrong... > >> >> > >> >> > >> >> On Sat, Jun 6, 2015 at 12:48 PM, Bill Lorensen > >> >> > >> >> wrote: > >> >> > Folks, > >> >> > > >> >> > I've been working on a Unit test for linear cells. So far I have > >> >> > found > >> >> > a few bugs that I could easily fix. > >> >> > > >> >> > My testing has uncovered a problem with vtkPentagonalPrism that I > >> >> > cannot fix on my own. > >> >> > > >> >> > If I compute the real center from the parametric center, the real > >> >> > center is not within the bounds of the cell. This is the only cell > >> >> > that fails this test. > >> >> > > >> >> > I have attached a small program and cmake file that illustrates the > >> >> > problem. > >> >> > > >> >> > Bill > >> >> > >> >> > >> >> > >> >> -- > >> >> Unpaid intern in BillsBasement at noware dot com > >> >> > >> >> > >> > -- > >> > ___________________________________________ > >> > Andrew J. P. Maclean > >> > > >> > ___________________________________________ > >> > >> > >> > >> -- > >> Unpaid intern in BillsBasement at noware dot com > > > > > > > > > > -- > > Mathieu > > > > -- > 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 berk.geveci at kitware.com Tue Jun 9 09:36:34 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 9 Jun 2015 09:36:34 -0400 Subject: [vtk-developers] Removing support for VS 8 and GCC < 4.1 Message-ID: Hi folks, Sean graciously created a branch that removes support for Visual Studio 8 and GCC < 4.1: https://gitlab.kitware.com/vtk/vtk/merge_requests/38 GCC 4.1 was released in 2006 and VS 9 was released in 2008 (actually late 2007). I believe that this is very reasonable. We removed support for VS 7 and GCC < 3 in 2013 and doing this regularly makes it easier to maintain VTK. Are there any major use cases for keeping these compilers? Unless I hear a good argument against merging this change in the next few weeks, I will go ahead and approve it. Moving forward, we will likely be more aggressive removing support for older compilers. The VTK developer community really wants to leverage new C++ features (C++ 11) and newer library/compiler features (e.g. TBB, OpenMP 3 and 4) etc. We want to get there relatively fast and this will require dropping old compilers more quickly than before. Thanks, -berk -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Tue Jun 9 09:58:50 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 09 Jun 2015 13:58:50 +0000 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: Message-ID: +1. People using those compiler can stick with previous versions of VTK. On Tue, Jun 9, 2015 at 9:37 AM Berk Geveci wrote: > Hi folks, > > Sean graciously created a branch that removes support for Visual Studio 8 > and GCC < 4.1: > > https://gitlab.kitware.com/vtk/vtk/merge_requests/38 > > GCC 4.1 was released in 2006 and VS 9 was released in 2008 (actually late > 2007). I believe that this is very reasonable. We removed support for VS 7 > and GCC < 3 in 2013 and doing this regularly makes it easier to maintain > VTK. > > Are there any major use cases for keeping these compilers? Unless I hear a > good argument against merging this change in the next few weeks, I will go > ahead and approve it. > > Moving forward, we will likely be more aggressive removing support for > older compilers. The VTK developer community really wants to leverage new > C++ features (C++ 11) and newer library/compiler features (e.g. TBB, OpenMP > 3 and 4) etc. We want to get there relatively fast and this will require > dropping old compilers more quickly than before. > > Thanks, > -berk > > _______________________________________________ > 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 lonni.besancon at gmail.com Tue Jun 9 10:45:10 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Tue, 9 Jun 2015 07:45:10 -0700 (MST) Subject: [vtk-developers] VTK for android example: missing vtkRenderingOpenGL2 Message-ID: <1433861110591-5732215.post@n5.nabble.com> Hello, I have, thanks to the help of Tim Thirion who told me to try and the git version of VTK instead of the one available on the website, been able to build VTK for android. Now I'm simply trying to run some examples and I thought the examples provided were a good idea. However, when ccmake-ing the NativeVTK example I stumble across this error: /CMake Error at /Users/lonnibesancon/Desktop/VTK/vtk/CMake/vtkModuleAPI.cmake:120 (message): Requested modules not available: vtkRenderingOpenGL2 Call Stack (most recent call first): /Users/lonnibesancon/Desktop/VTK/buildandroid2/VTKConfig.cmake:67 (vtk_module_config) CMakeLists.txt:8 (find_package)/ Would anyone know why I have this error? I have tried to edit the CMakeCache.txt file before running again cmake . to add VTKRENDERINGOGL2 with ON instead of OFF but I still get the error. Any help would be greatly appreciated. Thanks in advance; -- View this message in context: http://vtk.1045678.n5.nabble.com/VTK-for-android-example-missing-vtkRenderingOpenGL2-tp5732215.html Sent from the VTK - Dev mailing list archive at Nabble.com. From DLRdave at aol.com Tue Jun 9 11:30:48 2015 From: DLRdave at aol.com (David Cole) Date: Tue, 9 Jun 2015 11:30:48 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: Message-ID: Definitely +1. Agree with what Utkarsh said, plus: people writing code should be using modern tools for all sorts of good reasons: performance, security, the tools themselves are just better... I would go so far as to say it's reasonable that the dev/trunk/master branch of a project should only support the two most recent stable compiler releases on any given platform. Even less for dev/trunk/master if there is compelling reason to use a feature only available in the most recent stable release. Cheers for marching forward! David C. On Tue, Jun 9, 2015 at 9:58 AM, Utkarsh Ayachit wrote: > +1. People using those compiler can stick with previous versions of VTK. > > On Tue, Jun 9, 2015 at 9:37 AM Berk Geveci wrote: >> >> Hi folks, >> >> Sean graciously created a branch that removes support for Visual Studio 8 >> and GCC < 4.1: >> >> https://gitlab.kitware.com/vtk/vtk/merge_requests/38 >> >> GCC 4.1 was released in 2006 and VS 9 was released in 2008 (actually late >> 2007). I believe that this is very reasonable. We removed support for VS 7 >> and GCC < 3 in 2013 and doing this regularly makes it easier to maintain >> VTK. >> >> Are there any major use cases for keeping these compilers? Unless I hear a >> good argument against merging this change in the next few weeks, I will go >> ahead and approve it. >> >> Moving forward, we will likely be more aggressive removing support for >> older compilers. The VTK developer community really wants to leverage new >> C++ features (C++ 11) and newer library/compiler features (e.g. TBB, OpenMP >> 3 and 4) etc. We want to get there relatively fast and this will require >> dropping old compilers more quickly than before. >> >> Thanks, >> -berk >> >> _______________________________________________ >> 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 > > > _______________________________________________ > 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 > From utkarsh.ayachit at kitware.com Tue Jun 9 11:33:23 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 09 Jun 2015 15:33:23 +0000 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: Message-ID: > > I would go so far as to say it's reasonable that the dev/trunk/master > branch of a project should only support the two most recent stable > compiler releases on any given platform. Even less for > dev/trunk/master if there is compelling reason to use a feature only > available in the most recent stable release. > +1. At the very least, we should drop OSes and compilers that the OS/compiler provides themselves no longer support e.g. XP, Snow Leopard, etc. Utkarsh -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Tue Jun 9 11:48:10 2015 From: sean at rogue-research.com (Sean McBride) Date: Tue, 9 Jun 2015 11:48:10 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: Message-ID: <20150609154810.842558582@mail.rogue-research.com> On Tue, 9 Jun 2015 11:30:48 -0400, David Cole via vtkusers said: >I would go so far as to say it's reasonable that the dev/trunk/master >branch of a project should only support the two most recent stable >compiler releases on any given platform. Once my conservative patch is merged, I'll do another pass looking at what remaining workarounds exist for old compilers/OSes and post it for review/discussion. 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 Jun 9 17:05:13 2015 From: majcjc at gmail.com (Lin M) Date: Tue, 9 Jun 2015 17:05:13 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> Message-ID: Hi Dr. Thomposon, I have made it support 3D ellipse with function void vtkPatchInterpolation::GenerateEllipseCtrlPt( vtkDataArray* P_i, vtkVector3d center, vtkVector3d majorAxis, vtkVector3d minorAxis, int quadrant) As you can see in the python test, I call this function 4 times for each quadrant to generate the entire ellipse. Since we need to support multiple patches, I think it's better to define a new dataset class for bezier patches as you mentioned before about creating a new vtkControlPoints class that inherits from vtkPoints and allows for an extra coordinate. Another question is that currently the domain of parameter coordinate is [0, 1] for each patch. Do you think it's better to make the domain continuously, namely [0, 0.25] for the first quadrant, [0.25, 0.75] for the second quadrant, etc? Best, Lin On Thu, Jun 4, 2015 at 10:38 AM, David Thompson wrote: > Hi Lin, > > > I have written a helper function to generate control points for > arbitrary ellipse and modified the PatchInterpolation.py test to image test > which contains line, circle and ellipse. > > Excellent! I will do a detailed review of the changes this evening. At a > quick glance, some things that would be nice are: > > 1. Being able to specify ellipses in 3D with vectors (see > Common/DataModel/vtkVector.h) representing the center, major axis, and > minor axis (both direction and length). The minor axis would have to be > orthogonalized using Gram-Shmidt orthonormalization ( > https://en.wikipedia.org/wiki/Gram%E2%80%93Schmidt_process ). > > 2. Being able to return multiple patches so that an entire ellipse could > be generated at once. Then, besides the 3 vectors (center, major, minor), > two angles could be accepted indicating where the patch could start and > stop. This would mean outputting multiple patch points. It will also > require a subdivision algorithm to split a patch at a given parameter value > (which we will use in several other places later this summer). > > In terms of further development, in order to render 2-D splines properly, > we will need a method to evaluate surface normals for patches. More > generally, it would be nice to have an additional evaluation method that > computes the derivative as well as the coordinates of the B?zier patch at > the input points. (Note that the derivative is a vector with the same > dimension as the parameter-space of the patch.) > > > A question about the push the data. I followed the instruction in > https://gitlab.kitware.com/vtk/vtk/blob/master/Documentation/dev/git/data.md, > but I didn't see the message when doing the commit step. > > That's OK, we'll figure it out when it comes time to submit the patch for > review and inclusion into VTK. Hopefully we can do that next week. > > Thanks, > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From casey.goodlett at kitware.com Wed Jun 10 09:16:02 2015 From: casey.goodlett at kitware.com (Casey Goodlett) Date: Wed, 10 Jun 2015 09:16:02 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: <20150609154810.842558582@mail.rogue-research.com> References: <20150609154810.842558582@mail.rogue-research.com> Message-ID: I have recently used visual studio 2005 which would be dropped by this. Is it possible to add a check in the CMakeLists.txt to provide a warning or error if I try to use an unsupported MSVC with VTK 6.3? That way, if I forget about this change, there will be a clear error message instead of something broken due to the removed workarounds. Apologies if thats already in the patch, and I missed it. Thank you On Tue, Jun 9, 2015 at 11:48 AM, Sean McBride wrote: > On Tue, 9 Jun 2015 11:30:48 -0400, David Cole via vtkusers said: > > >I would go so far as to say it's reasonable that the dev/trunk/master > >branch of a project should only support the two most recent stable > >compiler releases on any given platform. > > Once my conservative patch is merged, I'll do another pass looking at what > remaining workarounds exist for old compilers/OSes and post it for > review/discussion. > > 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 > > -- Casey B Goodlett, PhD Technical Leader Kitware, Inc. - North Carolina Office http://www.kitware.com (919) 969-6990 x310 -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Wed Jun 10 09:24:06 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 10 Jun 2015 09:24:06 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: <20150609154810.842558582@mail.rogue-research.com> Message-ID: We could add a logic to check for unsupported or supported compilers. Which do you folks think would be best? As far as I know, when we drop support for a particular compiler, it doesn't mean that the compiler can no longer be used to compile VTK. So if we put a list of supported compilers, we would say that other compilers may work but are not actively supported and tested. If we put a list of unsupported compilers, those should be ones we know do not work... Otherwise the list can get out of hand quickly. On Wed, Jun 10, 2015 at 9:16 AM, Casey Goodlett wrote: > I have recently used visual studio 2005 which would be dropped by this. > > Is it possible to add a check in the CMakeLists.txt to provide a warning > or error if I try to use an unsupported MSVC with VTK 6.3? That way, if I > forget about this change, there will be a clear error message instead of > something broken due to the removed workarounds. > > Apologies if thats already in the patch, and I missed it. > > Thank you > > On Tue, Jun 9, 2015 at 11:48 AM, Sean McBride > wrote: > >> On Tue, 9 Jun 2015 11:30:48 -0400, David Cole via vtkusers said: >> >> >I would go so far as to say it's reasonable that the dev/trunk/master >> >branch of a project should only support the two most recent stable >> >compiler releases on any given platform. >> >> Once my conservative patch is merged, I'll do another pass looking at >> what remaining workarounds exist for old compilers/OSes and post it for >> review/discussion. >> >> 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 >> >> > > > -- > Casey B Goodlett, PhD > Technical Leader > Kitware, Inc. - North Carolina Office > http://www.kitware.com > (919) 969-6990 x310 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From casey.goodlett at kitware.com Wed Jun 10 09:32:17 2015 From: casey.goodlett at kitware.com (Casey Goodlett) Date: Wed, 10 Jun 2015 09:32:17 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: <20150609154810.842558582@mail.rogue-research.com> Message-ID: If I understand this last change correctly, I would start to get non-obvious compile errors on MSVC_VER < 1400 e.g. in vtkTypedArray or one of the other places a workaround has been dropped. My preference is then for a checked list of unsupported compilers where we know changes have been made to drop workarounds. -------------- next part -------------- An HTML attachment was scrubbed... URL: From casey.goodlett at kitware.com Wed Jun 10 09:34:50 2015 From: casey.goodlett at kitware.com (Casey Goodlett) Date: Wed, 10 Jun 2015 09:34:50 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: <20150609154810.842558582@mail.rogue-research.com> Message-ID: On Wed, Jun 10, 2015 at 9:32 AM, Casey Goodlett wrote: > > My preference is then for a checked list of unsupported compilers where we > know changes have been made to drop workarounds. > and in case only some features or modules are broken (e.g. python wrapping) it could be a warning for unsupported compilers rather than an error. -- Casey B Goodlett, PhD Technical Leader Kitware, Inc. - North Carolina Office http://www.kitware.com (919) 969-6990 x310 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Jun 10 09:43:09 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 10 Jun 2015 09:43:09 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: <20150609154810.842558582@mail.rogue-research.com> Message-ID: <20150610134309.945934349@mail.rogue-research.com> On Wed, 10 Jun 2015 09:32:17 -0400, Casey Goodlett said: >If I understand this last change correctly, I would start to get >non-obvious compile errors on MSVC_VER < 1400 e.g. in vtkTypedArray or one >of the other places a workaround has been dropped. Indeed. The idea of my patch is to remove old crud and workarounds. I'm honestly curious: why are you using a 10 year old IDE? >My preference is then for a checked list of unsupported compilers where we >know changes have been made to drop workarounds. I could add that by means of: #if MSVC_VER < xxx #error ... 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 ken.martin at kitware.com Wed Jun 10 09:45:24 2015 From: ken.martin at kitware.com (Ken Martin) Date: Wed, 10 Jun 2015 09:45:24 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: <20150610134309.945934349@mail.rogue-research.com> References: <20150609154810.842558582@mail.rogue-research.com> <20150610134309.945934349@mail.rogue-research.com> Message-ID: >>> I'm honestly curious: why are you using a 10 year old IDE? So much that ^ 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. -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Sean McBride Sent: Wednesday, June 10, 2015 9:43 AM To: Casey Goodlett; Berk Geveci Cc: VTK Developers Subject: Re: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 On Wed, 10 Jun 2015 09:32:17 -0400, Casey Goodlett said: >If I understand this last change correctly, I would start to get >non-obvious compile errors on MSVC_VER < 1400 e.g. in vtkTypedArray or >one of the other places a workaround has been dropped. Indeed. The idea of my patch is to remove old crud and workarounds. I'm honestly curious: why are you using a 10 year old IDE? >My preference is then for a checked list of unsupported compilers where >we know changes have been made to drop workarounds. I could add that by means of: #if MSVC_VER < xxx #error ... 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 casey.goodlett at kitware.com Wed Jun 10 09:49:38 2015 From: casey.goodlett at kitware.com (Casey Goodlett) Date: Wed, 10 Jun 2015 09:49:38 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: <20150610134309.945934349@mail.rogue-research.com> References: <20150609154810.842558582@mail.rogue-research.com> <20150610134309.945934349@mail.rogue-research.com> Message-ID: On Wed, Jun 10, 2015 at 9:43 AM, Sean McBride wrote: > > I'm honestly curious: why are you using a 10 year old IDE? > > Not because I want to :-) I need to move and am working on it, but it has not happened yet. > >My preference is then for a checked list of unsupported compilers where we > >know changes have been made to drop workarounds. > > I could add that by means of: > > #if MSVC_VER < xxx > #error ... That would be fine with me as it would provide a clear error message -- Casey B Goodlett, PhD Technical Leader Kitware, Inc. - North Carolina Office http://www.kitware.com (919) 969-6990 x310 -------------- next part -------------- An HTML attachment was scrubbed... URL: From karasevpa at gmail.com Wed Jun 10 10:07:33 2015 From: karasevpa at gmail.com (Peter Karasev) Date: Wed, 10 Jun 2015 07:07:33 -0700 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: Message-ID: +1 for the aggressive point of view. C++11 makes life so much easier it's practically criminal to make VTK users suffer due to legacy support. Peter Karasev On Jun 9, 2015 11:30 AM, "David Cole via vtk-developers" < vtk-developers at vtk.org> wrote: > Definitely +1. > > Agree with what Utkarsh said, plus: people writing code should be > using modern tools for all sorts of good reasons: performance, > security, the tools themselves are just better... > > I would go so far as to say it's reasonable that the dev/trunk/master > branch of a project should only support the two most recent stable > compiler releases on any given platform. Even less for > dev/trunk/master if there is compelling reason to use a feature only > available in the most recent stable release. > > > Cheers for marching forward! > David C. > > > > On Tue, Jun 9, 2015 at 9:58 AM, Utkarsh Ayachit > wrote: > > +1. People using those compiler can stick with previous versions of VTK. > > > > On Tue, Jun 9, 2015 at 9:37 AM Berk Geveci > wrote: > >> > >> Hi folks, > >> > >> Sean graciously created a branch that removes support for Visual Studio > 8 > >> and GCC < 4.1: > >> > >> https://gitlab.kitware.com/vtk/vtk/merge_requests/38 > >> > >> GCC 4.1 was released in 2006 and VS 9 was released in 2008 (actually > late > >> 2007). I believe that this is very reasonable. We removed support for > VS 7 > >> and GCC < 3 in 2013 and doing this regularly makes it easier to maintain > >> VTK. > >> > >> Are there any major use cases for keeping these compilers? Unless I > hear a > >> good argument against merging this change in the next few weeks, I will > go > >> ahead and approve it. > >> > >> Moving forward, we will likely be more aggressive removing support for > >> older compilers. The VTK developer community really wants to leverage > new > >> C++ features (C++ 11) and newer library/compiler features (e.g. TBB, > OpenMP > >> 3 and 4) etc. We want to get there relatively fast and this will require > >> dropping old compilers more quickly than before. > >> > >> Thanks, > >> -berk > >> > >> _______________________________________________ > >> 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 > > > > > > _______________________________________________ > > 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 > > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 Jun 10 10:30:43 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Wed, 10 Jun 2015 10:30:43 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: Message-ID: There may be customers that have products relying on older compilers. Switching compilers is not always an easy process since they must port their own code to the new compilers. I think we should be conservative and only remove compilers when they get in the way of progress of the vtk code base. My 2 cents. On Wed, Jun 10, 2015 at 10:07 AM, Peter Karasev wrote: > +1 for the aggressive point of view. C++11 makes life so much easier it's > practically criminal to make VTK users suffer due to legacy support. > > Peter Karasev > > On Jun 9, 2015 11:30 AM, "David Cole via vtk-developers" > wrote: >> >> Definitely +1. >> >> Agree with what Utkarsh said, plus: people writing code should be >> using modern tools for all sorts of good reasons: performance, >> security, the tools themselves are just better... >> >> I would go so far as to say it's reasonable that the dev/trunk/master >> branch of a project should only support the two most recent stable >> compiler releases on any given platform. Even less for >> dev/trunk/master if there is compelling reason to use a feature only >> available in the most recent stable release. >> >> >> Cheers for marching forward! >> David C. >> >> >> >> On Tue, Jun 9, 2015 at 9:58 AM, Utkarsh Ayachit >> wrote: >> > +1. People using those compiler can stick with previous versions of VTK. >> > >> > On Tue, Jun 9, 2015 at 9:37 AM Berk Geveci >> > wrote: >> >> >> >> Hi folks, >> >> >> >> Sean graciously created a branch that removes support for Visual Studio >> >> 8 >> >> and GCC < 4.1: >> >> >> >> https://gitlab.kitware.com/vtk/vtk/merge_requests/38 >> >> >> >> GCC 4.1 was released in 2006 and VS 9 was released in 2008 (actually >> >> late >> >> 2007). I believe that this is very reasonable. We removed support for >> >> VS 7 >> >> and GCC < 3 in 2013 and doing this regularly makes it easier to >> >> maintain >> >> VTK. >> >> >> >> Are there any major use cases for keeping these compilers? Unless I >> >> hear a >> >> good argument against merging this change in the next few weeks, I will >> >> go >> >> ahead and approve it. >> >> >> >> Moving forward, we will likely be more aggressive removing support for >> >> older compilers. The VTK developer community really wants to leverage >> >> new >> >> C++ features (C++ 11) and newer library/compiler features (e.g. TBB, >> >> OpenMP >> >> 3 and 4) etc. We want to get there relatively fast and this will >> >> require >> >> dropping old compilers more quickly than before. >> >> >> >> Thanks, >> >> -berk >> >> >> >> _______________________________________________ >> >> 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 >> > >> > >> > _______________________________________________ >> > 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 >> > >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the 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 > > -- Unpaid intern in BillsBasement at noware dot com From dave.demarle at kitware.com Wed Jun 10 10:51:55 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 10 Jun 2015 10:51:55 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: Message-ID: That took longer than expected Bill. :) Thanks for bringing up the counter argument Bill. Casey's pain demonstrates your point. Despite that my vote is for getting rid of old compilers sooner rather than later. Old compilers are a drag on both innovation and maintenance. Whatever we do I think the we need to clearly communicate what compilers we really are trying to support. This discussion and earlier ones on the mailing list help. The cmake macros people have discussed will help too. In practice the dashboards submitters define the set of compilers that people can expect to "just work". That set should be introspected and published automatically and expanded. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Wed Jun 10 10:59:37 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Wed, 10 Jun 2015 10:59:37 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: Message-ID: We could also start putting a "tested against ?" statement in the release notes for posterity. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Jun 10, 2015 at 10:51 AM, David E DeMarle wrote: > That took longer than expected Bill. :) > > Thanks for bringing up the counter argument Bill. Casey's pain > demonstrates your point. > > Despite that my vote is for getting rid of old compilers sooner rather > than later. Old compilers are a drag on both innovation and maintenance. > > Whatever we do I think the we need to clearly communicate what compilers > we really are trying to support. This discussion and earlier ones on the > mailing list help. The cmake macros people have discussed will help too. In > practice the dashboards submitters define the set of compilers that people > can expect to "just work". That set should be introspected and published > automatically and expanded. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Jun 10 11:01:02 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 10 Jun 2015 11:01:02 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: Message-ID: <20150610150102.1362641435@mail.rogue-research.com> On Wed, 10 Jun 2015 10:30:43 -0400, Bill Lorensen said: >There may be customers that have products relying on older compilers. >Switching compilers is not always an easy process since they must port >their own code to the new compilers. > >I think we should be conservative and only remove compilers when they >get in the way of progress of the vtk code base. I fully agree. It's just a question of degree. What's 'conservative'? With my patch VTK's minimums will be: - GCC 4.1 - released in 2006 - VS 9 - released in late 2007 To me, that's conservative. Do you agree? 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 berk.geveci at kitware.com Wed Jun 10 11:31:37 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 10 Jun 2015 11:31:37 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: Message-ID: Maybe one way of addressing this issue would be to keep two versions maintained for a longer period? For example, we could commit to maintaining (minor bug fixes and limited testing only) VTK 6 for 3 years after we release VTK 7... That way customer that are stuck on old compiler can benefit from bug fixes and testing longer. If they want newer features, they would have to update. Given that we are likely to move to VTK 7 and then 8 pretty quickly, even longer than 3 years may be warranted. I would argue for aiming for (mostly) C++ 11 by VTK 8, probably around late 2016. -berk On Wed, Jun 10, 2015 at 10:30 AM, Bill Lorensen wrote: > There may be customers that have products relying on older compilers. > Switching compilers is not always an easy process since they must port > their own code to the new compilers. > > I think we should be conservative and only remove compilers when they > get in the way of progress of the vtk code base. > > My 2 cents. > > On Wed, Jun 10, 2015 at 10:07 AM, Peter Karasev > wrote: > > +1 for the aggressive point of view. C++11 makes life so much easier it's > > practically criminal to make VTK users suffer due to legacy support. > > > > Peter Karasev > > > > On Jun 9, 2015 11:30 AM, "David Cole via vtk-developers" > > wrote: > >> > >> Definitely +1. > >> > >> Agree with what Utkarsh said, plus: people writing code should be > >> using modern tools for all sorts of good reasons: performance, > >> security, the tools themselves are just better... > >> > >> I would go so far as to say it's reasonable that the dev/trunk/master > >> branch of a project should only support the two most recent stable > >> compiler releases on any given platform. Even less for > >> dev/trunk/master if there is compelling reason to use a feature only > >> available in the most recent stable release. > >> > >> > >> Cheers for marching forward! > >> David C. > >> > >> > >> > >> On Tue, Jun 9, 2015 at 9:58 AM, Utkarsh Ayachit > >> wrote: > >> > +1. People using those compiler can stick with previous versions of > VTK. > >> > > >> > On Tue, Jun 9, 2015 at 9:37 AM Berk Geveci > >> > wrote: > >> >> > >> >> Hi folks, > >> >> > >> >> Sean graciously created a branch that removes support for Visual > Studio > >> >> 8 > >> >> and GCC < 4.1: > >> >> > >> >> https://gitlab.kitware.com/vtk/vtk/merge_requests/38 > >> >> > >> >> GCC 4.1 was released in 2006 and VS 9 was released in 2008 (actually > >> >> late > >> >> 2007). I believe that this is very reasonable. We removed support for > >> >> VS 7 > >> >> and GCC < 3 in 2013 and doing this regularly makes it easier to > >> >> maintain > >> >> VTK. > >> >> > >> >> Are there any major use cases for keeping these compilers? Unless I > >> >> hear a > >> >> good argument against merging this change in the next few weeks, I > will > >> >> go > >> >> ahead and approve it. > >> >> > >> >> Moving forward, we will likely be more aggressive removing support > for > >> >> older compilers. The VTK developer community really wants to leverage > >> >> new > >> >> C++ features (C++ 11) and newer library/compiler features (e.g. TBB, > >> >> OpenMP > >> >> 3 and 4) etc. We want to get there relatively fast and this will > >> >> require > >> >> dropping old compilers more quickly than before. > >> >> > >> >> Thanks, > >> >> -berk > >> >> > >> >> _______________________________________________ > >> >> 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 > >> > > >> > > >> > _______________________________________________ > >> > 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 > >> > > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the 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 > > > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From DLRdave at aol.com Wed Jun 10 11:40:07 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 10 Jun 2015 11:40:07 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: <20150609154810.842558582@mail.rogue-research.com> Message-ID: I think both an official list of supported compilers, and an official list of "known problems with" compilers, perhaps even explicitly encoded into the CMakeLists.txt file, would be a fantastic addition to VTK. You still ought to be able to TRY to compile it with any compiler you want. After all, you may have a fork on github (or wherever) that maintains active support of your own on the side.... But having official lists of both known supported compilers and known problem compilers would be an excellent resource to have. D On Wed, Jun 10, 2015 at 9:24 AM, Berk Geveci wrote: > We could add a logic to check for unsupported or supported compilers. Which > do you folks think would be best? As far as I know, when we drop support for > a particular compiler, it doesn't mean that the compiler can no longer be > used to compile VTK. So if we put a list of supported compilers, we would > say that other compilers may work but are not actively supported and tested. > If we put a list of unsupported compilers, those should be ones we know do > not work... Otherwise the list can get out of hand quickly. > > > On Wed, Jun 10, 2015 at 9:16 AM, Casey Goodlett > wrote: >> >> I have recently used visual studio 2005 which would be dropped by this. >> >> Is it possible to add a check in the CMakeLists.txt to provide a warning >> or error if I try to use an unsupported MSVC with VTK 6.3? That way, if I >> forget about this change, there will be a clear error message instead of >> something broken due to the removed workarounds. >> >> Apologies if thats already in the patch, and I missed it. >> >> Thank you >> >> On Tue, Jun 9, 2015 at 11:48 AM, Sean McBride >> wrote: >>> >>> On Tue, 9 Jun 2015 11:30:48 -0400, David Cole via vtkusers said: >>> >>> >I would go so far as to say it's reasonable that the dev/trunk/master >>> >branch of a project should only support the two most recent stable >>> >compiler releases on any given platform. >>> >>> Once my conservative patch is merged, I'll do another pass looking at >>> what remaining workarounds exist for old compilers/OSes and post it for >>> review/discussion. >>> >>> 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 >>> >> >> >> >> -- >> Casey B Goodlett, PhD >> Technical Leader >> Kitware, Inc. - North Carolina Office >> http://www.kitware.com >> (919) 969-6990 x310 > > From DLRdave at aol.com Wed Jun 10 11:47:23 2015 From: DLRdave at aol.com (David Cole) Date: Wed, 10 Jun 2015 11:47:23 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: Message-ID: I agree, that did take longer than expected, Bill... Golfing good already up there this year...? ;-) Customers having products relying on older compilers should probably also be relying on older VTK versions. Just sayin'... As to Casey's pain, I'm curious whether it's a hobby project, or a real live academic/business/government project. Whatever it is, I know I personally don't want software built by VS 2005 on my 2015 machine. Surprised that anybody else does either. (Having said that, I probably already do have software like that installed and don't even know it....) ;-) Good discussion -- I like this thread.... D On Wed, Jun 10, 2015 at 10:51 AM, David E DeMarle wrote: > That took longer than expected Bill. :) > > Thanks for bringing up the counter argument Bill. Casey's pain demonstrates > your point. > > Despite that my vote is for getting rid of old compilers sooner rather than > later. Old compilers are a drag on both innovation and maintenance. > > Whatever we do I think the we need to clearly communicate what compilers we > really are trying to support. This discussion and earlier ones on the > mailing list help. The cmake macros people have discussed will help too. In > practice the dashboards submitters define the set of compilers that people > can expect to "just work". That set should be introspected and published > automatically and expanded. > > > _______________________________________________ > 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 > From casey.goodlett at kitware.com Wed Jun 10 12:10:01 2015 From: casey.goodlett at kitware.com (Casey Goodlett) Date: Wed, 10 Jun 2015 12:10:01 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: Message-ID: On Wed, Jun 10, 2015 at 11:47 AM, David Cole via vtk-developers < vtk-developers at vtk.org> wrote: > As to Casey's pain, I'm curious whether it's a hobby project, or a > real live academic/business/government project. Whatever it is, I know > I personally don't want software built by VS 2005 on my 2015 machine. > Surprised that anybody else does either. (Having said that, I probably > already do have software like that installed and don't even know > it....) ;-) > To be clear I'm not asking for support for this version. Just humbly requesting an obvious warning or error since in this case we know exactly the compiler versions we're dropping. AFAIK official python binaries are still built with VS 2008 which is not that different (one iteration). I find those binaries quite handy :-) -- Casey -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Wed Jun 10 12:14:40 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Wed, 10 Jun 2015 10:14:40 -0600 Subject: [vtk-developers] Long-term support for previous VTK release Message-ID: Hi Berk, I'd love to see long-term support for older versions of VTK. It could be done without placing any burden on anyone but the people who need it, if a couple simple rules are followed: 1) When we move to VTK 7, an LTS branch should be created for VTK 6, and this branch should remain open for X years. Merge requests etc. for this branch should be handled exactly as for the master branch. We could have a list of developers willing to review patches for this branch on the wiki (I'd certainly be willing to do so). 2) There should be no expectation of binary releases from an LTS branch, that would just create extra work for Kitware and would probably end up slowing down the whole process. 3) There would have to be a section of the dashboard available for each LTS branch for nightly testing at least. Merges into the LTS branch should be rare enough that @home testing would be unnecessary. I realize that this might entail some gitlab customization. I was not happy with how fast VTK 5 was dropped. If there had been some way that I could have helped to support it, then I would have. Here in academia, it's very common for projects to be put on hold for two or three years due to temporary lack of funding, or because a lab goes for a couple years without a grad student who has the necessary expertise. So if a grad student gets stuck with a project that requires a version of VTK that won't work on a modern system, it becomes very difficult to even get started. - David On Wed, Jun 10, 2015 at 9:31 AM, Berk Geveci wrote: > Maybe one way of addressing this issue would be to keep two versions > maintained for a longer period? For example, we could commit to maintaining > (minor bug fixes and limited testing only) VTK 6 for 3 years after we > release VTK 7... That way customer that are stuck on old compiler can > benefit from bug fixes and testing longer. If they want newer features, > they would have to update. Given that we are likely to move to VTK 7 and > then 8 pretty quickly, even longer than 3 years may be warranted. > > I would argue for aiming for (mostly) C++ 11 by VTK 8, probably around > late 2016. > > -berk > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joaorobertojr88 at gmail.com Wed Jun 10 13:16:30 2015 From: joaorobertojr88 at gmail.com (joaoroberto88) Date: Wed, 10 Jun 2015 10:16:30 -0700 (MST) Subject: [vtk-developers] Actor color gradient Message-ID: <1433956590919-5732275.post@n5.nabble.com> Hi Devs, I would like to apply a color gradient on a vtkActor. I've defined scalar values to each vtkCell (by following this example http://www.vtk.org/Wiki/VTK/Examples/Cxx/PolyData/ColorCellsWithRGB). However, the color transition isn't as I want. Please take a look in the attached screenshot. Also below is a piece of code responsible for rendering the image. What can I do to have it done? Thanks, Joao. // Mesh rendering vtkSmartPointer gridPolyData = mesh->getGrid(); vtkSmartPointer gridMapper = vtkSmartPointer::New(); // gridMapper->InterpolateScalarsBeforeMappingOff(); // Didn't take effect on color gradient gridMapper->SetInputData(gridPolyData); vtkSmartPointer actor = vtkSmartPointer::New(); actor->SetMapper(gridMapper); // actor->GetProperty()->SetColor(1, 1, 1); actor->GetProperty()->EdgeVisibilityOff(); renderer = vtkSmartPointer::New(); renderer->SetBackground(1, 1, 1); // White renderer->AddActor(actor); renderWindow->AddRenderer(renderer); // QVTKWidget class method this->SetRenderWindow(renderWindow); renderWindow->Render(); -- View this message in context: http://vtk.1045678.n5.nabble.com/Actor-color-gradient-tp5732275.html Sent from the VTK - Dev mailing list archive at Nabble.com. From david.thompson at kitware.com Wed Jun 10 14:39:33 2015 From: david.thompson at kitware.com (David Thompson) Date: Wed, 10 Jun 2015 14:39:33 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> Message-ID: Hi Lin, > I have made it support 3D ellipse with function ... Great! > As you can see in the python test, I call this function 4 times for each quadrant to generate the entire ellipse. Since we need to support multiple patches, I think it's better to define a new dataset class for bezier patches as you mentioned before about creating a new vtkControlPoints class that inherits from vtkPoints and allows for an extra coordinate. Rather than create new dataset types, I would like to use existing datatypes to store the data and make an adaptor to iterate over them. That way existing pipelines could modify scalar values defined on control points (and perhaps even patches). For instance, B-splines could be represented as a vtkStructuredGrid whose FieldData contains a special knot array (special in the sense that the array must be of the proper size and with a fixed name like "_vtkKnotVector"). The adaptor would take a vtkDataObject as input and provide iterator-style access to each patch defined by the dataset. Specific subclasses of the adaptor would be B-splines (which expect the vtkDataObject to be a vtkStructuredGrid) or T-splines (which might expect a vtkUniformGridAMR) or even point-based splines (PB-splines as defined in Sederberg's T-spline paper, which could expect any dataset derived vtkPointSet). class vtkBezierPatchAdaptor : public vtkObject { public: virtual void SetControlPointData(vtkDataObject* controlPointData); vtkGetObjectMacro(vtkDataObject,ControlPointData); // Methods to iterate over patches: virtual void Begin() = 0; virtual bool IsAtEnd() = 0; virtual bool GoToPatch(vtkIdType patchId) = 0; // random access iteration virtual bool Next() = 0; // Methods to access the current patch: virtual int GetPatchDimension() const = 0; virtual void GetPatchShape() const = 0; // returns VTK_TRIANGLE/VTK_QUAD when PatchDimension==2, // returns VTK_HEXAHEDRON/VTK_TETRA when PatchDimension==3 virtual void GetPatchDegree(int* degreeOut) const = 0; virtual void GetPatchParameterRange(double* paramsOut) const = 0; virtual void GetPatchPoints(vtkPoints* pointsOut) const = 0; // Some helper methods that would make Python wrappings usable: int GetPatchDegree(int dim) const { std::vector degree(this->GetPatchDimension()); this->GetPatchDegree(°ree[0]); return degree[dim]; } void GetPatchParameterRange(int dim, double paramRange[2]) { std::vector range(2 * this->GetPatchDimension()); this->GetPatchDegree(&range[0]); paramRange[0] = [2 * dim]; paramRange[1] = [2 * dim + 1]; } protected: vtkDataObject* ControlPointData; }; The B-spline subclass could then iterate over patches by keeping a current "cell ID," which would be incremented by calling Next(). When asked for the *patch* points (not the input points), the adaptor would create a vtkMappedDataArray (see http://www.vtk.org/Wiki/VTK/InSituDataStructure for more information) that did not copy control point coordinates from its ControlPointData->GetPoints() but instead used the implicit connectivity to provide access to underlying B-spline points. For example, consider the simple case of a rectangular B-spline with degree 1 (bi-linear). We might be given a 5x6 grid of control points as input and asked to iterate over all the patches. Each patch is simply a quadrilateral, and there are (5-1)*(6-1) = 20 of them. adaptor->Begin(); // would initialize an internal "cell ID" to 0 adaptor->IsAtEnd(); // would return false for "cell ID" values in [0,19] and true otherwise. adaptor->GetPatchDimension(); // would return 2 adaptor->GetPatchShape(); // would return VTK_QUAD adaptor->GetPatchDegree(degreeOut); // would populate degreeOut with [1,1] adaptor->GetPatchPoints(pointsOut); // would populate pointsOut with a vtkMappedDataArray. The vtkMappedDataArray would report having 4 tuples (one for each corner of the quad... when the degree is higher, is would report the product of (degreeOut[i]+1) for all i in GetPatchDimension()). The actual points reported would depend on the "cell ID" in the adaptor. I have not figured out yet how the "w" homogeneous coordinate would work with vtkPoints. A different adaptor API might work better (keeping the "w" coordinate separate from the other points). > Another question is that currently the domain of parameter coordinate is [0, 1] for each patch. Do you think it's better to make the domain continuously, namely [0, 0.25] for the first quadrant, [0.25, 0.75] for the second quadrant, etc? If we focus on the B-spline adaptor above, we get that for free since the returned knot vector could be normalized to the range [0,1]. David From berk.geveci at kitware.com Wed Jun 10 20:16:46 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 10 Jun 2015 20:16:46 -0400 Subject: [vtk-developers] Long-term support for previous VTK release In-Reply-To: References: Message-ID: Hi David, Sounds good. We had a discussion about testing at Kitware. With the new infrastructure we have in place, we won't need nightly testing. We can just test when changes are made to master. CDash now supports showing latest dashboard results every day, no matter how long ago they were run. This will allow us to throw as many dashboard systems as we use on the latest version to older versions, since changes will happen rarely... We need to figure out the details of how we will do this. It is likely VTK 8 and 9 will come fairly quickly after 7 and they are very likely to bring fairly big changes both in terms of API as well as supported compilers. So my current thinking is to have VTK 6 live for several years (3-5?) while 7, 8 and 9 would come and go fairly quickly. So anyone who doesn't want to ride this new wave of changes could stick to 6 but those that jump on 7 or later will have to be willing to move forward... Does this make sense? Alternative suggestions are welcome. With the caveat that maintaining multiple versions of several years would be challenging for the community. Best, -berk On Wed, Jun 10, 2015 at 12:14 PM, David Gobbi wrote: > Hi Berk, > > I'd love to see long-term support for older versions of VTK. It could be > done without placing any burden on anyone but the people who need it, if a > couple simple rules are followed: > > 1) When we move to VTK 7, an LTS branch should be created for VTK 6, and > this branch should remain open for X years. Merge requests etc. for this > branch should be handled exactly as for the master branch. We could have a > list of developers willing to review patches for this branch on the wiki > (I'd certainly be willing to do so). > > 2) There should be no expectation of binary releases from an LTS branch, > that would just create extra work for Kitware and would probably end up > slowing down the whole process. > > 3) There would have to be a section of the dashboard available for each > LTS branch for nightly testing at least. Merges into the LTS branch should > be rare enough that @home testing would be unnecessary. I realize that > this might entail some gitlab customization. > > I was not happy with how fast VTK 5 was dropped. If there had been some > way that I could have helped to support it, then I would have. > > Here in academia, it's very common for projects to be put on hold for two > or three years due to temporary lack of funding, or because a lab goes for > a couple years without a grad student who has the necessary expertise. So > if a grad student gets stuck with a project that requires a version of VTK > that won't work on a modern system, it becomes very difficult to even get > started. > > - David > > > On Wed, Jun 10, 2015 at 9:31 AM, Berk Geveci > wrote: > >> Maybe one way of addressing this issue would be to keep two versions >> maintained for a longer period? For example, we could commit to maintaining >> (minor bug fixes and limited testing only) VTK 6 for 3 years after we >> release VTK 7... That way customer that are stuck on old compiler can >> benefit from bug fixes and testing longer. If they want newer features, >> they would have to update. Given that we are likely to move to VTK 7 and >> then 8 pretty quickly, even longer than 3 years may be warranted. >> >> I would argue for aiming for (mostly) C++ 11 by VTK 8, probably around >> late 2016. >> >> -berk >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dave.demarle at kitware.com Thu Jun 11 10:57:38 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Thu, 11 Jun 2015 10:57:38 -0400 Subject: [vtk-developers] [vtkusers] Long-term support for previous VTK release In-Reply-To: References: Message-ID: 5.10 was the first time we attempted any kind of long term support ( http://public.kitware.com/pipermail/vtk-developers/2013-October/029905.html) eh? Curiously, we just turned off the 5.10 branch dashboard testers last week. We did so to streamline the dashboard presentation and to repurpose the underused hardware cycles for buildbot tests. My thoughts on that first attempt: 1) Despite annoying people who wanted bug fixes and improvements merged, I personally agreed with the rule of only allowing os/compiler update fixes. 2) It was wasteful to dedicate machines to testing (poorly since there were few of them) the branch nightly - Buildbot and CDash updates should improve testing (2) this time around. 3) I did not like how opaque the contributions process for new patches was. 4) I did not like the one person bottleneck to getting contributions merged (the lumbering troll guarding the branch) 5) I did not like manually keeping track of topics to merge and ensuring that were clean - gitlab should should help with improving the contribution process (3,4,5). In summary, once we set up buildbot, cdash and gitlab to allow it, I think we'll be much more successful this time around. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 On Wed, Jun 10, 2015 at 8:16 PM, Berk Geveci wrote: > Hi David, > > Sounds good. We had a discussion about testing at Kitware. With the new > infrastructure we have in place, we won't need nightly testing. We can just > test when changes are made to master. CDash now supports showing latest > dashboard results every day, no matter how long ago they were run. This > will allow us to throw as many dashboard systems as we use on the latest > version to older versions, since changes will happen rarely... > > We need to figure out the details of how we will do this. It is likely VTK > 8 and 9 will come fairly quickly after 7 and they are very likely to bring > fairly big changes both in terms of API as well as supported compilers. So > my current thinking is to have VTK 6 live for several years (3-5?) while 7, > 8 and 9 would come and go fairly quickly. So anyone who doesn't want to > ride this new wave of changes could stick to 6 but those that jump on 7 or > later will have to be willing to move forward... Does this make sense? > Alternative suggestions are welcome. With the caveat that maintaining > multiple versions of several years would be challenging for the community. > > Best, > -berk > > On Wed, Jun 10, 2015 at 12:14 PM, David Gobbi > wrote: > >> Hi Berk, >> >> I'd love to see long-term support for older versions of VTK. It could be >> done without placing any burden on anyone but the people who need it, if a >> couple simple rules are followed: >> >> 1) When we move to VTK 7, an LTS branch should be created for VTK 6, and >> this branch should remain open for X years. Merge requests etc. for this >> branch should be handled exactly as for the master branch. We could have a >> list of developers willing to review patches for this branch on the wiki >> (I'd certainly be willing to do so). >> >> 2) There should be no expectation of binary releases from an LTS branch, >> that would just create extra work for Kitware and would probably end up >> slowing down the whole process. >> >> 3) There would have to be a section of the dashboard available for each >> LTS branch for nightly testing at least. Merges into the LTS branch should >> be rare enough that @home testing would be unnecessary. I realize that >> this might entail some gitlab customization. >> >> I was not happy with how fast VTK 5 was dropped. If there had been some >> way that I could have helped to support it, then I would have. >> >> Here in academia, it's very common for projects to be put on hold for two >> or three years due to temporary lack of funding, or because a lab goes for >> a couple years without a grad student who has the necessary expertise. So >> if a grad student gets stuck with a project that requires a version of VTK >> that won't work on a modern system, it becomes very difficult to even get >> started. >> >> - David >> >> >> On Wed, Jun 10, 2015 at 9:31 AM, Berk Geveci >> wrote: >> >>> Maybe one way of addressing this issue would be to keep two versions >>> maintained for a longer period? For example, we could commit to maintaining >>> (minor bug fixes and limited testing only) VTK 6 for 3 years after we >>> release VTK 7... That way customer that are stuck on old compiler can >>> benefit from bug fixes and testing longer. If they want newer features, >>> they would have to update. Given that we are likely to move to VTK 7 and >>> then 8 pretty quickly, even longer than 3 years may be warranted. >>> >>> I would argue for aiming for (mostly) C++ 11 by VTK 8, probably around >>> late 2016. >>> >>> -berk >>> >> > > _______________________________________________ > 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 berk.geveci at kitware.com Thu Jun 11 11:05:09 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 11 Jun 2015 11:05:09 -0400 Subject: [vtk-developers] [vtkusers] Long-term support for previous VTK release In-Reply-To: References: Message-ID: Thanks for the feedback Dave. I think that we would allow for more than os/compiler fixes if we will maintain VTK 6 for several years. We would allow for general bug fixes also. My hope would be that those in the community that need VTK 6 would help out significantly. It sounds like David is volunteering to help maintain such a version. I am sure that there would be others also. The main challenge I can think of is how we will keep track of what was merged into VTK 6. Maybe we need to ++ our processes to integrate the issue tracker more tightly, the way ParaView does. This would enable us to keep track of things better... I'd like to hear some feedback and suggestions on this. -berk On Thu, Jun 11, 2015 at 10:57 AM, David E DeMarle wrote: > 5.10 was the first time we attempted any kind of long term support ( > http://public.kitware.com/pipermail/vtk-developers/2013-October/029905.html) > eh? Curiously, we just turned off the 5.10 branch dashboard testers last > week. We did so to streamline the dashboard presentation and to repurpose > the underused hardware cycles for buildbot tests. > > My thoughts on that first attempt: > 1) Despite annoying people who wanted bug fixes and improvements merged, I > personally agreed with the rule of only allowing os/compiler update fixes. > > 2) It was wasteful to dedicate machines to testing (poorly since there > were few of them) the branch nightly > - Buildbot and CDash updates should improve testing (2) this time around. > > 3) I did not like how opaque the contributions process for new patches was. > 4) I did not like the one person bottleneck to getting contributions > merged (the lumbering troll guarding the branch) > 5) I did not like manually keeping track of topics to merge and ensuring > that were clean > - gitlab should should help with improving the contribution process > (3,4,5). > > In summary, once we set up buildbot, cdash and gitlab to allow it, I think > we'll be much more successful this time around. > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > > On Wed, Jun 10, 2015 at 8:16 PM, Berk Geveci > wrote: > >> Hi David, >> >> Sounds good. We had a discussion about testing at Kitware. With the new >> infrastructure we have in place, we won't need nightly testing. We can just >> test when changes are made to master. CDash now supports showing latest >> dashboard results every day, no matter how long ago they were run. This >> will allow us to throw as many dashboard systems as we use on the latest >> version to older versions, since changes will happen rarely... >> >> We need to figure out the details of how we will do this. It is likely >> VTK 8 and 9 will come fairly quickly after 7 and they are very likely to >> bring fairly big changes both in terms of API as well as supported >> compilers. So my current thinking is to have VTK 6 live for several years >> (3-5?) while 7, 8 and 9 would come and go fairly quickly. So anyone who >> doesn't want to ride this new wave of changes could stick to 6 but those >> that jump on 7 or later will have to be willing to move forward... Does >> this make sense? Alternative suggestions are welcome. With the caveat that >> maintaining multiple versions of several years would be challenging for the >> community. >> >> Best, >> -berk >> >> On Wed, Jun 10, 2015 at 12:14 PM, David Gobbi >> wrote: >> >>> Hi Berk, >>> >>> I'd love to see long-term support for older versions of VTK. It could >>> be done without placing any burden on anyone but the people who need it, if >>> a couple simple rules are followed: >>> >>> 1) When we move to VTK 7, an LTS branch should be created for VTK 6, and >>> this branch should remain open for X years. Merge requests etc. for this >>> branch should be handled exactly as for the master branch. We could have a >>> list of developers willing to review patches for this branch on the wiki >>> (I'd certainly be willing to do so). >>> >>> 2) There should be no expectation of binary releases from an LTS branch, >>> that would just create extra work for Kitware and would probably end up >>> slowing down the whole process. >>> >>> 3) There would have to be a section of the dashboard available for each >>> LTS branch for nightly testing at least. Merges into the LTS branch should >>> be rare enough that @home testing would be unnecessary. I realize that >>> this might entail some gitlab customization. >>> >>> I was not happy with how fast VTK 5 was dropped. If there had been some >>> way that I could have helped to support it, then I would have. >>> >>> Here in academia, it's very common for projects to be put on hold for >>> two or three years due to temporary lack of funding, or because a lab goes >>> for a couple years without a grad student who has the necessary expertise. >>> So if a grad student gets stuck with a project that requires a version of >>> VTK that won't work on a modern system, it becomes very difficult to even >>> get started. >>> >>> - David >>> >>> >>> On Wed, Jun 10, 2015 at 9:31 AM, Berk Geveci >>> wrote: >>> >>>> Maybe one way of addressing this issue would be to keep two versions >>>> maintained for a longer period? For example, we could commit to maintaining >>>> (minor bug fixes and limited testing only) VTK 6 for 3 years after we >>>> release VTK 7... That way customer that are stuck on old compiler can >>>> benefit from bug fixes and testing longer. If they want newer features, >>>> they would have to update. Given that we are likely to move to VTK 7 and >>>> then 8 pretty quickly, even longer than 3 years may be warranted. >>>> >>>> I would argue for aiming for (mostly) C++ 11 by VTK 8, probably around >>>> late 2016. >>>> >>>> -berk >>>> >>> >> >> _______________________________________________ >> 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 david.gobbi at gmail.com Thu Jun 11 11:46:36 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Thu, 11 Jun 2015 09:46:36 -0600 Subject: [vtk-developers] [vtkusers] Long-term support for previous VTK release In-Reply-To: References: Message-ID: On Thu, Jun 11, 2015 at 8:57 AM, David E DeMarle wrote: > 5.10 was the first time we attempted any kind of long term support ( > http://public.kitware.com/pipermail/vtk-developers/2013-October/029905.html) > eh? > For VTK 4, there was no long-term support, but neither were their any restrictions on developers continuing to push fixes to the old branch. I continued to push fixes for VTK 4 for a couple years, at least. So there really was a bit of long-term support going on for VTK 4, just not from Kitware ;) - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Thu Jun 11 12:22:24 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Thu, 11 Jun 2015 12:22:24 -0400 Subject: [vtk-developers] [vtkusers] Long-term support for previous VTK release In-Reply-To: References: Message-ID: This is good to know. With Gitlab in place, everyone who can merge to master should be able to merge to a VTK 6 branch once we create it. If there are no objections to this, we should go ahead and make a branch for VTK 6.2. Unless I hear a good reason why not, let's shoot for Monday. On Thu, Jun 11, 2015 at 11:46 AM, David Gobbi wrote: > On Thu, Jun 11, 2015 at 8:57 AM, David E DeMarle > wrote: > >> 5.10 was the first time we attempted any kind of long term support ( >> http://public.kitware.com/pipermail/vtk-developers/2013-October/029905.html) >> eh? >> > > For VTK 4, there was no long-term support, but neither were their any > restrictions on developers continuing to push fixes to the old branch. I > continued to push fixes for VTK 4 for a couple years, at least. > > So there really was a bit of long-term support going on for VTK 4, just > not from Kitware ;) > > - David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Fri Jun 12 04:50:31 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Fri, 12 Jun 2015 18:50:31 +1000 Subject: [vtk-developers] squadViewer Message-ID: Hi Michael, You may be interested to know that as the original author of the Tcl version, your "three sliders of fun" has just become "six sliders of fun", there is now a Python version in VTK. Regards Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.lonie at kitware.com Fri Jun 12 07:48:18 2015 From: david.lonie at kitware.com (David Lonie) Date: Fri, 12 Jun 2015 07:48:18 -0400 Subject: [vtk-developers] Test failing on megas extdeps Message-ID: I'm looking into this failure for a new test on a gitlab PR: https://open.cdash.org/testDetails.php?test=344159456&build=3855063 When I VNC in, I can see the image rendering properly on screen, but the output is black. The only thing this test does differently from others is use display tiling to enlarge the output image, and it passes everywhere else but this build. Is there something odd about this testing platform? The 'extdeps' bit in the build name is the only clue I see that something may be quirky, and I'm struggling to figure out what could be breaking here, and only here. Any insights? Thanks, Dave -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Fri Jun 12 19:06:28 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Fri, 12 Jun 2015 23:06:28 +0000 Subject: [vtk-developers] Test failing on megas extdeps In-Reply-To: References: Message-ID: Megas does use a VNC server for running the dashboards. Also, it tries to use system versions of versions of various external libraries. Also, notice that it's using Qt5. Utkarsh On Fri, Jun 12, 2015 at 7:48 AM David Lonie wrote: > I'm looking into this failure for a new test on a gitlab PR: > > https://open.cdash.org/testDetails.php?test=344159456&build=3855063 > > When I VNC in, I can see the image rendering properly on screen, but the > output is black. The only thing this test does differently from others is > use display tiling to enlarge the output image, and it passes everywhere > else but this build. > > Is there something odd about this testing platform? The 'extdeps' bit in > the build name is the only clue I see that something may be quirky, and I'm > struggling to figure out what could be breaking here, and only here. > > Any insights? > > Thanks, > 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 will.schroeder at kitware.com Sat Jun 13 08:28:35 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Sat, 13 Jun 2015 08:28:35 -0400 Subject: [vtk-developers] Gentle introduction to vtkSMPTools and vision for parallel computing including VTK-m Message-ID: FYI- There is a lot of recent work going on in VTK to address parallel computing, ranging from multi-core, shared memory approaches (vtkSMPTools) to GPU's and co-processors (VTK-m), to rewriting algorithms for parallel computation. Here's a high-level introduction. http://www.kitware.com/blog/home/post/915 There's a ton of work to do so if you are interested let's start some threads (no pun intended) and coordinate our efforts. W -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Sat Jun 13 12:56:08 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Sat, 13 Jun 2015 10:56:08 -0600 Subject: [vtk-developers] Gentle introduction to vtkSMPTools and vision for parallel computing including VTK-m In-Reply-To: References: Message-ID: I grepped the code to see how many classes directly use the old vtkMultiThreader for SMP. It's an amazingly small number, because multithreading was nicely consolidated into base classes like vtkThreadedImageAlgorithm and vtkStreamer: Common/ExecutionModel/vtkThreadedImageAlgorithm.cxx (base class) Filters/FlowPaths/vtkStreamer.cxx (base class) Filters/Hybrid/vtkImplicitModeller.cxx Rendering/Core/vtkImageMapper3D.cxx Rendering/Volume/vtkEncodedGradientEstimator.cxx (base class) Rendering/Volume/vtkFixedPointVolumeRayCastMapper.cxx Rendering/Volume/vtkUnstructuredGridVolumeRayCastMapper.cxx Rendering/Volume/vtkVolumeRayCastMapper.cxx http://www.vtk.org/Wiki/VTK/Replacing_vtkMultiThreader_with_vtkSMPTools Our GSoC student has been doing a great job updating the vtkThreadedImageAlgorithm to use vtkSMPTools. I'll tackle the ImageMapper, since it's one of my own classes, and I might be able to take a look at the implicit modeller. - David On Sat, Jun 13, 2015 at 6:28 AM, Will Schroeder wrote: > FYI- There is a lot of recent work going on in VTK to address parallel > computing, ranging from multi-core, shared memory approaches (vtkSMPTools) > to GPU's and co-processors (VTK-m), to rewriting algorithms for parallel > computation. Here's a high-level introduction. > > http://www.kitware.com/blog/home/post/915 > > There's a ton of work to do so if you are interested let's start some > threads (no pun intended) and coordinate our efforts. > > W > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Jun 15 13:31:58 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 15 Jun 2015 13:31:58 -0400 Subject: [vtk-developers] Pentagonal prism bug resolved! Message-ID: Folks, I reported recently of issues with the shape functions and derivatives for the pentagonal prism. Since I could not find any references for the current implementation I used the formulation in this paper: http://dilbert.engr.ucdavis.edu/~suku/nem/papers/polyelas.pdf Since this paper did not have the shape function derivatives, I used SymPy ( http://www.sympy.org/en/index.html ) to compute the derivatives. I'm happy to report that the new formulation does a great job and passes the new unit test I created for cells. I have not submitted a patch yet since I want the code to document the process. I wrote c++ code and SymPy code to generate the statements for the new formulation. I wanted to give a heads up in case someone else is looking into this. Bill From berk.geveci at kitware.com Mon Jun 15 14:17:00 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 15 Jun 2015 14:17:00 -0400 Subject: [vtk-developers] Pentagonal prism bug resolved! In-Reply-To: References: Message-ID: You rock Bill. On Mon, Jun 15, 2015 at 1:31 PM, Bill Lorensen wrote: > Folks, > > I reported recently of issues with the shape functions and derivatives > for the pentagonal prism. Since I could not find any references for > the current implementation I used the formulation in this paper: > http://dilbert.engr.ucdavis.edu/~suku/nem/papers/polyelas.pdf > Since this paper did not have the shape function derivatives, I used > SymPy ( http://www.sympy.org/en/index.html ) to compute the > derivatives. > > I'm happy to report that the new formulation does a great job and > passes the new unit test I created for cells. > > I have not submitted a patch yet since I want the code to document the > process. I wrote c++ code and SymPy code to generate the statements > for the new formulation. > > I wanted to give a heads up in case someone else is looking into this. > > Bill > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bill.lorensen at gmail.com Mon Jun 15 14:27:34 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 15 Jun 2015 14:27:34 -0400 Subject: [vtk-developers] Pentagonal prism bug resolved! In-Reply-To: References: Message-ID: Brings back memories of my finite element days, 1968-1978, at Watervliet Arsenal. At that time we worked with NASTRAN and we added a few elements for crack tip analysis.... Pu, S. L., M. A. Hussain, and W. E. Lorensen, The Collapsed Cubic Isoparametric Element as a Singular Element for Crack Problems, International Journal for Numerical Methods in Engineering, vol. 12, no. 11, pp. 1727-1742, 1978. Hussain, M. A. and W. E. Lorensen, Isoparametric Elements as Singular Elements for Crack Problems, AR-LCB-TR-77041, Benet Weapons Laboratory, Watervliet, NY, November 1977. Hussain, M. A.; Pu, S. L.; Lorensen, W. E., Singular Plastic Element: NASTRAN Implementation and Application, Sixth NASTRAN Users' Colloq., pp. 257-274, October, 1977, (NASA CP-2018). Pu, S. L., M. A. Hussain, and W. E. Lorensen, Collapsed 12-Node Triangular Elements as Crack Tip Elements for Elastic Fracture, ARLCB-TR-77047, Watervliet Arsenal, Watervliet, NY, December 1977. Lorensen, W. E. and M. A. Hussain, "The Stability of Isoparametric Elements as a Singular Element for Crack Problems," in Developments in Mechanics, ed. T. C. T. Ting, 1977. Pu, S. L., M. A. Hussain, and W. E. Lorensen, The Collapsed Cubic Isoparametric Element as a Singular Element for Crack Problems, AR-LCB-TR77047, Watervliet Arsenal, 1977. Hussain, M. A., W. E. Lorensen, and G. Pflegl, The Quarter-Point Quadratic Isoparametric Element as A Singular Element for Crack Problems, TM-X-3428, p. 419, NASA, 1976. On Mon, Jun 15, 2015 at 2:17 PM, Berk Geveci wrote: > You rock Bill. > > On Mon, Jun 15, 2015 at 1:31 PM, Bill Lorensen > wrote: >> >> Folks, >> >> I reported recently of issues with the shape functions and derivatives >> for the pentagonal prism. Since I could not find any references for >> the current implementation I used the formulation in this paper: >> http://dilbert.engr.ucdavis.edu/~suku/nem/papers/polyelas.pdf >> Since this paper did not have the shape function derivatives, I used >> SymPy ( http://www.sympy.org/en/index.html ) to compute the >> derivatives. >> >> I'm happy to report that the new formulation does a great job and >> passes the new unit test I created for cells. >> >> I have not submitted a patch yet since I want the code to document the >> process. I wrote c++ code and SymPy code to generate the statements >> for the new formulation. >> >> I wanted to give a heads up in case someone else is looking into this. >> >> Bill >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> > -- Unpaid intern in BillsBasement at noware dot com From berk.geveci at kitware.com Mon Jun 15 15:03:09 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Mon, 15 Jun 2015 15:03:09 -0400 Subject: [vtk-developers] Pentagonal prism bug resolved! In-Reply-To: References: Message-ID: Finite element analysis with punch cards. That's hard core! -berk On Mon, Jun 15, 2015 at 2:27 PM, Bill Lorensen wrote: > Brings back memories of my finite element days, 1968-1978, at > Watervliet Arsenal. At that time we worked with NASTRAN and we added a > few elements for crack tip analysis.... > > > Pu, S. L., M. A. Hussain, and W. E. Lorensen, The Collapsed Cubic > Isoparametric Element as a Singular Element for Crack Problems, > International Journal for Numerical Methods in Engineering, vol. 12, > no. 11, pp. 1727-1742, 1978. > > Hussain, M. A. and W. E. Lorensen, Isoparametric Elements as Singular > Elements for Crack Problems, AR-LCB-TR-77041, Benet Weapons > Laboratory, Watervliet, NY, November 1977. > > Hussain, M. A.; Pu, S. L.; Lorensen, W. E., Singular Plastic Element: > NASTRAN Implementation and Application, Sixth NASTRAN Users' Colloq., > pp. 257-274, October, 1977, (NASA CP-2018). > > Pu, S. L., M. A. Hussain, and W. E. Lorensen, Collapsed 12-Node > Triangular Elements as Crack Tip Elements for Elastic Fracture, > ARLCB-TR-77047, Watervliet Arsenal, Watervliet, NY, December 1977. > > Lorensen, W. E. and M. A. Hussain, "The Stability of Isoparametric > Elements as a Singular Element for Crack Problems," in Developments in > Mechanics, ed. T. C. T. Ting, 1977. > > Pu, S. L., M. A. Hussain, and W. E. Lorensen, The Collapsed Cubic > Isoparametric Element as a Singular Element for Crack Problems, > AR-LCB-TR77047, Watervliet Arsenal, 1977. > > Hussain, M. A., W. E. Lorensen, and G. Pflegl, The Quarter-Point > Quadratic Isoparametric Element as A Singular Element for Crack > Problems, TM-X-3428, p. 419, NASA, 1976. > > > On Mon, Jun 15, 2015 at 2:17 PM, Berk Geveci > wrote: > > You rock Bill. > > > > On Mon, Jun 15, 2015 at 1:31 PM, Bill Lorensen > > wrote: > >> > >> Folks, > >> > >> I reported recently of issues with the shape functions and derivatives > >> for the pentagonal prism. Since I could not find any references for > >> the current implementation I used the formulation in this paper: > >> http://dilbert.engr.ucdavis.edu/~suku/nem/papers/polyelas.pdf > >> Since this paper did not have the shape function derivatives, I used > >> SymPy ( http://www.sympy.org/en/index.html ) to compute the > >> derivatives. > >> > >> I'm happy to report that the new formulation does a great job and > >> passes the new unit test I created for cells. > >> > >> I have not submitted a patch yet since I want the code to document the > >> process. I wrote c++ code and SymPy code to generate the statements > >> for the new formulation. > >> > >> I wanted to give a heads up in case someone else is looking into this. > >> > >> Bill > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Tue Jun 16 04:23:47 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Tue, 16 Jun 2015 01:23:47 -0700 (MST) Subject: [vtk-developers] VTK for android example: missing vtkRenderingOpenGL2 In-Reply-To: <1433861110591-5732215.post@n5.nabble.com> References: <1433861110591-5732215.post@n5.nabble.com> Message-ID: <1434443027682-5732361.post@n5.nabble.com> So I solved my problem finally. Apparently, while ccmaking I couldn't at the same time activate OpenGL2 for the rendering and the android support I had first to do OpenGL2 and then press configure and then android. Problem solved :) -- View this message in context: http://vtk.1045678.n5.nabble.com/VTK-for-android-example-missing-vtkRenderingOpenGL2-tp5732215p5732361.html Sent from the VTK - Dev mailing list archive at Nabble.com. From lonni.besancon at gmail.com Tue Jun 16 04:26:13 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Tue, 16 Jun 2015 01:26:13 -0700 (MST) Subject: [vtk-developers] android_native_app_glue.c doesn't exist Message-ID: <1434443173378-5732362.post@n5.nabble.com> Hello, Still trying to run VTK on android devices. Apparently I'm stuck a step further but this time I have no idea where to look for a solution to this problem. Whenever I'm trying to build the android examples (especially the native one) I get this as a result: /CMake Error at NativeVTK/jni/CMakeLists.txt:11 (add_library): Cannot find source file: /sources/android/native_app_glue/android_native_app_glue.c Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx CMake Error: CMake can not determine linker language for target: NativeVTK CMake Error: Cannot determine link language for target "NativeVTK". CMake Warning (dev): Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run "cmake --help-policy CMP0042" for policy details. Use the cmake_policy command to set the policy and suppress this warning./ Would anyone know where that could come from? Thanks in advance for helping :). Have a nice day -- View this message in context: http://vtk.1045678.n5.nabble.com/android-native-app-glue-c-doesn-t-exist-tp5732362.html Sent from the VTK - Dev mailing list archive at Nabble.com. From ken.martin at kitware.com Tue Jun 16 10:45:28 2015 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 16 Jun 2015 10:45:28 -0400 Subject: [vtk-developers] android_native_app_glue.c doesn't exist In-Reply-To: <1434443173378-5732362.post@n5.nabble.com> References: <1434443173378-5732362.post@n5.nabble.com> Message-ID: <9b7ff6aed3c433573591f7920006bd2a@mail.gmail.com> That file was/is included in the android NDK. That is where it should be. Maybe it moved location in more recent NDK versions. 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. -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Lonni Besan?on Sent: Tuesday, June 16, 2015 4:26 AM To: vtk-developers at vtk.org Subject: [vtk-developers] android_native_app_glue.c doesn't exist Hello, Still trying to run VTK on android devices. Apparently I'm stuck a step further but this time I have no idea where to look for a solution to this problem. Whenever I'm trying to build the android examples (especially the native one) I get this as a result: /CMake Error at NativeVTK/jni/CMakeLists.txt:11 (add_library): Cannot find source file: /sources/android/native_app_glue/android_native_app_glue.c Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx CMake Error: CMake can not determine linker language for target: NativeVTK CMake Error: Cannot determine link language for target "NativeVTK". CMake Warning (dev): Policy CMP0042 is not set: MACOSX_RPATH is enabled by default. Run "cmake --help-policy CMP0042" for policy details. Use the cmake_policy command to set the policy and suppress this warning./ Would anyone know where that could come from? Thanks in advance for helping :). Have a nice day -- View this message in context: http://vtk.1045678.n5.nabble.com/android-native-app-glue-c-doesn-t-exist-t p5732362.html Sent from the VTK - Dev mailing list archive at Nabble.com. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers From ali.hadimogullari at netcad.com.tr Tue Jun 16 10:47:58 2015 From: ali.hadimogullari at netcad.com.tr (alihadim) Date: Tue, 16 Jun 2015 07:47:58 -0700 (MST) Subject: [vtk-developers] vtkClipPolyData update is waiting use with Tube Algorithm. Message-ID: <1434466078717-5732372.post@n5.nabble.com> I created vtkpolydata after I added tube algorithm. These are not problem. Then vtkClipPolyData update ise very waitng when I use to vtkClipPolyData with tube algorithm. Do you have any idea? Tanks. -- View this message in context: http://vtk.1045678.n5.nabble.com/vtkClipPolyData-update-is-waiting-use-with-Tube-Algorithm-tp5732372.html Sent from the VTK - Dev mailing list archive at Nabble.com. From lonni.besancon at gmail.com Tue Jun 16 10:56:25 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Tue, 16 Jun 2015 07:56:25 -0700 (MST) Subject: [vtk-developers] android_native_app_glue.c doesn't exist In-Reply-To: <9b7ff6aed3c433573591f7920006bd2a@mail.gmail.com> References: <1434443173378-5732362.post@n5.nabble.com> <9b7ff6aed3c433573591f7920006bd2a@mail.gmail.com> Message-ID: <1434466585533-5732374.post@n5.nabble.com> I'm using android-ndk-r10e. What do you advise me to do then? Should I get a previous version of the ndk? If so which one? -- View this message in context: http://vtk.1045678.n5.nabble.com/android-native-app-glue-c-doesn-t-exist-tp5732362p5732374.html Sent from the VTK - Dev mailing list archive at Nabble.com. From ken.martin at kitware.com Tue Jun 16 11:03:07 2015 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 16 Jun 2015 11:03:07 -0400 Subject: [vtk-developers] android_native_app_glue.c doesn't exist In-Reply-To: <1434466585533-5732374.post@n5.nabble.com> References: <1434443173378-5732362.post@n5.nabble.com> <9b7ff6aed3c433573591f7920006bd2a@mail.gmail.com> <1434466585533-5732374.post@n5.nabble.com> Message-ID: <42a06a8b52c2689b3115c7c498a934b8@mail.gmail.com> I know NDK r9d has it, that is what I last tried building against. - 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. -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Lonni Besan?on Sent: Tuesday, June 16, 2015 10:56 AM To: vtk-developers at vtk.org Subject: Re: [vtk-developers] android_native_app_glue.c doesn't exist I'm using android-ndk-r10e. What do you advise me to do then? Should I get a previous version of the ndk? If so which one? -- View this message in context: http://vtk.1045678.n5.nabble.com/android-native-app-glue-c-doesn-t-exist-t p5732362p5732374.html Sent from the VTK - Dev mailing list archive at Nabble.com. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers From lonni.besancon at gmail.com Tue Jun 16 11:05:25 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Tue, 16 Jun 2015 08:05:25 -0700 (MST) Subject: [vtk-developers] android_native_app_glue.c doesn't exist In-Reply-To: <42a06a8b52c2689b3115c7c498a934b8@mail.gmail.com> References: <1434443173378-5732362.post@n5.nabble.com> <9b7ff6aed3c433573591f7920006bd2a@mail.gmail.com> <1434466585533-5732374.post@n5.nabble.com> <42a06a8b52c2689b3115c7c498a934b8@mail.gmail.com> Message-ID: <1434467125303-5732376.post@n5.nabble.com> I've just checked my android-ndk and it does have the file. Maybe the location is not the same though. What is the location of yours? Mine is under: .../android-ndk-r10e/sources/android/native_app_glue -- View this message in context: http://vtk.1045678.n5.nabble.com/android-native-app-glue-c-doesn-t-exist-tp5732362p5732376.html Sent from the VTK - Dev mailing list archive at Nabble.com. From ken.martin at kitware.com Tue Jun 16 11:15:11 2015 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 16 Jun 2015 11:15:11 -0400 Subject: [vtk-developers] android_native_app_glue.c doesn't exist In-Reply-To: <1434467125303-5732376.post@n5.nabble.com> References: <1434443173378-5732362.post@n5.nabble.com> <9b7ff6aed3c433573591f7920006bd2a@mail.gmail.com> <1434466585533-5732374.post@n5.nabble.com> <42a06a8b52c2689b3115c7c498a934b8@mail.gmail.com> <1434467125303-5732376.post@n5.nabble.com> Message-ID: <484f26a198af0d2c3a58953d9bd351ad@mail.gmail.com> Same place in mine. I suspect that VTK/CMake/android.toolchain.cmake has not been updated for newer SDKs. Try adding -r10e to line 219 of that file. That may help it. 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. -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Lonni Besan?on Sent: Tuesday, June 16, 2015 11:05 AM To: vtk-developers at vtk.org Subject: Re: [vtk-developers] android_native_app_glue.c doesn't exist I've just checked my android-ndk and it does have the file. Maybe the location is not the same though. What is the location of yours? Mine is under: .../android-ndk-r10e/sources/android/native_app_glue -- View this message in context: http://vtk.1045678.n5.nabble.com/android-native-app-glue-c-doesn-t-exist-t p5732362p5732376.html Sent from the VTK - Dev mailing list archive at Nabble.com. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers From lonni.besancon at gmail.com Tue Jun 16 11:16:18 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Tue, 16 Jun 2015 08:16:18 -0700 (MST) Subject: [vtk-developers] android_native_app_glue.c doesn't exist In-Reply-To: <484f26a198af0d2c3a58953d9bd351ad@mail.gmail.com> References: <1434443173378-5732362.post@n5.nabble.com> <9b7ff6aed3c433573591f7920006bd2a@mail.gmail.com> <1434466585533-5732374.post@n5.nabble.com> <42a06a8b52c2689b3115c7c498a934b8@mail.gmail.com> <1434467125303-5732376.post@n5.nabble.com> <484f26a198af0d2c3a58953d9bd351ad@mail.gmail.com> Message-ID: <1434467778943-5732378.post@n5.nabble.com> And then I should CCmake again and make right? -- View this message in context: http://vtk.1045678.n5.nabble.com/android-native-app-glue-c-doesn-t-exist-tp5732362p5732378.html Sent from the VTK - Dev mailing list archive at Nabble.com. From ken.martin at kitware.com Tue Jun 16 11:18:18 2015 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 16 Jun 2015 11:18:18 -0400 Subject: [vtk-developers] android_native_app_glue.c doesn't exist In-Reply-To: <1434467778943-5732378.post@n5.nabble.com> References: <1434443173378-5732362.post@n5.nabble.com> <9b7ff6aed3c433573591f7920006bd2a@mail.gmail.com> <1434466585533-5732374.post@n5.nabble.com> <42a06a8b52c2689b3115c7c498a934b8@mail.gmail.com> <1434467125303-5732376.post@n5.nabble.com> <484f26a198af0d2c3a58953d9bd351ad@mail.gmail.com> <1434467778943-5732378.post@n5.nabble.com> Message-ID: Yes. Make would probably run cmake anyhow as the file changed but it doesn't hurt to run it yourself. - 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. -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Lonni Besan?on Sent: Tuesday, June 16, 2015 11:16 AM To: vtk-developers at vtk.org Subject: Re: [vtk-developers] android_native_app_glue.c doesn't exist And then I should CCmake again and make right? -- View this message in context: http://vtk.1045678.n5.nabble.com/android-native-app-glue-c-doesn-t-exist-t p5732362p5732378.html Sent from the VTK - Dev mailing list archive at Nabble.com. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers From lonni.besancon at gmail.com Tue Jun 16 11:24:20 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Tue, 16 Jun 2015 08:24:20 -0700 (MST) Subject: [vtk-developers] android_native_app_glue.c doesn't exist In-Reply-To: <1434467778943-5732378.post@n5.nabble.com> References: <1434443173378-5732362.post@n5.nabble.com> <9b7ff6aed3c433573591f7920006bd2a@mail.gmail.com> <1434466585533-5732374.post@n5.nabble.com> <42a06a8b52c2689b3115c7c498a934b8@mail.gmail.com> <1434467125303-5732376.post@n5.nabble.com> <484f26a198af0d2c3a58953d9bd351ad@mail.gmail.com> <1434467778943-5732378.post@n5.nabble.com> Message-ID: <1434468260576-5732380.post@n5.nabble.com> So I tried adding this to the toolchain (without ccmaking and making vtk again, dunno if I should) and it doesn't work. Has anyone tried and succeeded with a recent ndk ? -- View this message in context: http://vtk.1045678.n5.nabble.com/android-native-app-glue-c-doesn-t-exist-tp5732362p5732380.html Sent from the VTK - Dev mailing list archive at Nabble.com. From chinander at gmail.com Tue Jun 16 11:31:59 2015 From: chinander at gmail.com (Mike Chinander) Date: Tue, 16 Jun 2015 10:31:59 -0500 Subject: [vtk-developers] android_native_app_glue.c doesn't exist In-Reply-To: <1434468260576-5732380.post@n5.nabble.com> References: <1434443173378-5732362.post@n5.nabble.com> <9b7ff6aed3c433573591f7920006bd2a@mail.gmail.com> <1434466585533-5732374.post@n5.nabble.com> <42a06a8b52c2689b3115c7c498a934b8@mail.gmail.com> <1434467125303-5732376.post@n5.nabble.com> <484f26a198af0d2c3a58953d9bd351ad@mail.gmail.com> <1434467778943-5732378.post@n5.nabble.com> <1434468260576-5732380.post@n5.nabble.com> Message-ID: Is your ANDROID_NDK CMake variable set correctly to the path of the NDK? On Tue, Jun 16, 2015 at 10:24 AM, Lonni Besan?on wrote: > So I tried adding this to the toolchain (without ccmaking and making vtk > again, dunno if I should) and it doesn't work. > > Has anyone tried and succeeded with a recent ndk ? > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/android-native-app-glue-c-doesn-t-exist-tp5732362p5732380.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Tue Jun 16 11:34:08 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Tue, 16 Jun 2015 08:34:08 -0700 (MST) Subject: [vtk-developers] android_native_app_glue.c doesn't exist In-Reply-To: References: <1434443173378-5732362.post@n5.nabble.com> <9b7ff6aed3c433573591f7920006bd2a@mail.gmail.com> <1434466585533-5732374.post@n5.nabble.com> <42a06a8b52c2689b3115c7c498a934b8@mail.gmail.com> <1434467125303-5732376.post@n5.nabble.com> <484f26a198af0d2c3a58953d9bd351ad@mail.gmail.com> <1434467778943-5732378.post@n5.nabble.com> <1434468260576-5732380.post@n5.nabble.com> Message-ID: <1434468848072-5732382.post@n5.nabble.com> Yes I made sure of that. When ccmaking vtk if you don't use a correct path it doesn't generate files or maybe it fails during the making of vtk but it fails even before I can get to the android examples anyway. -- View this message in context: http://vtk.1045678.n5.nabble.com/android-native-app-glue-c-doesn-t-exist-tp5732362p5732382.html Sent from the VTK - Dev mailing list archive at Nabble.com. From lonni.besancon at gmail.com Tue Jun 16 11:59:29 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Tue, 16 Jun 2015 08:59:29 -0700 (MST) Subject: [vtk-developers] android_native_app_glue.c doesn't exist In-Reply-To: <1434468848072-5732382.post@n5.nabble.com> References: <1434443173378-5732362.post@n5.nabble.com> <9b7ff6aed3c433573591f7920006bd2a@mail.gmail.com> <1434466585533-5732374.post@n5.nabble.com> <42a06a8b52c2689b3115c7c498a934b8@mail.gmail.com> <1434467125303-5732376.post@n5.nabble.com> <484f26a198af0d2c3a58953d9bd351ad@mail.gmail.com> <1434467778943-5732378.post@n5.nabble.com> <1434468260576-5732380.post@n5.nabble.com> <1434468848072-5732382.post@n5.nabble.com> Message-ID: <1434470369464-5732383.post@n5.nabble.com> So I have tried to build VTK again for android with everything set in the toolchain as suggested but I still get the same error: it cannot find my native_app_glue.c file while I have checked and it is really present at $PathToNDK/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c And the error still is: CMake Error at jni/CMakeLists.txt:11 (add_library): Cannot find source file: /sources/android/native_app_glue/android_native_app_glue.c Tried extensions .c .C .c++ .cc .cpp .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx CMake Error: CMake can not determine linker language for target: NativeVTK CMake Error: Cannot determine link language for target "NativeVTK". -- View this message in context: http://vtk.1045678.n5.nabble.com/android-native-app-glue-c-doesn-t-exist-tp5732362p5732383.html Sent from the VTK - Dev mailing list archive at Nabble.com. From lonni.besancon at gmail.com Tue Jun 16 12:06:01 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Tue, 16 Jun 2015 09:06:01 -0700 (MST) Subject: [vtk-developers] android_native_app_glue.c doesn't exist In-Reply-To: References: <1434443173378-5732362.post@n5.nabble.com> <9b7ff6aed3c433573591f7920006bd2a@mail.gmail.com> <1434466585533-5732374.post@n5.nabble.com> <42a06a8b52c2689b3115c7c498a934b8@mail.gmail.com> <1434467125303-5732376.post@n5.nabble.com> <484f26a198af0d2c3a58953d9bd351ad@mail.gmail.com> <1434467778943-5732378.post@n5.nabble.com> <1434468260576-5732380.post@n5.nabble.com> Message-ID: <1434470761121-5732385.post@n5.nabble.com> So I have checked again, just in case, and turns out you were right, my path to the ndk is not set, even though I did set it when building vtk and when I try echoing in my terminal it is also set. How can I set it then? Directly in the CMakeList? Seems kinda counter-intuitive but that's the only thing I can think of. -- View this message in context: http://vtk.1045678.n5.nabble.com/android-native-app-glue-c-doesn-t-exist-tp5732362p5732385.html Sent from the VTK - Dev mailing list archive at Nabble.com. From e.tadeu at gmail.com Tue Jun 16 14:26:37 2015 From: e.tadeu at gmail.com (E. Tadeu) Date: Tue, 16 Jun 2015 15:26:37 -0300 Subject: [vtk-developers] Observer crashes with Python thread, bug in vtkPythonCommand and also in dataset_adapter Message-ID: Currently, if an observer is added in a python thread and then executed in another thread after the first one has finished, it will cause a segfault/access violation in the python interpreter. This code reproduces the problem: from Queue import Queue from threading import Thread import vtk def on_delete(caller, event): print 'on_delete:' print ' caller:', caller print ' event:', event def create_object_with_observer(result_queue): object_with_observer = vtk.vtkObject() object_with_observer.AddObserver('DeleteEvent', on_delete) result_queue.put(object_with_observer) def test_observer_command_with_threads(): result_queue = Queue() thread = Thread(target=create_object_with_observer, args=(result_queue,)) thread.start() thread.join() object_with_observer = result_queue.get(block=True) print object_with_observer del object_with_observer # <-- crashes here (would crash later without del too) print 'checkpoint' if __name__ == '__main__': test_observer_command_with_threads() This seems to happen because of this line in vtkPythonCommand.cxx, which seems to be assigning a bad ThreadState pointer to _PyThreadState_Current: prevThreadState = PyThreadState_Swap(this->ThreadState); (The pointer seems to be dangling. Perhaps vtkPythonCommand::SetThreadState should *incref *the PyThreadState* object?) This bug is directly affecting dataset_adapter, because it causes a crash in this use case (dataset_adapter uses a command to store the numpy array ref): from Queue import Queue from threading import Thread from vtk.numpy_interface.dataset_adapter import UnstructuredGrid import numpy import vtk def create_unstructured_grid(result_queue): points = numpy.array([[0.0, 0.0, 0.0]]) ug = UnstructuredGrid(vtk.vtkUnstructuredGrid()) ug.SetPoints(points) result_queue.put(ug) def test_unstructured_grid_in_thread(): result_queue = Queue() thread = Thread(target=create_unstructured_grid, args=(result_queue,)) thread.start() thread.join() ug = result_queue.get(block=True) print ug del ug # <-- crashes print 'checkpoint' if __name__ == '__main__': test_unstructured_grid_in_thread() ( I've already submitted a bug report here: http://www.paraview.org/Bug/view.php?id=15545 ) Best regards, Edson -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.amaclean at gmail.com Tue Jun 16 20:20:05 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 17 Jun 2015 10:20:05 +1000 Subject: [vtk-developers] Pentagonal prism bug resolved! Message-ID: Brilliant work Bill, That is a really interesting paper. I'm glad you found a solution. Your work here just underscores the fundamental importance of good testing. I'm looking forward to seeing it in VTK. I had never heard of SymPy, I had always used Maple but it is too expensive now that I have retired. I'll give it a SymPy a go. Nothing wrong with punch cards ... except when you drop a whole box. I used them to do Tempromandibular joint (TMJ) analysis using FORTRAN, way back in the 70's. Then I graduated to using a Teletype and APL! Regards Andrew On Tue, Jun 16, 2015 at 6:26 PM, wrote: > Send vtk-developers mailing list submissions to > vtk-developers at vtk.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://public.kitware.com/mailman/listinfo/vtk-developers > or, via email, send a message with subject or body 'help' to > vtk-developers-request at vtk.org > > You can reach the person managing the list at > vtk-developers-owner at vtk.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of vtk-developers digest..." > > Today's Topics: > > 1. Pentagonal prism bug resolved! (Bill Lorensen) > 2. Re: Pentagonal prism bug resolved! (Berk Geveci) > 3. Re: Pentagonal prism bug resolved! (Bill Lorensen) > 4. Re: Pentagonal prism bug resolved! (Berk Geveci) > 5. Re: VTK for android example: missing vtkRenderingOpenGL2 > (Lonni Besan?on) > 6. android_native_app_glue.c doesn't exist (Lonni Besan?on) > > > ---------- Forwarded message ---------- > From: Bill Lorensen > To: VTK Developers > Cc: > Date: Mon, 15 Jun 2015 13:31:58 -0400 > Subject: [vtk-developers] Pentagonal prism bug resolved! > Folks, > > I reported recently of issues with the shape functions and derivatives > for the pentagonal prism. Since I could not find any references for > the current implementation I used the formulation in this paper: > http://dilbert.engr.ucdavis.edu/~suku/nem/papers/polyelas.pdf > Since this paper did not have the shape function derivatives, I used > SymPy ( http://www.sympy.org/en/index.html ) to compute the > derivatives. > > I'm happy to report that the new formulation does a great job and > passes the new unit test I created for cells. > > I have not submitted a patch yet since I want the code to document the > process. I wrote c++ code and SymPy code to generate the statements > for the new formulation. > > I wanted to give a heads up in case someone else is looking into this. > > Bill > > > > ---------- Forwarded message ---------- > From: Berk Geveci > To: Bill Lorensen > Cc: VTK Developers > Date: Mon, 15 Jun 2015 14:17:00 -0400 > Subject: Re: [vtk-developers] Pentagonal prism bug resolved! > You rock Bill. > > On Mon, Jun 15, 2015 at 1:31 PM, Bill Lorensen > wrote: > >> Folks, >> >> I reported recently of issues with the shape functions and derivatives >> for the pentagonal prism. Since I could not find any references for >> the current implementation I used the formulation in this paper: >> http://dilbert.engr.ucdavis.edu/~suku/nem/papers/polyelas.pdf >> Since this paper did not have the shape function derivatives, I used >> SymPy ( http://www.sympy.org/en/index.html ) to compute the >> derivatives. >> >> I'm happy to report that the new formulation does a great job and >> passes the new unit test I created for cells. >> >> I have not submitted a patch yet since I want the code to document the >> process. I wrote c++ code and SymPy code to generate the statements >> for the new formulation. >> >> I wanted to give a heads up in case someone else is looking into this. >> >> 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 >> >> > > > ---------- Forwarded message ---------- > From: Bill Lorensen > To: Berk Geveci > Cc: VTK Developers > Date: Mon, 15 Jun 2015 14:27:34 -0400 > Subject: Re: [vtk-developers] Pentagonal prism bug resolved! > Brings back memories of my finite element days, 1968-1978, at > Watervliet Arsenal. At that time we worked with NASTRAN and we added a > few elements for crack tip analysis.... > > > Pu, S. L., M. A. Hussain, and W. E. Lorensen, The Collapsed Cubic > Isoparametric Element as a Singular Element for Crack Problems, > International Journal for Numerical Methods in Engineering, vol. 12, > no. 11, pp. 1727-1742, 1978. > > Hussain, M. A. and W. E. Lorensen, Isoparametric Elements as Singular > Elements for Crack Problems, AR-LCB-TR-77041, Benet Weapons > Laboratory, Watervliet, NY, November 1977. > > Hussain, M. A.; Pu, S. L.; Lorensen, W. E., Singular Plastic Element: > NASTRAN Implementation and Application, Sixth NASTRAN Users' Colloq., > pp. 257-274, October, 1977, (NASA CP-2018). > > Pu, S. L., M. A. Hussain, and W. E. Lorensen, Collapsed 12-Node > Triangular Elements as Crack Tip Elements for Elastic Fracture, > ARLCB-TR-77047, Watervliet Arsenal, Watervliet, NY, December 1977. > > Lorensen, W. E. and M. A. Hussain, "The Stability of Isoparametric > Elements as a Singular Element for Crack Problems," in Developments in > Mechanics, ed. T. C. T. Ting, 1977. > > Pu, S. L., M. A. Hussain, and W. E. Lorensen, The Collapsed Cubic > Isoparametric Element as a Singular Element for Crack Problems, > AR-LCB-TR77047, Watervliet Arsenal, 1977. > > Hussain, M. A., W. E. Lorensen, and G. Pflegl, The Quarter-Point > Quadratic Isoparametric Element as A Singular Element for Crack > Problems, TM-X-3428, p. 419, NASA, 1976. > > > On Mon, Jun 15, 2015 at 2:17 PM, Berk Geveci > wrote: > > You rock Bill. > > > > On Mon, Jun 15, 2015 at 1:31 PM, Bill Lorensen > > wrote: > >> > >> Folks, > >> > >> I reported recently of issues with the shape functions and derivatives > >> for the pentagonal prism. Since I could not find any references for > >> the current implementation I used the formulation in this paper: > >> http://dilbert.engr.ucdavis.edu/~suku/nem/papers/polyelas.pdf > >> Since this paper did not have the shape function derivatives, I used > >> SymPy ( http://www.sympy.org/en/index.html ) to compute the > >> derivatives. > >> > >> I'm happy to report that the new formulation does a great job and > >> passes the new unit test I created for cells. > >> > >> I have not submitted a patch yet since I want the code to document the > >> process. I wrote c++ code and SymPy code to generate the statements > >> for the new formulation. > >> > >> I wanted to give a heads up in case someone else is looking into this. > >> > >> Bill > >> _______________________________________________ > >> Powered by www.kitware.com > >> > >> Visit other Kitware open-source projects at > >> http://www.kitware.com/opensource/opensource.html > >> > >> Search the list archives at: > http://markmail.org/search/?q=vtk-developers > >> > >> Follow this link to subscribe/unsubscribe: > >> http://public.kitware.com/mailman/listinfo/vtk-developers > >> > > > > > > -- > Unpaid intern in BillsBasement at noware dot com > > > > ---------- Forwarded message ---------- > From: Berk Geveci > To: Bill Lorensen > Cc: VTK Developers > Date: Mon, 15 Jun 2015 15:03:09 -0400 > Subject: Re: [vtk-developers] Pentagonal prism bug resolved! > Finite element analysis with punch cards. That's hard core! > > -berk > > On Mon, Jun 15, 2015 at 2:27 PM, Bill Lorensen > wrote: > >> Brings back memories of my finite element days, 1968-1978, at >> Watervliet Arsenal. At that time we worked with NASTRAN and we added a >> few elements for crack tip analysis.... >> >> >> Pu, S. L., M. A. Hussain, and W. E. Lorensen, The Collapsed Cubic >> Isoparametric Element as a Singular Element for Crack Problems, >> International Journal for Numerical Methods in Engineering, vol. 12, >> no. 11, pp. 1727-1742, 1978. >> >> Hussain, M. A. and W. E. Lorensen, Isoparametric Elements as Singular >> Elements for Crack Problems, AR-LCB-TR-77041, Benet Weapons >> Laboratory, Watervliet, NY, November 1977. >> >> Hussain, M. A.; Pu, S. L.; Lorensen, W. E., Singular Plastic Element: >> NASTRAN Implementation and Application, Sixth NASTRAN Users' Colloq., >> pp. 257-274, October, 1977, (NASA CP-2018). >> >> Pu, S. L., M. A. Hussain, and W. E. Lorensen, Collapsed 12-Node >> Triangular Elements as Crack Tip Elements for Elastic Fracture, >> ARLCB-TR-77047, Watervliet Arsenal, Watervliet, NY, December 1977. >> >> Lorensen, W. E. and M. A. Hussain, "The Stability of Isoparametric >> Elements as a Singular Element for Crack Problems," in Developments in >> Mechanics, ed. T. C. T. Ting, 1977. >> >> Pu, S. L., M. A. Hussain, and W. E. Lorensen, The Collapsed Cubic >> Isoparametric Element as a Singular Element for Crack Problems, >> AR-LCB-TR77047, Watervliet Arsenal, 1977. >> >> Hussain, M. A., W. E. Lorensen, and G. Pflegl, The Quarter-Point >> Quadratic Isoparametric Element as A Singular Element for Crack >> Problems, TM-X-3428, p. 419, NASA, 1976. >> >> >> On Mon, Jun 15, 2015 at 2:17 PM, Berk Geveci >> wrote: >> > You rock Bill. >> > >> > On Mon, Jun 15, 2015 at 1:31 PM, Bill Lorensen > > >> > wrote: >> >> >> >> Folks, >> >> >> >> I reported recently of issues with the shape functions and derivatives >> >> for the pentagonal prism. Since I could not find any references for >> >> the current implementation I used the formulation in this paper: >> >> http://dilbert.engr.ucdavis.edu/~suku/nem/papers/polyelas.pdf >> >> Since this paper did not have the shape function derivatives, I used >> >> SymPy ( http://www.sympy.org/en/index.html ) to compute the >> >> derivatives. >> >> >> >> I'm happy to report that the new formulation does a great job and >> >> passes the new unit test I created for cells. >> >> >> >> I have not submitted a patch yet since I want the code to document the >> >> process. I wrote c++ code and SymPy code to generate the statements >> >> for the new formulation. >> >> >> >> I wanted to give a heads up in case someone else is looking into this. >> >> >> >> Bill >> >> _______________________________________________ >> >> Powered by www.kitware.com >> >> >> >> Visit other Kitware open-source projects at >> >> http://www.kitware.com/opensource/opensource.html >> >> >> >> Search the list archives at: >> http://markmail.org/search/?q=vtk-developers >> >> >> >> Follow this link to subscribe/unsubscribe: >> >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > >> >> >> >> -- >> Unpaid intern in BillsBasement at noware dot com >> > > > > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From nico.schloemer at gmail.com Wed Jun 17 04:00:04 2015 From: nico.schloemer at gmail.com (=?UTF-8?Q?Nico_Schl=C3=B6mer?=) Date: Wed, 17 Jun 2015 08:00:04 +0000 Subject: [vtk-developers] bug tracker? Message-ID: Hi, I wasn't able to find a bug tracker for VTK. Can you give me some pointers here? Cheers, Nico -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Wed Jun 17 04:02:13 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Wed, 17 Jun 2015 10:02:13 +0200 Subject: [vtk-developers] bug tracker? In-Reply-To: References: Message-ID: http://www.paraview.org/Bug/my_view_page.php Mathieu Westphal On Wed, Jun 17, 2015 at 10:00 AM, Nico Schl?mer wrote: > Hi, > > I wasn't able to find a bug tracker for VTK. Can you give me some pointers > here? > > Cheers, > Nico > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 jchris.fillionr at kitware.com Wed Jun 17 09:10:57 2015 From: jchris.fillionr at kitware.com (Jean-Christophe Fillion-Robin) Date: Wed, 17 Jun 2015 09:10:57 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: Message-ID: On Wed, Jun 10, 2015 at 12:10 PM, Casey Goodlett wrote: > AFAIK official python binaries are still built with VS 2008 which is not > that different (one iteration) As Casey mentioned, since python 2.7.x official compiler is still VS 2008 (VS9) and this version of python is still maintained, let's make sure to keep its support. Thanks Jc -- +1 919 869 8849 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Wed Jun 17 09:14:06 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Wed, 17 Jun 2015 06:14:06 -0700 (MST) Subject: [vtk-developers] Building VTK with QT5.4 Windows 8 Message-ID: <1434546846947-5732403.post@n5.nabble.com> Hello, I'm facing a rather weird error. I can see on the wiki that we can build vtk with support for qt5. However, when trying to do so and first configuring with cmake I get the following output: CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.2/Modules/FindQt4.cmake:1326 (message): Found unsuitable Qt version "5.4.2" from C:/Qt/5.4/msvc2012_opengl/bin/qmake.exe, this code requires Qt 4.x Call Stack (most recent call first): GUISupport/Qt/CMakeLists.txt:71 (find_package) I have tried to set CMAKE_PREFIX_PATH to C:/Qt/5.4/msvc2012_opengl/ and QT_QMAKE_EXECUTABLE to C:/Qt/5.4/msvc2012_opengl/bin/qmake.exe And yet it doesn't work. Does anyone have an explanation for that? -- View this message in context: http://vtk.1045678.n5.nabble.com/Building-VTK-with-QT5-4-Windows-8-tp5732403.html Sent from the VTK - Dev mailing list archive at Nabble.com. From karsten.tausche at student.hpi.uni-potsdam.de Wed Jun 17 09:42:26 2015 From: karsten.tausche at student.hpi.uni-potsdam.de (Karsten Tausche) Date: Wed, 17 Jun 2015 15:42:26 +0200 Subject: [vtk-developers] Building VTK with QT5.4 Windows 8 In-Reply-To: <1434546846947-5732403.post@n5.nabble.com> References: <1434546846947-5732403.post@n5.nabble.com> Message-ID: <55817942.30802@student.hpi.uni-potsdam.de> Hi, you have to set the CMake variable VTK_QT_VERSION to 5, otherwise VTK will only search for Qt4. Am 2015-06-17 um 3:14 PM schrieb Lonni Besan?on: > Hello, > > I'm facing a rather weird error. I can see on the wiki that we can build vtk > with support for qt5. However, when trying to do so and first configuring > with cmake I get the following output: > > CMake Error at C:/Program Files > (x86)/CMake/share/cmake-3.2/Modules/FindQt4.cmake:1326 (message): > Found unsuitable Qt version "5.4.2" from > C:/Qt/5.4/msvc2012_opengl/bin/qmake.exe, this code requires Qt 4.x > Call Stack (most recent call first): > GUISupport/Qt/CMakeLists.txt:71 (find_package) > > I have tried to set CMAKE_PREFIX_PATH to C:/Qt/5.4/msvc2012_opengl/ and > QT_QMAKE_EXECUTABLE to C:/Qt/5.4/msvc2012_opengl/bin/qmake.exe > > And yet it doesn't work. Does anyone have an explanation for that? > > > > -- > View this message in context: http://vtk.1045678.n5.nabble.com/Building-VTK-with-QT5-4-Windows-8-tp5732403.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From lonni.besancon at gmail.com Wed Jun 17 09:50:29 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Wed, 17 Jun 2015 06:50:29 -0700 (MST) Subject: [vtk-developers] Building VTK with QT5.4 Windows 8 In-Reply-To: <55817942.30802@student.hpi.uni-potsdam.de> References: <1434546846947-5732403.post@n5.nabble.com> <55817942.30802@student.hpi.uni-potsdam.de> Message-ID: <1434549029258-5732410.post@n5.nabble.com> Thanks, can I do it form CMake GUI? Cause I don't actually see it :s -- View this message in context: http://vtk.1045678.n5.nabble.com/Building-VTK-with-QT5-4-Windows-8-tp5732403p5732410.html Sent from the VTK - Dev mailing list archive at Nabble.com. From karsten.tausche at student.hpi.uni-potsdam.de Wed Jun 17 09:52:31 2015 From: karsten.tausche at student.hpi.uni-potsdam.de (Karsten Tausche) Date: Wed, 17 Jun 2015 15:52:31 +0200 Subject: [vtk-developers] Building VTK with QT5.4 Windows 8 In-Reply-To: <1434549029258-5732410.post@n5.nabble.com> References: <1434546846947-5732403.post@n5.nabble.com> <55817942.30802@student.hpi.uni-potsdam.de> <1434549029258-5732410.post@n5.nabble.com> Message-ID: <55817B9F.3010109@student.hpi.uni-potsdam.de> Yes, you have to set the "Advanced" check box (near the add/remove entry buttons). Am 2015-06-17 um 3:50 PM schrieb Lonni Besan?on: > Thanks, can I do it form CMake GUI? Cause I don't actually see it > :s > > > > -- View this message in context: > http://vtk.1045678.n5.nabble.com/Building-VTK-with-QT5-4-Windows-8-tp5732403p5732410.html > > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ Powered by > www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: > http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From lonni.besancon at gmail.com Wed Jun 17 10:04:43 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Wed, 17 Jun 2015 07:04:43 -0700 (MST) Subject: [vtk-developers] Building VTK with QT5.4 Windows 8 In-Reply-To: <55817B9F.3010109@student.hpi.uni-potsdam.de> References: <1434546846947-5732403.post@n5.nabble.com> <55817942.30802@student.hpi.uni-potsdam.de> <1434549029258-5732410.post@n5.nabble.com> <55817B9F.3010109@student.hpi.uni-potsdam.de> Message-ID: <1434549883778-5732412.post@n5.nabble.com> Works like a charm :). Thanks again ! -- View this message in context: http://vtk.1045678.n5.nabble.com/Building-VTK-with-QT5-4-Windows-8-tp5732403p5732412.html Sent from the VTK - Dev mailing list archive at Nabble.com. From berk.geveci at kitware.com Wed Jun 17 10:57:26 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 17 Jun 2015 10:57:26 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: Message-ID: For now, this shouldn't be a problem. However, if we aggressively pursue C++11 support, it will be a problem. See the chart in here: https://msdn.microsoft.com/en-us/library/hh567368.aspx I read that as we would have to require VS 2013 for this. My preferred timeline for this would be to require partial C++ 11 support in the compilers we support by early 2017. I also hope that we would have first class support for Python 3 way before then. Those that still want python 2.7 support in 2017 would have to depend on VTK 6 or 7 (assuming we have VTK 8). Does this make sense? Best, -berk On Wed, Jun 17, 2015 at 9:10 AM, Jean-Christophe Fillion-Robin < jchris.fillionr at kitware.com> wrote: > > On Wed, Jun 10, 2015 at 12:10 PM, Casey Goodlett < > casey.goodlett at kitware.com> wrote: > >> AFAIK official python binaries are still built with VS 2008 which is not >> that different (one iteration) > > > As Casey mentioned, since python 2.7.x official compiler is still VS 2008 > (VS9) and this version of python is still maintained, let's make sure to > keep its support. > > Thanks > Jc > > > -- > +1 919 869 8849 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at rogue-research.com Wed Jun 17 11:21:16 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 17 Jun 2015 11:21:16 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: Message-ID: <20150617152116.417279775@mail.rogue-research.com> Just yesterday someone on vtkusers asked about minimum compiler versions. I could add a paragraph somewhere... would README.md be appropriate? 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 lonni.besancon at gmail.com Wed Jun 17 11:26:02 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Wed, 17 Jun 2015 08:26:02 -0700 (MST) Subject: [vtk-developers] android_native_app_glue.c doesn't exist In-Reply-To: <1434470761121-5732385.post@n5.nabble.com> References: <1434443173378-5732362.post@n5.nabble.com> <9b7ff6aed3c433573591f7920006bd2a@mail.gmail.com> <1434466585533-5732374.post@n5.nabble.com> <42a06a8b52c2689b3115c7c498a934b8@mail.gmail.com> <1434467125303-5732376.post@n5.nabble.com> <484f26a198af0d2c3a58953d9bd351ad@mail.gmail.com> <1434467778943-5732378.post@n5.nabble.com> <1434468260576-5732380.post@n5.nabble.com> <1434470761121-5732385.post@n5.nabble.com> Message-ID: <1434554762716-5732417.post@n5.nabble.com> For other users who might have this error too I set up the path to the android_ndk manually by setting ANDROID_NDK variable directly in the android.mk -- View this message in context: http://vtk.1045678.n5.nabble.com/android-native-app-glue-c-doesn-t-exist-tp5732362p5732417.html Sent from the VTK - Dev mailing list archive at Nabble.com. From lonni.besancon at gmail.com Wed Jun 17 11:29:46 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Wed, 17 Jun 2015 08:29:46 -0700 (MST) Subject: [vtk-developers] Android: undefined reference to vtkRenderWindow::New() Message-ID: <1434554986629-5732418.post@n5.nabble.com> Still trying to build the examples from the VTK Example/Android. I've had several issues that I've managed to solve alone or thanks to the help of the community. Now I'm afraid I don't know where to look at anymore. I was wondering if I could again get some help from the talented people around here :). This is the error I get from ndk-build: Android NDK: WARNING: APP_PLATFORM android-14 is larger than android:minSdkVersion 8 in /Users/lonnibesancon/Documents/workspace/TestNativecopy/AndroidManifest.xml [armeabi-v7a] Compile++ thumb: ndk1 <= native.cxx [armeabi-v7a] Compile thumb : android_native_app_glue <= android_native_app_glue.c [armeabi-v7a] StaticLibrary : libandroid_native_app_glue.a [armeabi-v7a] SharedLibrary : libndk1.so /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkNew.h:66: error: undefined reference to 'vtkRenderWindow::New()' /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkNew.h:66: error: undefined reference to 'vtkRenderer::New()' /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkNew.h:66: error: undefined reference to 'vtkAndroidRenderWindowInteractor::New()' /Users/lonnibesancon/Documents/workspace/TestNativecopy/jni/native.cxx:61: error: undefined reference to 'vtkRenderWindowInteractor::SetRenderWindow(vtkRenderWindow*)' /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkNew.h:66: error: undefined reference to 'vtkSphereSource::New()' /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkNew.h:66: error: undefined reference to 'vtkPolyDataMapper::New()' /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkAlgorithm.h:391: error: undefined reference to 'vtkAlgorithm::GetOutputPort(int)' /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkNew.h:66: error: undefined reference to 'vtkActor::New()' /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkNew.h:66: error: undefined reference to 'vtkConeSource::New()' /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkNew.h:66: error: undefined reference to 'vtkGlyph3D::New()' /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkAlgorithm.h:391: error: undefined reference to 'vtkAlgorithm::GetOutputPort(int)' /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkAlgorithm.h:391: error: undefined reference to 'vtkAlgorithm::GetOutputPort(int)' /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkGlyph3D.h:131: error: undefined reference to 'vtkGlyph3D::SetSourceConnection(int, vtkAlgorithmOutput*)' /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkNew.h:66: error: undefined reference to 'vtkPolyDataMapper::New()' /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkAlgorithm.h:391: error: undefined reference to 'vtkAlgorithm::GetOutputPort(int)' /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkNew.h:66: error: undefined reference to 'vtkActor::New()' /Users/lonnibesancon/Documents/workspace/TestNativecopy/jni/native.cxx:88: error: undefined reference to 'vtkRenderer::AddActor(vtkProp*)' /Users/lonnibesancon/Documents/workspace/TestNativecopy/jni/native.cxx:89: error: undefined reference to 'vtkRenderer::AddActor(vtkProp*)' /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkDebugLeaksManager.h:39: error: undefined reference to 'vtkDebugLeaksManager::vtkDebugLeaksManager()' /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkDebugLeaksManager.h:39: error: undefined reference to 'vtkDebugLeaksManager::~vtkDebugLeaksManager()' /Users/lonnibesancon/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c:190: error: undefined reference to 'AInputQueue_getEvent' /Users/lonnibesancon/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c:192: error: undefined reference to 'AInputQueue_preDispatchEvent' /Users/lonnibesancon/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c:197: error: undefined reference to 'AInputQueue_finishEvent' /Users/lonnibesancon/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c:211: error: undefined reference to 'AConfiguration_new' /Users/lonnibesancon/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c:212: error: undefined reference to 'AConfiguration_fromAssetManager' /Users/lonnibesancon/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c:66: error: undefined reference to 'AConfiguration_getLanguage' /Users/lonnibesancon/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c:67: error: undefined reference to 'AConfiguration_getCountry' /Users/lonnibesancon/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c:223: error: undefined reference to 'ALooper_prepare' /Users/lonnibesancon/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c:224: error: undefined reference to 'ALooper_addFd' /Users/lonnibesancon/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c:179: error: undefined reference to 'AInputQueue_detachLooper' /Users/lonnibesancon/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c:181: error: undefined reference to 'AConfiguration_delete' /Users/lonnibesancon/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c:95: error: undefined reference to 'AInputQueue_detachLooper' /Users/lonnibesancon/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c:100: error: undefined reference to 'AInputQueue_attachLooper' /Users/lonnibesancon/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c:134: error: undefined reference to 'AConfiguration_fromAssetManager' /Users/lonnibesancon/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c:66: error: undefined reference to 'AConfiguration_getLanguage' /Users/lonnibesancon/android-ndk-r10e/sources/android/native_app_glue/android_native_app_glue.c:67: error: undefined reference to 'AConfiguration_getCountry' collect2: error: ld returned 1 exit status make: *** [/Users/lonnibesancon/Documents/workspace/TestNativecopy/obj/local/armeabi-v7a/libndk1.so] Error 1 And here is the content of my android.mk: LOCAL_PATH := $(call my-dir) include $(CLEAR_VARS) # VTK Libs include $(CLEAR_VARS) LOCAL_MODULE := libvtkalglib-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkalglib-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkCommonColor-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkCommonColor-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkCommonComputationalGeometry-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkCommonComputationalGeometry-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkCommonCore-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkCommonCore-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkCommonMath-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkCommonMath-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkCommonMisc-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkCommonMisc-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkCommonSystem-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkCommonSystem-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkCommonTransforms-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkCommonTransforms-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkDICOMParser-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkDICOMParser-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkexpat-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkexpat-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkFiltersCore-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkFiltersCore-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkFiltersExtraction-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkFiltersExtraction-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkFiltersGeneral-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkFiltersGeneral-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkFiltersGeometry-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkFiltersGeometry-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkFiltersModeling-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkFiltersModeling-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkFiltersSources-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkFiltersSources-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkFiltersStatistics-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkFiltersStatistics-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkglew-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkglew-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkImagingCore-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkImagingCore-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkImagingFourier-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkImagingFourier-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkImagingHybrid-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkImagingHybrid-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkInfovisCore-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkInfovisCore-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkInteractionStyle-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkInteractionStyle-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkIOCore-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkIOCore-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkIOGeometry-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkIOGeometry-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkIOImage-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkIOImage-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkIOInfovis-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkIOInfovis-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkIOLegacy-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkIOLegacy-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkIOPLY-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkIOPLY-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkIOXML-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkIOXML-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkIOXMLParser-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkIOXMLParser-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkjpeg-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkjpeg-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkjsoncpp-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkjsoncpp-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtklibxml2-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtklibxml2-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkmetaio-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkmetaio-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkParallelCore-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkParallelCore-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkpng-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkpng-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkRenderingCore-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkRenderingCore-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkRenderingOpenGL2-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkRenderingOpenGL2-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtksys-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtksys-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtktiff-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtktiff-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_MODULE := libvtkzlib-6.3 LOCAL_SRC_FILES = /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/lib/libvtkzlib-6.3.a include $(PREBUILT_STATIC_LIBRARY) include $(CLEAR_VARS) LOCAL_C_INCLUDES := /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/ LOCAL_C_INCLUDES += /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/alglib/ Thanks in advance. LOCAL_C_INCLUDES += /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkexpat/ LOCAL_C_INCLUDES += /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkglew/ LOCAL_C_INCLUDES += /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkjpeg/ LOCAL_C_INCLUDES += /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkjsoncpp/ LOCAL_C_INCLUDES += /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtklibxml2/ LOCAL_C_INCLUDES += /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkmetaio/ LOCAL_C_INCLUDES += /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkpng/ LOCAL_C_INCLUDES += /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtksys/ LOCAL_C_INCLUDES += /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtktiff/ LOCAL_C_INCLUDES += /Users/lonnibesancon/Desktop/VTK/build4/CMakeExternals/Install/vtk-android/include/vtk-6.3/vtkzlib/ LOCAL_STATIC_LIBRARIES := cpufeatures android_native_app_glue ndk_helper LOCAL_CPP_FEATURES := rtti exceptions LOCAL_CPPFLAGS += --std=c++11 LOCAL_LDLIBS := -llog LOCAL_MODULE := ndk1 LOCAL_SRC_FILES := native.cxx include $(BUILD_SHARED_LIBRARY) $(call import-module,android/native_app_glue) -- View this message in context: http://vtk.1045678.n5.nabble.com/Android-undefined-reference-to-vtkRenderWindow-New-tp5732418.html Sent from the VTK - Dev mailing list archive at Nabble.com. From berk.geveci at kitware.com Wed Jun 17 11:50:44 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Wed, 17 Jun 2015 11:50:44 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: <20150617152116.417279775@mail.rogue-research.com> References: <20150617152116.417279775@mail.rogue-research.com> Message-ID: That should be fine for now. We need to restructure the documentation a bit. It is somewhat messy between the in-source doc, Gitlab and Wiki right now... On Wed, Jun 17, 2015 at 11:21 AM, Sean McBride wrote: > Just yesterday someone on vtkusers asked about minimum compiler versions. > > I could add a paragraph somewhere... would README.md be appropriate? > > 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 sean at rogue-research.com Wed Jun 17 12:26:25 2015 From: sean at rogue-research.com (Sean McBride) Date: Wed, 17 Jun 2015 12:26:25 -0400 Subject: [vtk-developers] [vtkusers] Removing support for VS 8 and GCC < 4.1 In-Reply-To: References: <20150617152116.417279775@mail.rogue-research.com> Message-ID: <20150617162625.64327103@mail.rogue-research.com> On Wed, 17 Jun 2015 11:50:44 -0400, Berk Geveci said: >That should be fine for now. We need to restructure the documentation a >bit. It is somewhat messy between the in-source doc, Gitlab and Wiki right >now... So here's a *very* rough draft: Please add comments there... I have no idea what our minimum Windows, icc, etc. are... 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 lonni.besancon at gmail.com Wed Jun 17 13:16:56 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Wed, 17 Jun 2015 10:16:56 -0700 (MST) Subject: [vtk-developers] Android: undefined reference to vtkRenderWindow::New() In-Reply-To: <1434554986629-5732418.post@n5.nabble.com> References: <1434554986629-5732418.post@n5.nabble.com> Message-ID: <1434561416248-5732424.post@n5.nabble.com> I've seen that it's possible to use: LOCAL_ALLOW_UNDEFINED_SYMBOLS:=true but i'm not sure it will solve my problem cause everything might be ignored until runtime and then it will crash no? -- View this message in context: http://vtk.1045678.n5.nabble.com/Android-undefined-reference-to-vtkRenderWindow-New-tp5732418p5732424.html Sent from the VTK - Dev mailing list archive at Nabble.com. From majcjc at gmail.com Wed Jun 17 21:11:42 2015 From: majcjc at gmail.com (Lin M) Date: Wed, 17 Jun 2015 21:11:42 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> Message-ID: Hi Dr. Thompson, Sorry for late reply. Since the midterm is coming, I'll definitely speed up the development from now on. I have a question about the class design in your last email. To my understanding, control points for one patch is stored in a vtkDataArray. Do you mean store multiple vtkDataArray regarding to multiple patches in the vtkDataObject? If so, what class do I need to use for vtkDataObject? Best, Lin On Wed, Jun 10, 2015 at 2:39 PM, David Thompson wrote: > Hi Lin, > > > I have made it support 3D ellipse with function ... > > Great! > > > As you can see in the python test, I call this function 4 times for each > quadrant to generate the entire ellipse. Since we need to support multiple > patches, I think it's better to define a new dataset class for bezier > patches as you mentioned before about creating a new vtkControlPoints > class that inherits from vtkPoints and allows for an extra coordinate. > > Rather than create new dataset types, I would like to use existing > datatypes to store the data and make an adaptor to iterate over them. That > way existing pipelines could modify scalar values defined on control points > (and perhaps even patches). For instance, B-splines could be represented as > a vtkStructuredGrid whose FieldData contains a special knot array (special > in the sense that the array must be of the proper size and with a fixed > name like "_vtkKnotVector"). > > The adaptor would take a vtkDataObject as input and provide iterator-style > access to each patch defined by the dataset. Specific subclasses of the > adaptor would be B-splines (which expect the vtkDataObject to be a > vtkStructuredGrid) or T-splines (which might expect a vtkUniformGridAMR) or > even point-based splines (PB-splines as defined in Sederberg's T-spline > paper, which could expect any dataset derived vtkPointSet). > > class vtkBezierPatchAdaptor : public vtkObject > { > public: > virtual void SetControlPointData(vtkDataObject* controlPointData); > vtkGetObjectMacro(vtkDataObject,ControlPointData); > > // Methods to iterate over patches: > virtual void Begin() = 0; > virtual bool IsAtEnd() = 0; > virtual bool GoToPatch(vtkIdType patchId) = 0; // random access iteration > virtual bool Next() = 0; > > // Methods to access the current patch: > virtual int GetPatchDimension() const = 0; > virtual void GetPatchShape() const = 0; > // returns VTK_TRIANGLE/VTK_QUAD when PatchDimension==2, > // returns VTK_HEXAHEDRON/VTK_TETRA when PatchDimension==3 > virtual void GetPatchDegree(int* degreeOut) const = 0; > virtual void GetPatchParameterRange(double* paramsOut) const = 0; > virtual void GetPatchPoints(vtkPoints* pointsOut) const = 0; > > // Some helper methods that would make Python wrappings usable: > int GetPatchDegree(int dim) const > { > std::vector degree(this->GetPatchDimension()); > this->GetPatchDegree(°ree[0]); > return degree[dim]; > } > void GetPatchParameterRange(int dim, double paramRange[2]) > { > std::vector range(2 * this->GetPatchDimension()); > this->GetPatchDegree(&range[0]); > paramRange[0] = [2 * dim]; > paramRange[1] = [2 * dim + 1]; > } > > protected: > vtkDataObject* ControlPointData; > }; > > The B-spline subclass could then iterate over patches by keeping a current > "cell ID," which would be incremented by calling Next(). When asked for the > *patch* points (not the input points), the adaptor would create a > vtkMappedDataArray (see http://www.vtk.org/Wiki/VTK/InSituDataStructure > for more information) that did not copy control point coordinates from its > ControlPointData->GetPoints() but instead used the implicit connectivity to > provide access to underlying B-spline points. > > For example, consider the simple case of a rectangular B-spline with > degree 1 (bi-linear). We might be given a 5x6 grid of control points as > input and asked to iterate over all the patches. Each patch is simply a > quadrilateral, and there are (5-1)*(6-1) = 20 of them. > > adaptor->Begin(); // would initialize an internal "cell ID" to 0 > adaptor->IsAtEnd(); // would return false for "cell ID" values in [0,19] > and true otherwise. > adaptor->GetPatchDimension(); // would return 2 > adaptor->GetPatchShape(); // would return VTK_QUAD > adaptor->GetPatchDegree(degreeOut); // would populate degreeOut with > [1,1] > adaptor->GetPatchPoints(pointsOut); // would populate pointsOut with a > vtkMappedDataArray. > > The vtkMappedDataArray would report having 4 tuples (one for each corner > of the quad... when the degree is higher, is would report the product of > (degreeOut[i]+1) for all i in GetPatchDimension()). The actual points > reported would depend on the "cell ID" in the adaptor. > > I have not figured out yet how the "w" homogeneous coordinate would work > with vtkPoints. A different adaptor API might work better (keeping the "w" > coordinate separate from the other points). > > > Another question is that currently the domain of parameter coordinate is > [0, 1] for each patch. Do you think it's better to make the domain > continuously, namely [0, 0.25] for the first quadrant, [0.25, 0.75] for the > second quadrant, etc? > > If we focus on the B-spline adaptor above, we get that for free since the > returned knot vector could be normalized to the range [0,1]. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Wed Jun 17 22:22:39 2015 From: david.thompson at kitware.com (David Thompson) Date: Wed, 17 Jun 2015 22:22:39 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> Message-ID: <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> Hi Lin, > Sorry for late reply. Since the midterm is coming, I'll definitely speed up the development from now on. We both need to do a little more work. I have been looking at how to read data from PetIGA so we can show some actual simulation data and have some 3-D volumetric examples. It would be nice to have a patch ready to merge into VTK's master branch at the midterm that provides spline interpolation and tests it for all 3 parametric dimensions (curves, surfaces, and volumes). The means producing triangles and tetrahedra, not just polylines. > I have a question about the class design in your last email. To my understanding, control points for one patch is stored in a vtkDataArray. Close. I think that we should use the vtkMappedDataArray class to hold control points for multiple patches but program it to appear as if points for each individual patch are stored in patch-order. > Do you mean store multiple vtkDataArray regarding to multiple patches in the vtkDataObject? There would be one data array to hold point coordinates, but other arrays would hold simulation variables like temperature, pressure, velocity, and so on. > If so, what class do I need to use for vtkDataObject? The class outline below is an abstract class. A concrete implementation for NURBs would require the base class's ControlPointData to be an instance of vtkStructuredGrid. A T-spline implementation might expect ControlPointData to be a vtkUnstructuredGrid. I think all we should do this summer is the NURBs case. David > >> On Wed, Jun 10, 2015 at 2:39 PM, David Thompson wrote: >> Hi Lin, >> >> > I have made it support 3D ellipse with function ... >> >> Great! >> >> > As you can see in the python test, I call this function 4 times for each quadrant to generate the entire ellipse. Since we need to support multiple patches, I think it's better to define a new dataset class for bezier patches as you mentioned before about creating a new vtkControlPoints class that inherits from vtkPoints and allows for an extra coordinate. >> >> Rather than create new dataset types, I would like to use existing datatypes to store the data and make an adaptor to iterate over them. That way existing pipelines could modify scalar values defined on control points (and perhaps even patches). For instance, B-splines could be represented as a vtkStructuredGrid whose FieldData contains a special knot array (special in the sense that the array must be of the proper size and with a fixed name like "_vtkKnotVector"). >> >> The adaptor would take a vtkDataObject as input and provide iterator-style access to each patch defined by the dataset. Specific subclasses of the adaptor would be B-splines (which expect the vtkDataObject to be a vtkStructuredGrid) or T-splines (which might expect a vtkUniformGridAMR) or even point-based splines (PB-splines as defined in Sederberg's T-spline paper, which could expect any dataset derived vtkPointSet). >> >> class vtkBezierPatchAdaptor : public vtkObject >> { >> public: >> virtual void SetControlPointData(vtkDataObject* controlPointData); >> vtkGetObjectMacro(vtkDataObject,ControlPointData); >> >> // Methods to iterate over patches: >> virtual void Begin() = 0; >> virtual bool IsAtEnd() = 0; >> virtual bool GoToPatch(vtkIdType patchId) = 0; // random access iteration >> virtual bool Next() = 0; >> >> // Methods to access the current patch: >> virtual int GetPatchDimension() const = 0; >> virtual void GetPatchShape() const = 0; >> // returns VTK_TRIANGLE/VTK_QUAD when PatchDimension==2, >> // returns VTK_HEXAHEDRON/VTK_TETRA when PatchDimension==3 >> virtual void GetPatchDegree(int* degreeOut) const = 0; >> virtual void GetPatchParameterRange(double* paramsOut) const = 0; >> virtual void GetPatchPoints(vtkPoints* pointsOut) const = 0; >> >> // Some helper methods that would make Python wrappings usable: >> int GetPatchDegree(int dim) const >> { >> std::vector degree(this->GetPatchDimension()); >> this->GetPatchDegree(°ree[0]); >> return degree[dim]; >> } >> void GetPatchParameterRange(int dim, double paramRange[2]) >> { >> std::vector range(2 * this->GetPatchDimension()); >> this->GetPatchDegree(&range[0]); >> paramRange[0] = [2 * dim]; >> paramRange[1] = [2 * dim + 1]; >> } >> >> protected: >> vtkDataObject* ControlPointData; >> }; >> >> The B-spline subclass could then iterate over patches by keeping a current "cell ID," which would be incremented by calling Next(). When asked for the *patch* points (not the input points), the adaptor would create a vtkMappedDataArray (see http://www.vtk.org/Wiki/VTK/InSituDataStructure for more information) that did not copy control point coordinates from its ControlPointData->GetPoints() but instead used the implicit connectivity to provide access to underlying B-spline points. >> >> For example, consider the simple case of a rectangular B-spline with degree 1 (bi-linear). We might be given a 5x6 grid of control points as input and asked to iterate over all the patches. Each patch is simply a quadrilateral, and there are (5-1)*(6-1) = 20 of them. >> >> adaptor->Begin(); // would initialize an internal "cell ID" to 0 >> adaptor->IsAtEnd(); // would return false for "cell ID" values in [0,19] and true otherwise. >> adaptor->GetPatchDimension(); // would return 2 >> adaptor->GetPatchShape(); // would return VTK_QUAD >> adaptor->GetPatchDegree(degreeOut); // would populate degreeOut with [1,1] >> adaptor->GetPatchPoints(pointsOut); // would populate pointsOut with a vtkMappedDataArray. >> >> The vtkMappedDataArray would report having 4 tuples (one for each corner of the quad... when the degree is higher, is would report the product of (degreeOut[i]+1) for all i in GetPatchDimension()). The actual points reported would depend on the "cell ID" in the adaptor. >> >> I have not figured out yet how the "w" homogeneous coordinate would work with vtkPoints. A different adaptor API might work better (keeping the "w" coordinate separate from the other points). >> >> > Another question is that currently the domain of parameter coordinate is [0, 1] for each patch. Do you think it's better to make the domain continuously, namely [0, 0.25] for the first quadrant, [0.25, 0.75] for the second quadrant, etc? >> >> If we focus on the B-spline adaptor above, we get that for free since the returned knot vector could be normalized to the range [0,1]. >> >> David > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Thu Jun 18 06:13:40 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Thu, 18 Jun 2015 03:13:40 -0700 (MST) Subject: [vtk-developers] Building VTK with QT5.4 Windows 8 In-Reply-To: <1434549883778-5732412.post@n5.nabble.com> References: <1434546846947-5732403.post@n5.nabble.com> <55817942.30802@student.hpi.uni-potsdam.de> <1434549029258-5732410.post@n5.nabble.com> <55817B9F.3010109@student.hpi.uni-potsdam.de> <1434549883778-5732412.post@n5.nabble.com> Message-ID: <1434622420322-5732429.post@n5.nabble.com> I'm afraid I'm stuck with Qt again. I have tried more or less everything and I've read a lot of stuff on here but it still doesn't work. I've followed the steps and created a qt project. I now have a QVTKWidget qtwidget that I just try to resize. Unfortunately, when running my code I get: Drawing.obj : error LNK2019: symbole externe non r?solu "__declspec(dllimport) public: __thiscall QVTKWidget::QVTKWidget(class QWidget *,class QFlags)" (__imp_??0QVTKWidget@@QAE at PAVQWidget@@V?$QFlags at W4WindowType@Qt@@@@@Z) r?f?renc? dans la fonction "public: __thiscall Drawing::Drawing(void)" (??0Drawing@@QAE at XZ) 1>Drawing.obj : error LNK2019: symbole externe non r?solu "__declspec(dllimport) public: virtual __thiscall QVTKWidget::~QVTKWidget(void)" (__imp_??1QVTKWidget@@UAE at XZ) r?f?renc? dans la fonction "public: __thiscall Drawing::~Drawing(void)" (??1Drawing@@QAE at XZ) Now I've seen that this could be resolved by building Qt support for vtk in release conf and not debug, so that what I did but I still get the error. Then, I saw here http://www.vtk.org/Wiki/VTK/Tutorials/QtSetup that I have to move a .lib and a .dll. Problem is that in my built configuration of vtk I only have the .dll. The .lib is just found in the cmake generated files before generating with visual studio. Would you have an idea of what happened? Thanks in advance :) -- View this message in context: http://vtk.1045678.n5.nabble.com/Building-VTK-with-QT5-4-Windows-8-tp5732403p5732429.html Sent from the VTK - Dev mailing list archive at Nabble.com. From david.thompson at kitware.com Thu Jun 18 10:47:41 2015 From: david.thompson at kitware.com (David Thompson) Date: Thu, 18 Jun 2015 10:47:41 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> Message-ID: Hi Lin, > From some examples I saw, usually we put some points in vtkPoints, store the connectivity in cellArray and add them to a dataset (vtkPolyData, vtkStructuredGrid or vtkUnstructureGrid). So is that we store the control point of multiple patches in the vtkPoints where we replace the vtkDataArray with vtkMappedDataArray now? And in a vtkMappedDataArray, we store all the points for all patches together but we overwrite how to iterate the array. That is nearly correct. We will accept vtkDataObject* ControlPointData; from the user. For the case we will implement first, ControlPointData's actual type will be the vtkStructuredGrid subclass of vtkDataObject. The vtkStructuredGrid instance can hold many user-supplied vtkDataArray instances: vtkStructuredGrid* structuredControlPoints = vtkStructuredGrid::SafeDownCast(ControlPointData); // Control points to map from parameter-space to world coordinates: vtkDataArray* geometricControlPoints = structuredControlPoints->GetPoints()->GetData(); // Control points to map from paramter-space to scalar fields: vtkDataSetAttributes* scalarFields = structuredControlPoints->GetPointData(); vtkIdType numScalarFields = scalarFields->GetNumberOfArrays(); for (vtkIdType i = 0; i < numScalarFields; ++i) { // scalarFieldControlPoints will hold things like temperature, pressure, etc.: vtkDataArray* scalarFieldControlPoints = scalarFields->GetArray(i); } Because the user supplies these arrays, we cannot force them to be vtkMappedDataArray. Instead, we can make a vtkMappedDataArray subclass that owns a reference to one of the arrays above and only returns one patch's values from the user-supplied array (which holds the values for all patches in the spline). The BezierPatchAdaptor below would return instances of our vtkMappedDataArray when its GetPatchPoints method is called. Now that I've written some more out, it looks like the API should be changed a little bit so that users can ask for a particular array (geometricControlPoints or scalarFieldControlPoints): class vtkBezierPatchAdaptor : public vtkObject { public: virtual void SetControlPointData(vtkDataObject* controlPointData); vtkGetObjectMacro(vtkDataObject,ControlPointData); // Methods to iterate over patches: // ... same as below ... // Methods to access the current patch: // ... virtual vtkSmartPointer GetPatchPoints(int scalarField) const = 0; // ... }; This way, GetPatchPoints() could return the vtkMappedDataArray for geometricControlPoints when the "int scalarField" argument is negative value and a vtkMappedDataArray for one of the scalarFieldControlPoints arrays when scalarField is positive. Having GetPatchPoints() return a smart pointer to a vtkMappedDataArray subclass would also get around the issue that vtkPoints expects its vtkDataArray to have 3 components per tuple (where ours will have 4 for geometricControlPoints or an arbitrary number for scalarFieldControlPoints). The vtkMappedDataArray instances would own a weak reference back the vtkBezierPatchAdaptor which created them and a weak reference to the geometricControlPoints or scalarFieldControlPoints array it draws values from. When vtkBezierPatchAdaptor::Next() or vtkBezierPatchAdaptor::GoToPatch() is called, the adaptor would iterate over all of the vtkMappedDataArray instances it owns and change an internal variable so they would return values for the proper patch. That way the vtkMappedDataArray instances only have to be created once for each spline dataset, not once per patch. Is that clear enough, or should I sketch out a header file for our vtkMappedDataArray subclass? David > On Wed, Jun 17, 2015 at 10:22 PM, David Thompson wrote: > Hi Lin, > >> Sorry for late reply. Since the midterm is coming, I'll definitely speed up the development from now on. > > We both need to do a little more work. I have been looking at how to read data from PetIGA so we can show some actual simulation data and have some 3-D volumetric examples. > > It would be nice to have a patch ready to merge into VTK's master branch at the midterm that provides spline interpolation and tests it for all 3 parametric dimensions (curves, surfaces, and volumes). The means producing triangles and tetrahedra, not just polylines. > >> I have a question about the class design in your last email. To my understanding, control points for one patch is stored in a vtkDataArray. > > Close. I think that we should use the vtkMappedDataArray class to hold control points for multiple patches but program it to appear as if points for each individual patch are stored in patch-order. > >> Do you mean store multiple vtkDataArray regarding to multiple patches in the vtkDataObject? > > There would be one data array to hold point coordinates, but other arrays would hold simulation variables like temperature, pressure, velocity, and so on. > >> If so, what class do I need to use for vtkDataObject? > > The class outline below is an abstract class. A concrete implementation for NURBs would require the base class's ControlPointData to be an instance of vtkStructuredGrid. A T-spline implementation might expect ControlPointData to be a vtkUnstructuredGrid. I think all we should do this summer is the NURBs case. > > David > >> >> On Wed, Jun 10, 2015 at 2:39 PM, David Thompson wrote: >> Hi Lin, >> >> > I have made it support 3D ellipse with function ... >> >> Great! >> >> > As you can see in the python test, I call this function 4 times for each quadrant to generate the entire ellipse. Since we need to support multiple patches, I think it's better to define a new dataset class for bezier patches as you mentioned before about creating a new vtkControlPoints class that inherits from vtkPoints and allows for an extra coordinate. >> >> Rather than create new dataset types, I would like to use existing datatypes to store the data and make an adaptor to iterate over them. That way existing pipelines could modify scalar values defined on control points (and perhaps even patches). For instance, B-splines could be represented as a vtkStructuredGrid whose FieldData contains a special knot array (special in the sense that the array must be of the proper size and with a fixed name like "_vtkKnotVector"). >> >> The adaptor would take a vtkDataObject as input and provide iterator-style access to each patch defined by the dataset. Specific subclasses of the adaptor would be B-splines (which expect the vtkDataObject to be a vtkStructuredGrid) or T-splines (which might expect a vtkUniformGridAMR) or even point-based splines (PB-splines as defined in Sederberg's T-spline paper, which could expect any dataset derived vtkPointSet). >> >> class vtkBezierPatchAdaptor : public vtkObject >> { >> public: >> virtual void SetControlPointData(vtkDataObject* controlPointData); >> vtkGetObjectMacro(vtkDataObject,ControlPointData); >> >> // Methods to iterate over patches: >> virtual void Begin() = 0; >> virtual bool IsAtEnd() = 0; >> virtual bool GoToPatch(vtkIdType patchId) = 0; // random access iteration >> virtual bool Next() = 0; >> >> // Methods to access the current patch: >> virtual int GetPatchDimension() const = 0; >> virtual void GetPatchShape() const = 0; >> // returns VTK_TRIANGLE/VTK_QUAD when PatchDimension==2, >> // returns VTK_HEXAHEDRON/VTK_TETRA when PatchDimension==3 >> virtual void GetPatchDegree(int* degreeOut) const = 0; >> virtual void GetPatchParameterRange(double* paramsOut) const = 0; >> virtual void GetPatchPoints(vtkPoints* pointsOut) const = 0; >> >> // Some helper methods that would make Python wrappings usable: >> int GetPatchDegree(int dim) const >> { >> std::vector degree(this->GetPatchDimension()); >> this->GetPatchDegree(°ree[0]); >> return degree[dim]; >> } >> void GetPatchParameterRange(int dim, double paramRange[2]) >> { >> std::vector range(2 * this->GetPatchDimension()); >> this->GetPatchDegree(&range[0]); >> paramRange[0] = [2 * dim]; >> paramRange[1] = [2 * dim + 1]; >> } >> >> protected: >> vtkDataObject* ControlPointData; >> }; >> >> The B-spline subclass could then iterate over patches by keeping a current "cell ID," which would be incremented by calling Next(). When asked for the *patch* points (not the input points), the adaptor would create a vtkMappedDataArray (see http://www.vtk.org/Wiki/VTK/InSituDataStructure for more information) that did not copy control point coordinates from its ControlPointData->GetPoints() but instead used the implicit connectivity to provide access to underlying B-spline points. >> >> For example, consider the simple case of a rectangular B-spline with degree 1 (bi-linear). We might be given a 5x6 grid of control points as input and asked to iterate over all the patches. Each patch is simply a quadrilateral, and there are (5-1)*(6-1) = 20 of them. >> >> adaptor->Begin(); // would initialize an internal "cell ID" to 0 >> adaptor->IsAtEnd(); // would return false for "cell ID" values in [0,19] and true otherwise. >> adaptor->GetPatchDimension(); // would return 2 >> adaptor->GetPatchShape(); // would return VTK_QUAD >> adaptor->GetPatchDegree(degreeOut); // would populate degreeOut with [1,1] >> adaptor->GetPatchPoints(pointsOut); // would populate pointsOut with a vtkMappedDataArray. >> >> The vtkMappedDataArray would report having 4 tuples (one for each corner of the quad... when the degree is higher, is would report the product of (degreeOut[i]+1) for all i in GetPatchDimension()). The actual points reported would depend on the "cell ID" in the adaptor. >> >> I have not figured out yet how the "w" homogeneous coordinate would work with vtkPoints. A different adaptor API might work better (keeping the "w" coordinate separate from the other points). >> >> > Another question is that currently the domain of parameter coordinate is [0, 1] for each patch. Do you think it's better to make the domain continuously, namely [0, 0.25] for the first quadrant, [0.25, 0.75] for the second quadrant, etc? >> >> If we focus on the B-spline adaptor above, we get that for free since the returned knot vector could be normalized to the range [0,1]. >> >> David >> > From majcjc at gmail.com Thu Jun 18 21:08:35 2015 From: majcjc at gmail.com (Lin M) Date: Thu, 18 Jun 2015 21:08:35 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> Message-ID: Hi Dr. Thompson, I have added one commit which contains a vtkMappedDataArray subclass but I'm not sure I totally get the idea about the in-situ data structures. Can you take a look at it please? ( https://gitlab.kitware.com/splines/vtk/merge_requests/4) Best, Lin On Thu, Jun 18, 2015 at 10:47 AM, David Thompson wrote: > Hi Lin, > > > From some examples I saw, usually we put some points in vtkPoints, store > the connectivity in cellArray and add them to a dataset (vtkPolyData, > vtkStructuredGrid or vtkUnstructureGrid). So is that we store the control > point of multiple patches in the vtkPoints where we replace the > vtkDataArray with vtkMappedDataArray now? And in a vtkMappedDataArray, we > store all the points for all patches together but we overwrite how to > iterate the array. > > That is nearly correct. We will accept > > vtkDataObject* ControlPointData; > > from the user. For the case we will implement first, ControlPointData's > actual type will be the vtkStructuredGrid subclass of vtkDataObject. The > vtkStructuredGrid instance can hold many user-supplied vtkDataArray > instances: > > vtkStructuredGrid* structuredControlPoints = > vtkStructuredGrid::SafeDownCast(ControlPointData); > > // Control points to map from parameter-space to world coordinates: > vtkDataArray* geometricControlPoints = > structuredControlPoints->GetPoints()->GetData(); > > // Control points to map from paramter-space to scalar fields: > vtkDataSetAttributes* scalarFields = > structuredControlPoints->GetPointData(); > vtkIdType numScalarFields = scalarFields->GetNumberOfArrays(); > for (vtkIdType i = 0; i < numScalarFields; ++i) > { // scalarFieldControlPoints will hold things like temperature, > pressure, etc.: > vtkDataArray* scalarFieldControlPoints = scalarFields->GetArray(i); > } > > Because the user supplies these arrays, we cannot force them to be > vtkMappedDataArray. Instead, we can make a vtkMappedDataArray subclass that > owns a reference to one of the arrays above and only returns one patch's > values from the user-supplied array (which holds the values for all patches > in the spline). > > The BezierPatchAdaptor below would return instances of our > vtkMappedDataArray when its GetPatchPoints method is called. Now that I've > written some more out, it looks like the API should be changed a little bit > so that users can ask for a particular array (geometricControlPoints or > scalarFieldControlPoints): > > class vtkBezierPatchAdaptor : public vtkObject > { > public: > virtual void SetControlPointData(vtkDataObject* controlPointData); > vtkGetObjectMacro(vtkDataObject,ControlPointData); > > // Methods to iterate over patches: > // ... same as below ... > > // Methods to access the current patch: > // ... > virtual vtkSmartPointer GetPatchPoints(int scalarField) > const = 0; > // ... > }; > > This way, GetPatchPoints() could return the vtkMappedDataArray for > geometricControlPoints when the "int scalarField" argument is negative > value and a vtkMappedDataArray for one of the scalarFieldControlPoints > arrays when scalarField is positive. > > Having GetPatchPoints() return a smart pointer to a vtkMappedDataArray > subclass would also get around the issue that vtkPoints expects its > vtkDataArray to have 3 components per tuple (where ours will have 4 for > geometricControlPoints or an arbitrary number for scalarFieldControlPoints). > > The vtkMappedDataArray instances would own a weak reference back the > vtkBezierPatchAdaptor which created them and a weak reference to the > geometricControlPoints or scalarFieldControlPoints array it draws values > from. When vtkBezierPatchAdaptor::Next() or > vtkBezierPatchAdaptor::GoToPatch() is called, the adaptor would iterate > over all of the vtkMappedDataArray instances it owns and change an internal > variable so they would return values for the proper patch. That way the > vtkMappedDataArray instances only have to be created once for each spline > dataset, not once per patch. > > Is that clear enough, or should I sketch out a header file for our > vtkMappedDataArray subclass? > > David > > > On Wed, Jun 17, 2015 at 10:22 PM, David Thompson < > david.thompson at kitware.com> wrote: > > Hi Lin, > > > >> Sorry for late reply. Since the midterm is coming, I'll definitely > speed up the development from now on. > > > > We both need to do a little more work. I have been looking at how to > read data from PetIGA so we can show some actual simulation data and have > some 3-D volumetric examples. > > > > It would be nice to have a patch ready to merge into VTK's master branch > at the midterm that provides spline interpolation and tests it for all 3 > parametric dimensions (curves, surfaces, and volumes). The means producing > triangles and tetrahedra, not just polylines. > > > >> I have a question about the class design in your last email. To my > understanding, control points for one patch is stored in a vtkDataArray. > > > > Close. I think that we should use the vtkMappedDataArray class to hold > control points for multiple patches but program it to appear as if points > for each individual patch are stored in patch-order. > > > >> Do you mean store multiple vtkDataArray regarding to multiple patches > in the vtkDataObject? > > > > There would be one data array to hold point coordinates, but other > arrays would hold simulation variables like temperature, pressure, > velocity, and so on. > > > >> If so, what class do I need to use for vtkDataObject? > > > > The class outline below is an abstract class. A concrete implementation > for NURBs would require the base class's ControlPointData to be an > instance of vtkStructuredGrid. A T-spline implementation might expect > ControlPointData to be a vtkUnstructuredGrid. I think all we should do this > summer is the NURBs case. > > > > David > > > >> > >> On Wed, Jun 10, 2015 at 2:39 PM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hi Lin, > >> > >> > I have made it support 3D ellipse with function ... > >> > >> Great! > >> > >> > As you can see in the python test, I call this function 4 times for > each quadrant to generate the entire ellipse. Since we need to support > multiple patches, I think it's better to define a new dataset class for > bezier patches as you mentioned before about creating a new > vtkControlPoints class that inherits from vtkPoints and allows for an extra > coordinate. > >> > >> Rather than create new dataset types, I would like to use existing > datatypes to store the data and make an adaptor to iterate over them. That > way existing pipelines could modify scalar values defined on control points > (and perhaps even patches). For instance, B-splines could be represented as > a vtkStructuredGrid whose FieldData contains a special knot array (special > in the sense that the array must be of the proper size and with a fixed > name like "_vtkKnotVector"). > >> > >> The adaptor would take a vtkDataObject as input and provide > iterator-style access to each patch defined by the dataset. Specific > subclasses of the adaptor would be B-splines (which expect the > vtkDataObject to be a vtkStructuredGrid) or T-splines (which might expect a > vtkUniformGridAMR) or even point-based splines (PB-splines as defined in > Sederberg's T-spline paper, which could expect any dataset derived > vtkPointSet). > >> > >> class vtkBezierPatchAdaptor : public vtkObject > >> { > >> public: > >> virtual void SetControlPointData(vtkDataObject* controlPointData); > >> vtkGetObjectMacro(vtkDataObject,ControlPointData); > >> > >> // Methods to iterate over patches: > >> virtual void Begin() = 0; > >> virtual bool IsAtEnd() = 0; > >> virtual bool GoToPatch(vtkIdType patchId) = 0; // random access > iteration > >> virtual bool Next() = 0; > >> > >> // Methods to access the current patch: > >> virtual int GetPatchDimension() const = 0; > >> virtual void GetPatchShape() const = 0; > >> // returns VTK_TRIANGLE/VTK_QUAD when PatchDimension==2, > >> // returns VTK_HEXAHEDRON/VTK_TETRA when PatchDimension==3 > >> virtual void GetPatchDegree(int* degreeOut) const = 0; > >> virtual void GetPatchParameterRange(double* paramsOut) const = 0; > >> virtual void GetPatchPoints(vtkPoints* pointsOut) const = 0; > >> > >> // Some helper methods that would make Python wrappings usable: > >> int GetPatchDegree(int dim) const > >> { > >> std::vector degree(this->GetPatchDimension()); > >> this->GetPatchDegree(°ree[0]); > >> return degree[dim]; > >> } > >> void GetPatchParameterRange(int dim, double paramRange[2]) > >> { > >> std::vector range(2 * this->GetPatchDimension()); > >> this->GetPatchDegree(&range[0]); > >> paramRange[0] = [2 * dim]; > >> paramRange[1] = [2 * dim + 1]; > >> } > >> > >> protected: > >> vtkDataObject* ControlPointData; > >> }; > >> > >> The B-spline subclass could then iterate over patches by keeping a > current "cell ID," which would be incremented by calling Next(). When asked > for the *patch* points (not the input points), the adaptor would create a > vtkMappedDataArray (see http://www.vtk.org/Wiki/VTK/InSituDataStructure > for more information) that did not copy control point coordinates from its > ControlPointData->GetPoints() but instead used the implicit connectivity to > provide access to underlying B-spline points. > >> > >> For example, consider the simple case of a rectangular B-spline with > degree 1 (bi-linear). We might be given a 5x6 grid of control points as > input and asked to iterate over all the patches. Each patch is simply a > quadrilateral, and there are (5-1)*(6-1) = 20 of them. > >> > >> adaptor->Begin(); // would initialize an internal "cell ID" to 0 > >> adaptor->IsAtEnd(); // would return false for "cell ID" values in > [0,19] and true otherwise. > >> adaptor->GetPatchDimension(); // would return 2 > >> adaptor->GetPatchShape(); // would return VTK_QUAD > >> adaptor->GetPatchDegree(degreeOut); // would populate degreeOut with > [1,1] > >> adaptor->GetPatchPoints(pointsOut); // would populate pointsOut with > a vtkMappedDataArray. > >> > >> The vtkMappedDataArray would report having 4 tuples (one for each > corner of the quad... when the degree is higher, is would report the > product of (degreeOut[i]+1) for all i in GetPatchDimension()). The actual > points reported would depend on the "cell ID" in the adaptor. > >> > >> I have not figured out yet how the "w" homogeneous coordinate would > work with vtkPoints. A different adaptor API might work better (keeping the > "w" coordinate separate from the other points). > >> > >> > Another question is that currently the domain of parameter coordinate > is [0, 1] for each patch. Do you think it's better to make the domain > continuously, namely [0, 0.25] for the first quadrant, [0.25, 0.75] for the > second quadrant, etc? > >> > >> If we focus on the B-spline adaptor above, we get that for free since > the returned knot vector could be normalized to the range [0,1]. > >> > >> David > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Thu Jun 18 21:11:30 2015 From: david.thompson at kitware.com (David Thompson) Date: Thu, 18 Jun 2015 21:11:30 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> Message-ID: <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> Hi Lin, It looks like you forgot to add the header and implementation files to the commit. David > On Jun 18, 2015, at 9:08 PM, Lin M wrote: > > Hi Dr. Thompson, > > I have added one commit which contains a vtkMappedDataArray subclass but I'm not sure I totally get the idea about the in-situ data structures. Can you take a look at it please? (https://gitlab.kitware.com/splines/vtk/merge_requests/4) > > Best, > Lin > > On Thu, Jun 18, 2015 at 10:47 AM, David Thompson wrote: > Hi Lin, > > > From some examples I saw, usually we put some points in vtkPoints, store the connectivity in cellArray and add them to a dataset (vtkPolyData, vtkStructuredGrid or vtkUnstructureGrid). So is that we store the control point of multiple patches in the vtkPoints where we replace the vtkDataArray with vtkMappedDataArray now? And in a vtkMappedDataArray, we store all the points for all patches together but we overwrite how to iterate the array. > > That is nearly correct. We will accept > > vtkDataObject* ControlPointData; > > from the user. For the case we will implement first, ControlPointData's actual type will be the vtkStructuredGrid subclass of vtkDataObject. The vtkStructuredGrid instance can hold many user-supplied vtkDataArray instances: > > vtkStructuredGrid* structuredControlPoints = > vtkStructuredGrid::SafeDownCast(ControlPointData); > > // Control points to map from parameter-space to world coordinates: > vtkDataArray* geometricControlPoints = > structuredControlPoints->GetPoints()->GetData(); > > // Control points to map from paramter-space to scalar fields: > vtkDataSetAttributes* scalarFields = structuredControlPoints->GetPointData(); > vtkIdType numScalarFields = scalarFields->GetNumberOfArrays(); > for (vtkIdType i = 0; i < numScalarFields; ++i) > { // scalarFieldControlPoints will hold things like temperature, pressure, etc.: > vtkDataArray* scalarFieldControlPoints = scalarFields->GetArray(i); > } > > Because the user supplies these arrays, we cannot force them to be vtkMappedDataArray. Instead, we can make a vtkMappedDataArray subclass that owns a reference to one of the arrays above and only returns one patch's values from the user-supplied array (which holds the values for all patches in the spline). > > The BezierPatchAdaptor below would return instances of our vtkMappedDataArray when its GetPatchPoints method is called. Now that I've written some more out, it looks like the API should be changed a little bit so that users can ask for a particular array (geometricControlPoints or scalarFieldControlPoints): > > class vtkBezierPatchAdaptor : public vtkObject > { > public: > virtual void SetControlPointData(vtkDataObject* controlPointData); > vtkGetObjectMacro(vtkDataObject,ControlPointData); > > // Methods to iterate over patches: > // ... same as below ... > > // Methods to access the current patch: > // ... > virtual vtkSmartPointer GetPatchPoints(int scalarField) const = 0; > // ... > }; > > This way, GetPatchPoints() could return the vtkMappedDataArray for geometricControlPoints when the "int scalarField" argument is negative value and a vtkMappedDataArray for one of the scalarFieldControlPoints arrays when scalarField is positive. > > Having GetPatchPoints() return a smart pointer to a vtkMappedDataArray subclass would also get around the issue that vtkPoints expects its vtkDataArray to have 3 components per tuple (where ours will have 4 for geometricControlPoints or an arbitrary number for scalarFieldControlPoints). > > The vtkMappedDataArray instances would own a weak reference back the vtkBezierPatchAdaptor which created them and a weak reference to the geometricControlPoints or scalarFieldControlPoints array it draws values from. When vtkBezierPatchAdaptor::Next() or vtkBezierPatchAdaptor::GoToPatch() is called, the adaptor would iterate over all of the vtkMappedDataArray instances it owns and change an internal variable so they would return values for the proper patch. That way the vtkMappedDataArray instances only have to be created once for each spline dataset, not once per patch. > > Is that clear enough, or should I sketch out a header file for our vtkMappedDataArray subclass? > > David > > > On Wed, Jun 17, 2015 at 10:22 PM, David Thompson wrote: > > Hi Lin, > > > >> Sorry for late reply. Since the midterm is coming, I'll definitely speed up the development from now on. > > > > We both need to do a little more work. I have been looking at how to read data from PetIGA so we can show some actual simulation data and have some 3-D volumetric examples. > > > > It would be nice to have a patch ready to merge into VTK's master branch at the midterm that provides spline interpolation and tests it for all 3 parametric dimensions (curves, surfaces, and volumes). The means producing triangles and tetrahedra, not just polylines. > > > >> I have a question about the class design in your last email. To my understanding, control points for one patch is stored in a vtkDataArray. > > > > Close. I think that we should use the vtkMappedDataArray class to hold control points for multiple patches but program it to appear as if points for each individual patch are stored in patch-order. > > > >> Do you mean store multiple vtkDataArray regarding to multiple patches in the vtkDataObject? > > > > There would be one data array to hold point coordinates, but other arrays would hold simulation variables like temperature, pressure, velocity, and so on. > > > >> If so, what class do I need to use for vtkDataObject? > > > > The class outline below is an abstract class. A concrete implementation for NURBs would require the base class's ControlPointData to be an instance of vtkStructuredGrid. A T-spline implementation might expect ControlPointData to be a vtkUnstructuredGrid. I think all we should do this summer is the NURBs case. > > > > David > > > >> > >> On Wed, Jun 10, 2015 at 2:39 PM, David Thompson wrote: > >> Hi Lin, > >> > >> > I have made it support 3D ellipse with function ... > >> > >> Great! > >> > >> > As you can see in the python test, I call this function 4 times for each quadrant to generate the entire ellipse. Since we need to support multiple patches, I think it's better to define a new dataset class for bezier patches as you mentioned before about creating a new vtkControlPoints class that inherits from vtkPoints and allows for an extra coordinate. > >> > >> Rather than create new dataset types, I would like to use existing datatypes to store the data and make an adaptor to iterate over them. That way existing pipelines could modify scalar values defined on control points (and perhaps even patches). For instance, B-splines could be represented as a vtkStructuredGrid whose FieldData contains a special knot array (special in the sense that the array must be of the proper size and with a fixed name like "_vtkKnotVector"). > >> > >> The adaptor would take a vtkDataObject as input and provide iterator-style access to each patch defined by the dataset. Specific subclasses of the adaptor would be B-splines (which expect the vtkDataObject to be a vtkStructuredGrid) or T-splines (which might expect a vtkUniformGridAMR) or even point-based splines (PB-splines as defined in Sederberg's T-spline paper, which could expect any dataset derived vtkPointSet). > >> > >> class vtkBezierPatchAdaptor : public vtkObject > >> { > >> public: > >> virtual void SetControlPointData(vtkDataObject* controlPointData); > >> vtkGetObjectMacro(vtkDataObject,ControlPointData); > >> > >> // Methods to iterate over patches: > >> virtual void Begin() = 0; > >> virtual bool IsAtEnd() = 0; > >> virtual bool GoToPatch(vtkIdType patchId) = 0; // random access iteration > >> virtual bool Next() = 0; > >> > >> // Methods to access the current patch: > >> virtual int GetPatchDimension() const = 0; > >> virtual void GetPatchShape() const = 0; > >> // returns VTK_TRIANGLE/VTK_QUAD when PatchDimension==2, > >> // returns VTK_HEXAHEDRON/VTK_TETRA when PatchDimension==3 > >> virtual void GetPatchDegree(int* degreeOut) const = 0; > >> virtual void GetPatchParameterRange(double* paramsOut) const = 0; > >> virtual void GetPatchPoints(vtkPoints* pointsOut) const = 0; > >> > >> // Some helper methods that would make Python wrappings usable: > >> int GetPatchDegree(int dim) const > >> { > >> std::vector degree(this->GetPatchDimension()); > >> this->GetPatchDegree(°ree[0]); > >> return degree[dim]; > >> } > >> void GetPatchParameterRange(int dim, double paramRange[2]) > >> { > >> std::vector range(2 * this->GetPatchDimension()); > >> this->GetPatchDegree(&range[0]); > >> paramRange[0] = [2 * dim]; > >> paramRange[1] = [2 * dim + 1]; > >> } > >> > >> protected: > >> vtkDataObject* ControlPointData; > >> }; > >> > >> The B-spline subclass could then iterate over patches by keeping a current "cell ID," which would be incremented by calling Next(). When asked for the *patch* points (not the input points), the adaptor would create a vtkMappedDataArray (see http://www.vtk.org/Wiki/VTK/InSituDataStructure for more information) that did not copy control point coordinates from its ControlPointData->GetPoints() but instead used the implicit connectivity to provide access to underlying B-spline points. > >> > >> For example, consider the simple case of a rectangular B-spline with degree 1 (bi-linear). We might be given a 5x6 grid of control points as input and asked to iterate over all the patches. Each patch is simply a quadrilateral, and there are (5-1)*(6-1) = 20 of them. > >> > >> adaptor->Begin(); // would initialize an internal "cell ID" to 0 > >> adaptor->IsAtEnd(); // would return false for "cell ID" values in [0,19] and true otherwise. > >> adaptor->GetPatchDimension(); // would return 2 > >> adaptor->GetPatchShape(); // would return VTK_QUAD > >> adaptor->GetPatchDegree(degreeOut); // would populate degreeOut with [1,1] > >> adaptor->GetPatchPoints(pointsOut); // would populate pointsOut with a vtkMappedDataArray. > >> > >> The vtkMappedDataArray would report having 4 tuples (one for each corner of the quad... when the degree is higher, is would report the product of (degreeOut[i]+1) for all i in GetPatchDimension()). The actual points reported would depend on the "cell ID" in the adaptor. > >> > >> I have not figured out yet how the "w" homogeneous coordinate would work with vtkPoints. A different adaptor API might work better (keeping the "w" coordinate separate from the other points). > >> > >> > Another question is that currently the domain of parameter coordinate is [0, 1] for each patch. Do you think it's better to make the domain continuously, namely [0, 0.25] for the first quadrant, [0.25, 0.75] for the second quadrant, etc? > >> > >> If we focus on the B-spline adaptor above, we get that for free since the returned knot vector could be normalized to the range [0,1]. > >> > >> David > >> > > > > From majcjc at gmail.com Thu Jun 18 21:17:15 2015 From: majcjc at gmail.com (Lin M) Date: Thu, 18 Jun 2015 21:17:15 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> Message-ID: Sorry... The vtkControlPointArray is the subclass of vtkMappedDataArray. I define a variable to indicate that the begin idx of the patch which I assume will be set when vtkBezierPatchAdaptor::Next() or vtkBezierPatchAdaptor::GoToPatch() is called. On Thu, Jun 18, 2015 at 9:11 PM, David Thompson wrote: > Hi Lin, > > It looks like you forgot to add the header and implementation files to the > commit. > > David > > > On Jun 18, 2015, at 9:08 PM, Lin M wrote: > > > > Hi Dr. Thompson, > > > > I have added one commit which contains a vtkMappedDataArray subclass but > I'm not sure I totally get the idea about the in-situ data structures. Can > you take a look at it please? ( > https://gitlab.kitware.com/splines/vtk/merge_requests/4) > > > > Best, > > Lin > > > > On Thu, Jun 18, 2015 at 10:47 AM, David Thompson < > david.thompson at kitware.com> wrote: > > Hi Lin, > > > > > From some examples I saw, usually we put some points in vtkPoints, > store the connectivity in cellArray and add them to a dataset (vtkPolyData, > vtkStructuredGrid or vtkUnstructureGrid). So is that we store the control > point of multiple patches in the vtkPoints where we replace the > vtkDataArray with vtkMappedDataArray now? And in a vtkMappedDataArray, we > store all the points for all patches together but we overwrite how to > iterate the array. > > > > That is nearly correct. We will accept > > > > vtkDataObject* ControlPointData; > > > > from the user. For the case we will implement first, ControlPointData's > actual type will be the vtkStructuredGrid subclass of vtkDataObject. The > vtkStructuredGrid instance can hold many user-supplied vtkDataArray > instances: > > > > vtkStructuredGrid* structuredControlPoints = > > vtkStructuredGrid::SafeDownCast(ControlPointData); > > > > // Control points to map from parameter-space to world coordinates: > > vtkDataArray* geometricControlPoints = > > structuredControlPoints->GetPoints()->GetData(); > > > > // Control points to map from paramter-space to scalar fields: > > vtkDataSetAttributes* scalarFields = > structuredControlPoints->GetPointData(); > > vtkIdType numScalarFields = scalarFields->GetNumberOfArrays(); > > for (vtkIdType i = 0; i < numScalarFields; ++i) > > { // scalarFieldControlPoints will hold things like temperature, > pressure, etc.: > > vtkDataArray* scalarFieldControlPoints = scalarFields->GetArray(i); > > } > > > > Because the user supplies these arrays, we cannot force them to be > vtkMappedDataArray. Instead, we can make a vtkMappedDataArray subclass that > owns a reference to one of the arrays above and only returns one patch's > values from the user-supplied array (which holds the values for all patches > in the spline). > > > > The BezierPatchAdaptor below would return instances of our > vtkMappedDataArray when its GetPatchPoints method is called. Now that I've > written some more out, it looks like the API should be changed a little bit > so that users can ask for a particular array (geometricControlPoints or > scalarFieldControlPoints): > > > > class vtkBezierPatchAdaptor : public vtkObject > > { > > public: > > virtual void SetControlPointData(vtkDataObject* controlPointData); > > vtkGetObjectMacro(vtkDataObject,ControlPointData); > > > > // Methods to iterate over patches: > > // ... same as below ... > > > > // Methods to access the current patch: > > // ... > > virtual vtkSmartPointer GetPatchPoints(int > scalarField) const = 0; > > // ... > > }; > > > > This way, GetPatchPoints() could return the vtkMappedDataArray for > geometricControlPoints when the "int scalarField" argument is negative > value and a vtkMappedDataArray for one of the scalarFieldControlPoints > arrays when scalarField is positive. > > > > Having GetPatchPoints() return a smart pointer to a vtkMappedDataArray > subclass would also get around the issue that vtkPoints expects its > vtkDataArray to have 3 components per tuple (where ours will have 4 for > geometricControlPoints or an arbitrary number for scalarFieldControlPoints). > > > > The vtkMappedDataArray instances would own a weak reference back the > vtkBezierPatchAdaptor which created them and a weak reference to the > geometricControlPoints or scalarFieldControlPoints array it draws values > from. When vtkBezierPatchAdaptor::Next() or > vtkBezierPatchAdaptor::GoToPatch() is called, the adaptor would iterate > over all of the vtkMappedDataArray instances it owns and change an internal > variable so they would return values for the proper patch. That way the > vtkMappedDataArray instances only have to be created once for each spline > dataset, not once per patch. > > > > Is that clear enough, or should I sketch out a header file for our > vtkMappedDataArray subclass? > > > > David > > > > > On Wed, Jun 17, 2015 at 10:22 PM, David Thompson < > david.thompson at kitware.com> wrote: > > > Hi Lin, > > > > > >> Sorry for late reply. Since the midterm is coming, I'll definitely > speed up the development from now on. > > > > > > We both need to do a little more work. I have been looking at how to > read data from PetIGA so we can show some actual simulation data and have > some 3-D volumetric examples. > > > > > > It would be nice to have a patch ready to merge into VTK's master > branch at the midterm that provides spline interpolation and tests it for > all 3 parametric dimensions (curves, surfaces, and volumes). The means > producing triangles and tetrahedra, not just polylines. > > > > > >> I have a question about the class design in your last email. To my > understanding, control points for one patch is stored in a vtkDataArray. > > > > > > Close. I think that we should use the vtkMappedDataArray class to hold > control points for multiple patches but program it to appear as if points > for each individual patch are stored in patch-order. > > > > > >> Do you mean store multiple vtkDataArray regarding to multiple patches > in the vtkDataObject? > > > > > > There would be one data array to hold point coordinates, but other > arrays would hold simulation variables like temperature, pressure, > velocity, and so on. > > > > > >> If so, what class do I need to use for vtkDataObject? > > > > > > The class outline below is an abstract class. A concrete > implementation for NURBs would require the base class's ControlPointData > to be an instance of vtkStructuredGrid. A T-spline implementation might > expect ControlPointData to be a vtkUnstructuredGrid. I think all we should > do this summer is the NURBs case. > > > > > > David > > > > > >> > > >> On Wed, Jun 10, 2015 at 2:39 PM, David Thompson < > david.thompson at kitware.com> wrote: > > >> Hi Lin, > > >> > > >> > I have made it support 3D ellipse with function ... > > >> > > >> Great! > > >> > > >> > As you can see in the python test, I call this function 4 times for > each quadrant to generate the entire ellipse. Since we need to support > multiple patches, I think it's better to define a new dataset class for > bezier patches as you mentioned before about creating a new > vtkControlPoints class that inherits from vtkPoints and allows for an extra > coordinate. > > >> > > >> Rather than create new dataset types, I would like to use existing > datatypes to store the data and make an adaptor to iterate over them. That > way existing pipelines could modify scalar values defined on control points > (and perhaps even patches). For instance, B-splines could be represented as > a vtkStructuredGrid whose FieldData contains a special knot array (special > in the sense that the array must be of the proper size and with a fixed > name like "_vtkKnotVector"). > > >> > > >> The adaptor would take a vtkDataObject as input and provide > iterator-style access to each patch defined by the dataset. Specific > subclasses of the adaptor would be B-splines (which expect the > vtkDataObject to be a vtkStructuredGrid) or T-splines (which might expect a > vtkUniformGridAMR) or even point-based splines (PB-splines as defined in > Sederberg's T-spline paper, which could expect any dataset derived > vtkPointSet). > > >> > > >> class vtkBezierPatchAdaptor : public vtkObject > > >> { > > >> public: > > >> virtual void SetControlPointData(vtkDataObject* controlPointData); > > >> vtkGetObjectMacro(vtkDataObject,ControlPointData); > > >> > > >> // Methods to iterate over patches: > > >> virtual void Begin() = 0; > > >> virtual bool IsAtEnd() = 0; > > >> virtual bool GoToPatch(vtkIdType patchId) = 0; // random access > iteration > > >> virtual bool Next() = 0; > > >> > > >> // Methods to access the current patch: > > >> virtual int GetPatchDimension() const = 0; > > >> virtual void GetPatchShape() const = 0; > > >> // returns VTK_TRIANGLE/VTK_QUAD when PatchDimension==2, > > >> // returns VTK_HEXAHEDRON/VTK_TETRA when PatchDimension==3 > > >> virtual void GetPatchDegree(int* degreeOut) const = 0; > > >> virtual void GetPatchParameterRange(double* paramsOut) const = 0; > > >> virtual void GetPatchPoints(vtkPoints* pointsOut) const = 0; > > >> > > >> // Some helper methods that would make Python wrappings usable: > > >> int GetPatchDegree(int dim) const > > >> { > > >> std::vector degree(this->GetPatchDimension()); > > >> this->GetPatchDegree(°ree[0]); > > >> return degree[dim]; > > >> } > > >> void GetPatchParameterRange(int dim, double paramRange[2]) > > >> { > > >> std::vector range(2 * this->GetPatchDimension()); > > >> this->GetPatchDegree(&range[0]); > > >> paramRange[0] = [2 * dim]; > > >> paramRange[1] = [2 * dim + 1]; > > >> } > > >> > > >> protected: > > >> vtkDataObject* ControlPointData; > > >> }; > > >> > > >> The B-spline subclass could then iterate over patches by keeping a > current "cell ID," which would be incremented by calling Next(). When asked > for the *patch* points (not the input points), the adaptor would create a > vtkMappedDataArray (see http://www.vtk.org/Wiki/VTK/InSituDataStructure > for more information) that did not copy control point coordinates from its > ControlPointData->GetPoints() but instead used the implicit connectivity to > provide access to underlying B-spline points. > > >> > > >> For example, consider the simple case of a rectangular B-spline with > degree 1 (bi-linear). We might be given a 5x6 grid of control points as > input and asked to iterate over all the patches. Each patch is simply a > quadrilateral, and there are (5-1)*(6-1) = 20 of them. > > >> > > >> adaptor->Begin(); // would initialize an internal "cell ID" to 0 > > >> adaptor->IsAtEnd(); // would return false for "cell ID" values in > [0,19] and true otherwise. > > >> adaptor->GetPatchDimension(); // would return 2 > > >> adaptor->GetPatchShape(); // would return VTK_QUAD > > >> adaptor->GetPatchDegree(degreeOut); // would populate degreeOut > with [1,1] > > >> adaptor->GetPatchPoints(pointsOut); // would populate pointsOut > with a vtkMappedDataArray. > > >> > > >> The vtkMappedDataArray would report having 4 tuples (one for each > corner of the quad... when the degree is higher, is would report the > product of (degreeOut[i]+1) for all i in GetPatchDimension()). The actual > points reported would depend on the "cell ID" in the adaptor. > > >> > > >> I have not figured out yet how the "w" homogeneous coordinate would > work with vtkPoints. A different adaptor API might work better (keeping the > "w" coordinate separate from the other points). > > >> > > >> > Another question is that currently the domain of parameter > coordinate is [0, 1] for each patch. Do you think it's better to make the > domain continuously, namely [0, 0.25] for the first quadrant, [0.25, 0.75] > for the second quadrant, etc? > > >> > > >> If we focus on the B-spline adaptor above, we get that for free since > the returned knot vector could be normalized to the range [0,1]. > > >> > > >> David > > >> > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Thu Jun 18 23:44:51 2015 From: majcjc at gmail.com (Lin M) Date: Thu, 18 Jun 2015 23:44:51 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> Message-ID: Do we store the auxiliary variables like PatchDegree PatchDimension and PatchParameterRange for all patches in the adaptor class and keep the variables for certain patch in the vtkMappedDataArray subclass when we want to retrieve that patch? On Thu, Jun 18, 2015 at 9:17 PM, Lin M wrote: > Sorry... > > The vtkControlPointArray is the subclass of vtkMappedDataArray. I define a > variable to indicate that the begin idx of the patch which I assume will be > set when vtkBezierPatchAdaptor::Next() or vtkBezierPatchAdaptor::GoToPatch() > is called. > > On Thu, Jun 18, 2015 at 9:11 PM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hi Lin, >> >> It looks like you forgot to add the header and implementation files to >> the commit. >> >> David >> >> > On Jun 18, 2015, at 9:08 PM, Lin M wrote: >> > >> > Hi Dr. Thompson, >> > >> > I have added one commit which contains a vtkMappedDataArray subclass >> but I'm not sure I totally get the idea about the in-situ data structures. >> Can you take a look at it please? ( >> https://gitlab.kitware.com/splines/vtk/merge_requests/4) >> > >> > Best, >> > Lin >> > >> > On Thu, Jun 18, 2015 at 10:47 AM, David Thompson < >> david.thompson at kitware.com> wrote: >> > Hi Lin, >> > >> > > From some examples I saw, usually we put some points in vtkPoints, >> store the connectivity in cellArray and add them to a dataset (vtkPolyData, >> vtkStructuredGrid or vtkUnstructureGrid). So is that we store the control >> point of multiple patches in the vtkPoints where we replace the >> vtkDataArray with vtkMappedDataArray now? And in a vtkMappedDataArray, we >> store all the points for all patches together but we overwrite how to >> iterate the array. >> > >> > That is nearly correct. We will accept >> > >> > vtkDataObject* ControlPointData; >> > >> > from the user. For the case we will implement first, ControlPointData's >> actual type will be the vtkStructuredGrid subclass of vtkDataObject. The >> vtkStructuredGrid instance can hold many user-supplied vtkDataArray >> instances: >> > >> > vtkStructuredGrid* structuredControlPoints = >> > vtkStructuredGrid::SafeDownCast(ControlPointData); >> > >> > // Control points to map from parameter-space to world coordinates: >> > vtkDataArray* geometricControlPoints = >> > structuredControlPoints->GetPoints()->GetData(); >> > >> > // Control points to map from paramter-space to scalar fields: >> > vtkDataSetAttributes* scalarFields = >> structuredControlPoints->GetPointData(); >> > vtkIdType numScalarFields = scalarFields->GetNumberOfArrays(); >> > for (vtkIdType i = 0; i < numScalarFields; ++i) >> > { // scalarFieldControlPoints will hold things like temperature, >> pressure, etc.: >> > vtkDataArray* scalarFieldControlPoints = >> scalarFields->GetArray(i); >> > } >> > >> > Because the user supplies these arrays, we cannot force them to be >> vtkMappedDataArray. Instead, we can make a vtkMappedDataArray subclass that >> owns a reference to one of the arrays above and only returns one patch's >> values from the user-supplied array (which holds the values for all patches >> in the spline). >> > >> > The BezierPatchAdaptor below would return instances of our >> vtkMappedDataArray when its GetPatchPoints method is called. Now that I've >> written some more out, it looks like the API should be changed a little bit >> so that users can ask for a particular array (geometricControlPoints or >> scalarFieldControlPoints): >> > >> > class vtkBezierPatchAdaptor : public vtkObject >> > { >> > public: >> > virtual void SetControlPointData(vtkDataObject* controlPointData); >> > vtkGetObjectMacro(vtkDataObject,ControlPointData); >> > >> > // Methods to iterate over patches: >> > // ... same as below ... >> > >> > // Methods to access the current patch: >> > // ... >> > virtual vtkSmartPointer GetPatchPoints(int >> scalarField) const = 0; >> > // ... >> > }; >> > >> > This way, GetPatchPoints() could return the vtkMappedDataArray for >> geometricControlPoints when the "int scalarField" argument is negative >> value and a vtkMappedDataArray for one of the scalarFieldControlPoints >> arrays when scalarField is positive. >> > >> > Having GetPatchPoints() return a smart pointer to a vtkMappedDataArray >> subclass would also get around the issue that vtkPoints expects its >> vtkDataArray to have 3 components per tuple (where ours will have 4 for >> geometricControlPoints or an arbitrary number for scalarFieldControlPoints). >> > >> > The vtkMappedDataArray instances would own a weak reference back the >> vtkBezierPatchAdaptor which created them and a weak reference to the >> geometricControlPoints or scalarFieldControlPoints array it draws values >> from. When vtkBezierPatchAdaptor::Next() or >> vtkBezierPatchAdaptor::GoToPatch() is called, the adaptor would iterate >> over all of the vtkMappedDataArray instances it owns and change an internal >> variable so they would return values for the proper patch. That way the >> vtkMappedDataArray instances only have to be created once for each spline >> dataset, not once per patch. >> > >> > Is that clear enough, or should I sketch out a header file for our >> vtkMappedDataArray subclass? >> > >> > David >> > >> > > On Wed, Jun 17, 2015 at 10:22 PM, David Thompson < >> david.thompson at kitware.com> wrote: >> > > Hi Lin, >> > > >> > >> Sorry for late reply. Since the midterm is coming, I'll definitely >> speed up the development from now on. >> > > >> > > We both need to do a little more work. I have been looking at how to >> read data from PetIGA so we can show some actual simulation data and have >> some 3-D volumetric examples. >> > > >> > > It would be nice to have a patch ready to merge into VTK's master >> branch at the midterm that provides spline interpolation and tests it for >> all 3 parametric dimensions (curves, surfaces, and volumes). The means >> producing triangles and tetrahedra, not just polylines. >> > > >> > >> I have a question about the class design in your last email. To my >> understanding, control points for one patch is stored in a vtkDataArray. >> > > >> > > Close. I think that we should use the vtkMappedDataArray class to >> hold control points for multiple patches but program it to appear as if >> points for each individual patch are stored in patch-order. >> > > >> > >> Do you mean store multiple vtkDataArray regarding to multiple >> patches in the vtkDataObject? >> > > >> > > There would be one data array to hold point coordinates, but other >> arrays would hold simulation variables like temperature, pressure, >> velocity, and so on. >> > > >> > >> If so, what class do I need to use for vtkDataObject? >> > > >> > > The class outline below is an abstract class. A concrete >> implementation for NURBs would require the base class's ControlPointData >> to be an instance of vtkStructuredGrid. A T-spline implementation might >> expect ControlPointData to be a vtkUnstructuredGrid. I think all we should >> do this summer is the NURBs case. >> > > >> > > David >> > > >> > >> >> > >> On Wed, Jun 10, 2015 at 2:39 PM, David Thompson < >> david.thompson at kitware.com> wrote: >> > >> Hi Lin, >> > >> >> > >> > I have made it support 3D ellipse with function ... >> > >> >> > >> Great! >> > >> >> > >> > As you can see in the python test, I call this function 4 times >> for each quadrant to generate the entire ellipse. Since we need to support >> multiple patches, I think it's better to define a new dataset class for >> bezier patches as you mentioned before about creating a new >> vtkControlPoints class that inherits from vtkPoints and allows for an extra >> coordinate. >> > >> >> > >> Rather than create new dataset types, I would like to use existing >> datatypes to store the data and make an adaptor to iterate over them. That >> way existing pipelines could modify scalar values defined on control points >> (and perhaps even patches). For instance, B-splines could be represented as >> a vtkStructuredGrid whose FieldData contains a special knot array (special >> in the sense that the array must be of the proper size and with a fixed >> name like "_vtkKnotVector"). >> > >> >> > >> The adaptor would take a vtkDataObject as input and provide >> iterator-style access to each patch defined by the dataset. Specific >> subclasses of the adaptor would be B-splines (which expect the >> vtkDataObject to be a vtkStructuredGrid) or T-splines (which might expect a >> vtkUniformGridAMR) or even point-based splines (PB-splines as defined in >> Sederberg's T-spline paper, which could expect any dataset derived >> vtkPointSet). >> > >> >> > >> class vtkBezierPatchAdaptor : public vtkObject >> > >> { >> > >> public: >> > >> virtual void SetControlPointData(vtkDataObject* controlPointData); >> > >> vtkGetObjectMacro(vtkDataObject,ControlPointData); >> > >> >> > >> // Methods to iterate over patches: >> > >> virtual void Begin() = 0; >> > >> virtual bool IsAtEnd() = 0; >> > >> virtual bool GoToPatch(vtkIdType patchId) = 0; // random access >> iteration >> > >> virtual bool Next() = 0; >> > >> >> > >> // Methods to access the current patch: >> > >> virtual int GetPatchDimension() const = 0; >> > >> virtual void GetPatchShape() const = 0; >> > >> // returns VTK_TRIANGLE/VTK_QUAD when PatchDimension==2, >> > >> // returns VTK_HEXAHEDRON/VTK_TETRA when PatchDimension==3 >> > >> virtual void GetPatchDegree(int* degreeOut) const = 0; >> > >> virtual void GetPatchParameterRange(double* paramsOut) const = 0; >> > >> virtual void GetPatchPoints(vtkPoints* pointsOut) const = 0; >> > >> >> > >> // Some helper methods that would make Python wrappings usable: >> > >> int GetPatchDegree(int dim) const >> > >> { >> > >> std::vector degree(this->GetPatchDimension()); >> > >> this->GetPatchDegree(°ree[0]); >> > >> return degree[dim]; >> > >> } >> > >> void GetPatchParameterRange(int dim, double paramRange[2]) >> > >> { >> > >> std::vector range(2 * this->GetPatchDimension()); >> > >> this->GetPatchDegree(&range[0]); >> > >> paramRange[0] = [2 * dim]; >> > >> paramRange[1] = [2 * dim + 1]; >> > >> } >> > >> >> > >> protected: >> > >> vtkDataObject* ControlPointData; >> > >> }; >> > >> >> > >> The B-spline subclass could then iterate over patches by keeping a >> current "cell ID," which would be incremented by calling Next(). When asked >> for the *patch* points (not the input points), the adaptor would create a >> vtkMappedDataArray (see http://www.vtk.org/Wiki/VTK/InSituDataStructure >> for more information) that did not copy control point coordinates from its >> ControlPointData->GetPoints() but instead used the implicit connectivity to >> provide access to underlying B-spline points. >> > >> >> > >> For example, consider the simple case of a rectangular B-spline with >> degree 1 (bi-linear). We might be given a 5x6 grid of control points as >> input and asked to iterate over all the patches. Each patch is simply a >> quadrilateral, and there are (5-1)*(6-1) = 20 of them. >> > >> >> > >> adaptor->Begin(); // would initialize an internal "cell ID" to 0 >> > >> adaptor->IsAtEnd(); // would return false for "cell ID" values in >> [0,19] and true otherwise. >> > >> adaptor->GetPatchDimension(); // would return 2 >> > >> adaptor->GetPatchShape(); // would return VTK_QUAD >> > >> adaptor->GetPatchDegree(degreeOut); // would populate degreeOut >> with [1,1] >> > >> adaptor->GetPatchPoints(pointsOut); // would populate pointsOut >> with a vtkMappedDataArray. >> > >> >> > >> The vtkMappedDataArray would report having 4 tuples (one for each >> corner of the quad... when the degree is higher, is would report the >> product of (degreeOut[i]+1) for all i in GetPatchDimension()). The actual >> points reported would depend on the "cell ID" in the adaptor. >> > >> >> > >> I have not figured out yet how the "w" homogeneous coordinate would >> work with vtkPoints. A different adaptor API might work better (keeping the >> "w" coordinate separate from the other points). >> > >> >> > >> > Another question is that currently the domain of parameter >> coordinate is [0, 1] for each patch. Do you think it's better to make the >> domain continuously, namely [0, 0.25] for the first quadrant, [0.25, 0.75] >> for the second quadrant, etc? >> > >> >> > >> If we focus on the B-spline adaptor above, we get that for free >> since the returned knot vector could be normalized to the range [0,1]. >> > >> >> > >> David >> > >> >> > > >> > >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri Jun 19 01:33:03 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 19 Jun 2015 01:33:03 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> Message-ID: <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> Hi Lin, The patch degree can be inferred from the difference between the length of the knot vector and the size of the control point grid. The patch dimension is the dimension of the control point grid. For example, if we run vtkStructuredGrid* grid; int dim[3]; grid->GetDimensions(dim); and dims is [4,1,1], then we have a 1-d curve spline with 4 control points (=4*1*1). If dims is [4,4,1] then we have a surface spline with 16 control points (=4*4*1). The order of the spline interpolant is the difference in length between the number of control points in that dimension and the number of knot vector entries in that dimension. See https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline#Knot_vector for examples. So, to answer your question, we do not need to cache the patch dimension and parameter range. The parameter interval is given by the knot vector entries corresponding to the current patch, so we should not need to store that, either. David > On Jun 18, 2015, at 23:44, Lin M wrote: > > Do we store the auxiliary variables like PatchDegree PatchDimension and PatchParameterRange for all patches in the adaptor class and keep the variables for certain patch in the vtkMappedDataArray subclass when we want to retrieve that patch? > >> On Thu, Jun 18, 2015 at 9:17 PM, Lin M wrote: >> Sorry... >> >> The vtkControlPointArray is the subclass of vtkMappedDataArray. I define a variable to indicate that the begin idx of the patch which I assume will be set when vtkBezierPatchAdaptor::Next() or vtkBezierPatchAdaptor::GoToPatch() is called. >> >>> On Thu, Jun 18, 2015 at 9:11 PM, David Thompson wrote: >>> Hi Lin, >>> >>> It looks like you forgot to add the header and implementation files to the commit. >>> >>> David >>> >>> > On Jun 18, 2015, at 9:08 PM, Lin M wrote: >>> > >>> > Hi Dr. Thompson, >>> > >>> > I have added one commit which contains a vtkMappedDataArray subclass but I'm not sure I totally get the idea about the in-situ data structures. Can you take a look at it please? (https://gitlab.kitware.com/splines/vtk/merge_requests/4) >>> > >>> > Best, >>> > Lin >>> > >>> > On Thu, Jun 18, 2015 at 10:47 AM, David Thompson wrote: >>> > Hi Lin, >>> > >>> > > From some examples I saw, usually we put some points in vtkPoints, store the connectivity in cellArray and add them to a dataset (vtkPolyData, vtkStructuredGrid or vtkUnstructureGrid). So is that we store the control point of multiple patches in the vtkPoints where we replace the vtkDataArray with vtkMappedDataArray now? And in a vtkMappedDataArray, we store all the points for all patches together but we overwrite how to iterate the array. >>> > >>> > That is nearly correct. We will accept >>> > >>> > vtkDataObject* ControlPointData; >>> > >>> > from the user. For the case we will implement first, ControlPointData's actual type will be the vtkStructuredGrid subclass of vtkDataObject. The vtkStructuredGrid instance can hold many user-supplied vtkDataArray instances: >>> > >>> > vtkStructuredGrid* structuredControlPoints = >>> > vtkStructuredGrid::SafeDownCast(ControlPointData); >>> > >>> > // Control points to map from parameter-space to world coordinates: >>> > vtkDataArray* geometricControlPoints = >>> > structuredControlPoints->GetPoints()->GetData(); >>> > >>> > // Control points to map from paramter-space to scalar fields: >>> > vtkDataSetAttributes* scalarFields = structuredControlPoints->GetPointData(); >>> > vtkIdType numScalarFields = scalarFields->GetNumberOfArrays(); >>> > for (vtkIdType i = 0; i < numScalarFields; ++i) >>> > { // scalarFieldControlPoints will hold things like temperature, pressure, etc.: >>> > vtkDataArray* scalarFieldControlPoints = scalarFields->GetArray(i); >>> > } >>> > >>> > Because the user supplies these arrays, we cannot force them to be vtkMappedDataArray. Instead, we can make a vtkMappedDataArray subclass that owns a reference to one of the arrays above and only returns one patch's values from the user-supplied array (which holds the values for all patches in the spline). >>> > >>> > The BezierPatchAdaptor below would return instances of our vtkMappedDataArray when its GetPatchPoints method is called. Now that I've written some more out, it looks like the API should be changed a little bit so that users can ask for a particular array (geometricControlPoints or scalarFieldControlPoints): >>> > >>> > class vtkBezierPatchAdaptor : public vtkObject >>> > { >>> > public: >>> > virtual void SetControlPointData(vtkDataObject* controlPointData); >>> > vtkGetObjectMacro(vtkDataObject,ControlPointData); >>> > >>> > // Methods to iterate over patches: >>> > // ... same as below ... >>> > >>> > // Methods to access the current patch: >>> > // ... >>> > virtual vtkSmartPointer GetPatchPoints(int scalarField) const = 0; >>> > // ... >>> > }; >>> > >>> > This way, GetPatchPoints() could return the vtkMappedDataArray for geometricControlPoints when the "int scalarField" argument is negative value and a vtkMappedDataArray for one of the scalarFieldControlPoints arrays when scalarField is positive. >>> > >>> > Having GetPatchPoints() return a smart pointer to a vtkMappedDataArray subclass would also get around the issue that vtkPoints expects its vtkDataArray to have 3 components per tuple (where ours will have 4 for geometricControlPoints or an arbitrary number for scalarFieldControlPoints). >>> > >>> > The vtkMappedDataArray instances would own a weak reference back the vtkBezierPatchAdaptor which created them and a weak reference to the geometricControlPoints or scalarFieldControlPoints array it draws values from. When vtkBezierPatchAdaptor::Next() or vtkBezierPatchAdaptor::GoToPatch() is called, the adaptor would iterate over all of the vtkMappedDataArray instances it owns and change an internal variable so they would return values for the proper patch. That way the vtkMappedDataArray instances only have to be created once for each spline dataset, not once per patch. >>> > >>> > Is that clear enough, or should I sketch out a header file for our vtkMappedDataArray subclass? >>> > >>> > David >>> > >>> > > On Wed, Jun 17, 2015 at 10:22 PM, David Thompson wrote: >>> > > Hi Lin, >>> > > >>> > >> Sorry for late reply. Since the midterm is coming, I'll definitely speed up the development from now on. >>> > > >>> > > We both need to do a little more work. I have been looking at how to read data from PetIGA so we can show some actual simulation data and have some 3-D volumetric examples. >>> > > >>> > > It would be nice to have a patch ready to merge into VTK's master branch at the midterm that provides spline interpolation and tests it for all 3 parametric dimensions (curves, surfaces, and volumes). The means producing triangles and tetrahedra, not just polylines. >>> > > >>> > >> I have a question about the class design in your last email. To my understanding, control points for one patch is stored in a vtkDataArray. >>> > > >>> > > Close. I think that we should use the vtkMappedDataArray class to hold control points for multiple patches but program it to appear as if points for each individual patch are stored in patch-order. >>> > > >>> > >> Do you mean store multiple vtkDataArray regarding to multiple patches in the vtkDataObject? >>> > > >>> > > There would be one data array to hold point coordinates, but other arrays would hold simulation variables like temperature, pressure, velocity, and so on. >>> > > >>> > >> If so, what class do I need to use for vtkDataObject? >>> > > >>> > > The class outline below is an abstract class. A concrete implementation for NURBs would require the base class's ControlPointData to be an instance of vtkStructuredGrid. A T-spline implementation might expect ControlPointData to be a vtkUnstructuredGrid. I think all we should do this summer is the NURBs case. >>> > > >>> > > David >>> > > >>> > >> >>> > >> On Wed, Jun 10, 2015 at 2:39 PM, David Thompson wrote: >>> > >> Hi Lin, >>> > >> >>> > >> > I have made it support 3D ellipse with function ... >>> > >> >>> > >> Great! >>> > >> >>> > >> > As you can see in the python test, I call this function 4 times for each quadrant to generate the entire ellipse. Since we need to support multiple patches, I think it's better to define a new dataset class for bezier patches as you mentioned before about creating a new vtkControlPoints class that inherits from vtkPoints and allows for an extra coordinate. >>> > >> >>> > >> Rather than create new dataset types, I would like to use existing datatypes to store the data and make an adaptor to iterate over them. That way existing pipelines could modify scalar values defined on control points (and perhaps even patches). For instance, B-splines could be represented as a vtkStructuredGrid whose FieldData contains a special knot array (special in the sense that the array must be of the proper size and with a fixed name like "_vtkKnotVector"). >>> > >> >>> > >> The adaptor would take a vtkDataObject as input and provide iterator-style access to each patch defined by the dataset. Specific subclasses of the adaptor would be B-splines (which expect the vtkDataObject to be a vtkStructuredGrid) or T-splines (which might expect a vtkUniformGridAMR) or even point-based splines (PB-splines as defined in Sederberg's T-spline paper, which could expect any dataset derived vtkPointSet). >>> > >> >>> > >> class vtkBezierPatchAdaptor : public vtkObject >>> > >> { >>> > >> public: >>> > >> virtual void SetControlPointData(vtkDataObject* controlPointData); >>> > >> vtkGetObjectMacro(vtkDataObject,ControlPointData); >>> > >> >>> > >> // Methods to iterate over patches: >>> > >> virtual void Begin() = 0; >>> > >> virtual bool IsAtEnd() = 0; >>> > >> virtual bool GoToPatch(vtkIdType patchId) = 0; // random access iteration >>> > >> virtual bool Next() = 0; >>> > >> >>> > >> // Methods to access the current patch: >>> > >> virtual int GetPatchDimension() const = 0; >>> > >> virtual void GetPatchShape() const = 0; >>> > >> // returns VTK_TRIANGLE/VTK_QUAD when PatchDimension==2, >>> > >> // returns VTK_HEXAHEDRON/VTK_TETRA when PatchDimension==3 >>> > >> virtual void GetPatchDegree(int* degreeOut) const = 0; >>> > >> virtual void GetPatchParameterRange(double* paramsOut) const = 0; >>> > >> virtual void GetPatchPoints(vtkPoints* pointsOut) const = 0; >>> > >> >>> > >> // Some helper methods that would make Python wrappings usable: >>> > >> int GetPatchDegree(int dim) const >>> > >> { >>> > >> std::vector degree(this->GetPatchDimension()); >>> > >> this->GetPatchDegree(°ree[0]); >>> > >> return degree[dim]; >>> > >> } >>> > >> void GetPatchParameterRange(int dim, double paramRange[2]) >>> > >> { >>> > >> std::vector range(2 * this->GetPatchDimension()); >>> > >> this->GetPatchDegree(&range[0]); >>> > >> paramRange[0] = [2 * dim]; >>> > >> paramRange[1] = [2 * dim + 1]; >>> > >> } >>> > >> >>> > >> protected: >>> > >> vtkDataObject* ControlPointData; >>> > >> }; >>> > >> >>> > >> The B-spline subclass could then iterate over patches by keeping a current "cell ID," which would be incremented by calling Next(). When asked for the *patch* points (not the input points), the adaptor would create a vtkMappedDataArray (see http://www.vtk.org/Wiki/VTK/InSituDataStructure for more information) that did not copy control point coordinates from its ControlPointData->GetPoints() but instead used the implicit connectivity to provide access to underlying B-spline points. >>> > >> >>> > >> For example, consider the simple case of a rectangular B-spline with degree 1 (bi-linear). We might be given a 5x6 grid of control points as input and asked to iterate over all the patches. Each patch is simply a quadrilateral, and there are (5-1)*(6-1) = 20 of them. >>> > >> >>> > >> adaptor->Begin(); // would initialize an internal "cell ID" to 0 >>> > >> adaptor->IsAtEnd(); // would return false for "cell ID" values in [0,19] and true otherwise. >>> > >> adaptor->GetPatchDimension(); // would return 2 >>> > >> adaptor->GetPatchShape(); // would return VTK_QUAD >>> > >> adaptor->GetPatchDegree(degreeOut); // would populate degreeOut with [1,1] >>> > >> adaptor->GetPatchPoints(pointsOut); // would populate pointsOut with a vtkMappedDataArray. >>> > >> >>> > >> The vtkMappedDataArray would report having 4 tuples (one for each corner of the quad... when the degree is higher, is would report the product of (degreeOut[i]+1) for all i in GetPatchDimension()). The actual points reported would depend on the "cell ID" in the adaptor. >>> > >> >>> > >> I have not figured out yet how the "w" homogeneous coordinate would work with vtkPoints. A different adaptor API might work better (keeping the "w" coordinate separate from the other points). >>> > >> >>> > >> > Another question is that currently the domain of parameter coordinate is [0, 1] for each patch. Do you think it's better to make the domain continuously, namely [0, 0.25] for the first quadrant, [0.25, 0.75] for the second quadrant, etc? >>> > >> >>> > >> If we focus on the B-spline adaptor above, we get that for free since the returned knot vector could be normalized to the range [0,1]. >>> > >> >>> > >> David >>> > >> >>> > > >>> > >>> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Fri Jun 19 04:46:47 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Fri, 19 Jun 2015 10:46:47 +0200 Subject: [vtk-developers] Coloring using vector magnitude Message-ID: Hello Can someone help me color my data by vector magnitude ? It seems so simple and yet does not work. Mathieu Westphal -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: main.cxx Type: text/x-c++src Size: 2581 bytes Desc: not available URL: From joachim.pouderoux at kitware.com Fri Jun 19 04:56:03 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Fri, 19 Jun 2015 10:56:03 +0200 Subject: [vtk-developers] Coloring using vector magnitude In-Reply-To: References: Message-ID: reader->ReadAllVectorsOn(); should do the trick here ;) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mathieu.westphal at kitware.com Fri Jun 19 04:56:43 2015 From: mathieu.westphal at kitware.com (Mathieu Westphal) Date: Fri, 19 Jun 2015 10:56:43 +0200 Subject: [vtk-developers] Coloring using vector magnitude In-Reply-To: References: Message-ID: thx Mathieu Westphal On Fri, Jun 19, 2015 at 10:56 AM, Joachim Pouderoux < joachim.pouderoux at kitware.com> wrote: > reader->ReadAllVectorsOn(); > > should do the trick here ;) > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Fri Jun 19 18:28:26 2015 From: majcjc at gmail.com (Lin M) Date: Fri, 19 Jun 2015 18:28:26 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> Message-ID: I get it now. Previously I was thinking of bezier patches so we need explicit definition about the degree to each dimension given a control point array. We are now considering NURBS whose degree of interpolant has been implicit defined together by the knot vectors and control points (degree + number of control points = number of knot vector entries) but if we assume all the control points for all patches are stored in one vtkStructureGrid instance (the points are ultimately stored in the vtkDataArray* vtkStructureGrid->GetPoints()->GetData()), we still need to know where the i-th patch begins in the vtkDataArray. What we want to implement now is to use vtkMappedDataArray to retrieve a "fake" vtkDataArray for one patch from the original vtkDataArray. On Fri, Jun 19, 2015 at 1:33 AM, David Thompson wrote: > Hi Lin, > > The patch degree can be inferred from the difference between the length of > the knot vector and the size of the control point grid. The patch dimension > is the dimension of the control point grid. For example, if we run > > vtkStructuredGrid* grid; > int dim[3]; > grid->GetDimensions(dim); > > and dims is [4,1,1], then we have a 1-d curve spline with 4 control points > (=4*1*1). If dims is [4,4,1] then we have a surface spline with 16 control > points (=4*4*1). The order of the spline interpolant is the difference in > length between the number of control points in that dimension and the > number of knot vector entries in that dimension. See > https://en.wikipedia.org/wiki/Non-uniform_rational_B-spline#Knot_vector for > examples. > > So, to answer your question, we do not need to cache the patch dimension > and parameter range. The parameter interval is given by the knot vector > entries corresponding to the current patch, so we should not need to store > that, either. > > David > > > On Jun 18, 2015, at 23:44, Lin M wrote: > > Do we store the auxiliary variables like PatchDegree PatchDimension and > PatchParameterRange for all patches in the adaptor class and keep the > variables for certain patch in the vtkMappedDataArray subclass when we want > to retrieve that patch? > > On Thu, Jun 18, 2015 at 9:17 PM, Lin M wrote: > >> Sorry... >> >> The vtkControlPointArray is the subclass of vtkMappedDataArray. I define >> a variable to indicate that the begin idx of the patch which I assume will >> be set when vtkBezierPatchAdaptor::Next() or vtkBezierPatchAdaptor::GoToPatch() >> is called. >> >> On Thu, Jun 18, 2015 at 9:11 PM, David Thompson < >> david.thompson at kitware.com> wrote: >> >>> Hi Lin, >>> >>> It looks like you forgot to add the header and implementation files to >>> the commit. >>> >>> David >>> >>> > On Jun 18, 2015, at 9:08 PM, Lin M wrote: >>> > >>> > Hi Dr. Thompson, >>> > >>> > I have added one commit which contains a vtkMappedDataArray subclass >>> but I'm not sure I totally get the idea about the in-situ data structures. >>> Can you take a look at it please? ( >>> https://gitlab.kitware.com/splines/vtk/merge_requests/4) >>> > >>> > Best, >>> > Lin >>> > >>> > On Thu, Jun 18, 2015 at 10:47 AM, David Thompson < >>> david.thompson at kitware.com> wrote: >>> > Hi Lin, >>> > >>> > > From some examples I saw, usually we put some points in vtkPoints, >>> store the connectivity in cellArray and add them to a dataset (vtkPolyData, >>> vtkStructuredGrid or vtkUnstructureGrid). So is that we store the control >>> point of multiple patches in the vtkPoints where we replace the >>> vtkDataArray with vtkMappedDataArray now? And in a vtkMappedDataArray, we >>> store all the points for all patches together but we overwrite how to >>> iterate the array. >>> > >>> > That is nearly correct. We will accept >>> > >>> > vtkDataObject* ControlPointData; >>> > >>> > from the user. For the case we will implement first, >>> ControlPointData's actual type will be the vtkStructuredGrid subclass of >>> vtkDataObject. The vtkStructuredGrid instance can hold many user-supplied >>> vtkDataArray instances: >>> > >>> > vtkStructuredGrid* structuredControlPoints = >>> > vtkStructuredGrid::SafeDownCast(ControlPointData); >>> > >>> > // Control points to map from parameter-space to world coordinates: >>> > vtkDataArray* geometricControlPoints = >>> > structuredControlPoints->GetPoints()->GetData(); >>> > >>> > // Control points to map from paramter-space to scalar fields: >>> > vtkDataSetAttributes* scalarFields = >>> structuredControlPoints->GetPointData(); >>> > vtkIdType numScalarFields = scalarFields->GetNumberOfArrays(); >>> > for (vtkIdType i = 0; i < numScalarFields; ++i) >>> > { // scalarFieldControlPoints will hold things like temperature, >>> pressure, etc.: >>> > vtkDataArray* scalarFieldControlPoints = >>> scalarFields->GetArray(i); >>> > } >>> > >>> > Because the user supplies these arrays, we cannot force them to be >>> vtkMappedDataArray. Instead, we can make a vtkMappedDataArray subclass that >>> owns a reference to one of the arrays above and only returns one patch's >>> values from the user-supplied array (which holds the values for all patches >>> in the spline). >>> > >>> > The BezierPatchAdaptor below would return instances of our >>> vtkMappedDataArray when its GetPatchPoints method is called. Now that I've >>> written some more out, it looks like the API should be changed a little bit >>> so that users can ask for a particular array (geometricControlPoints or >>> scalarFieldControlPoints): >>> > >>> > class vtkBezierPatchAdaptor : public vtkObject >>> > { >>> > public: >>> > virtual void SetControlPointData(vtkDataObject* controlPointData); >>> > vtkGetObjectMacro(vtkDataObject,ControlPointData); >>> > >>> > // Methods to iterate over patches: >>> > // ... same as below ... >>> > >>> > // Methods to access the current patch: >>> > // ... >>> > virtual vtkSmartPointer GetPatchPoints(int >>> scalarField) const = 0; >>> > // ... >>> > }; >>> > >>> > This way, GetPatchPoints() could return the vtkMappedDataArray for >>> geometricControlPoints when the "int scalarField" argument is negative >>> value and a vtkMappedDataArray for one of the scalarFieldControlPoints >>> arrays when scalarField is positive. >>> > >>> > Having GetPatchPoints() return a smart pointer to a vtkMappedDataArray >>> subclass would also get around the issue that vtkPoints expects its >>> vtkDataArray to have 3 components per tuple (where ours will have 4 for >>> geometricControlPoints or an arbitrary number for scalarFieldControlPoints). >>> > >>> > The vtkMappedDataArray instances would own a weak reference back the >>> vtkBezierPatchAdaptor which created them and a weak reference to the >>> geometricControlPoints or scalarFieldControlPoints array it draws values >>> from. When vtkBezierPatchAdaptor::Next() or >>> vtkBezierPatchAdaptor::GoToPatch() is called, the adaptor would iterate >>> over all of the vtkMappedDataArray instances it owns and change an internal >>> variable so they would return values for the proper patch. That way the >>> vtkMappedDataArray instances only have to be created once for each spline >>> dataset, not once per patch. >>> > >>> > Is that clear enough, or should I sketch out a header file for our >>> vtkMappedDataArray subclass? >>> > >>> > David >>> > >>> > > On Wed, Jun 17, 2015 at 10:22 PM, David Thompson < >>> david.thompson at kitware.com> wrote: >>> > > Hi Lin, >>> > > >>> > >> Sorry for late reply. Since the midterm is coming, I'll definitely >>> speed up the development from now on. >>> > > >>> > > We both need to do a little more work. I have been looking at how to >>> read data from PetIGA so we can show some actual simulation data and have >>> some 3-D volumetric examples. >>> > > >>> > > It would be nice to have a patch ready to merge into VTK's master >>> branch at the midterm that provides spline interpolation and tests it for >>> all 3 parametric dimensions (curves, surfaces, and volumes). The means >>> producing triangles and tetrahedra, not just polylines. >>> > > >>> > >> I have a question about the class design in your last email. To my >>> understanding, control points for one patch is stored in a vtkDataArray. >>> > > >>> > > Close. I think that we should use the vtkMappedDataArray class to >>> hold control points for multiple patches but program it to appear as if >>> points for each individual patch are stored in patch-order. >>> > > >>> > >> Do you mean store multiple vtkDataArray regarding to multiple >>> patches in the vtkDataObject? >>> > > >>> > > There would be one data array to hold point coordinates, but other >>> arrays would hold simulation variables like temperature, pressure, >>> velocity, and so on. >>> > > >>> > >> If so, what class do I need to use for vtkDataObject? >>> > > >>> > > The class outline below is an abstract class. A concrete >>> implementation for NURBs would require the base class's ControlPointData >>> to be an instance of vtkStructuredGrid. A T-spline implementation might >>> expect ControlPointData to be a vtkUnstructuredGrid. I think all we should >>> do this summer is the NURBs case. >>> > > >>> > > David >>> > > >>> > >> >>> > >> On Wed, Jun 10, 2015 at 2:39 PM, David Thompson < >>> david.thompson at kitware.com> wrote: >>> > >> Hi Lin, >>> > >> >>> > >> > I have made it support 3D ellipse with function ... >>> > >> >>> > >> Great! >>> > >> >>> > >> > As you can see in the python test, I call this function 4 times >>> for each quadrant to generate the entire ellipse. Since we need to support >>> multiple patches, I think it's better to define a new dataset class for >>> bezier patches as you mentioned before about creating a new >>> vtkControlPoints class that inherits from vtkPoints and allows for an extra >>> coordinate. >>> > >> >>> > >> Rather than create new dataset types, I would like to use existing >>> datatypes to store the data and make an adaptor to iterate over them. That >>> way existing pipelines could modify scalar values defined on control points >>> (and perhaps even patches). For instance, B-splines could be represented as >>> a vtkStructuredGrid whose FieldData contains a special knot array (special >>> in the sense that the array must be of the proper size and with a fixed >>> name like "_vtkKnotVector"). >>> > >> >>> > >> The adaptor would take a vtkDataObject as input and provide >>> iterator-style access to each patch defined by the dataset. Specific >>> subclasses of the adaptor would be B-splines (which expect the >>> vtkDataObject to be a vtkStructuredGrid) or T-splines (which might expect a >>> vtkUniformGridAMR) or even point-based splines (PB-splines as defined in >>> Sederberg's T-spline paper, which could expect any dataset derived >>> vtkPointSet). >>> > >> >>> > >> class vtkBezierPatchAdaptor : public vtkObject >>> > >> { >>> > >> public: >>> > >> virtual void SetControlPointData(vtkDataObject* controlPointData); >>> > >> vtkGetObjectMacro(vtkDataObject,ControlPointData); >>> > >> >>> > >> // Methods to iterate over patches: >>> > >> virtual void Begin() = 0; >>> > >> virtual bool IsAtEnd() = 0; >>> > >> virtual bool GoToPatch(vtkIdType patchId) = 0; // random access >>> iteration >>> > >> virtual bool Next() = 0; >>> > >> >>> > >> // Methods to access the current patch: >>> > >> virtual int GetPatchDimension() const = 0; >>> > >> virtual void GetPatchShape() const = 0; >>> > >> // returns VTK_TRIANGLE/VTK_QUAD when PatchDimension==2, >>> > >> // returns VTK_HEXAHEDRON/VTK_TETRA when PatchDimension==3 >>> > >> virtual void GetPatchDegree(int* degreeOut) const = 0; >>> > >> virtual void GetPatchParameterRange(double* paramsOut) const = 0; >>> > >> virtual void GetPatchPoints(vtkPoints* pointsOut) const = 0; >>> > >> >>> > >> // Some helper methods that would make Python wrappings usable: >>> > >> int GetPatchDegree(int dim) const >>> > >> { >>> > >> std::vector degree(this->GetPatchDimension()); >>> > >> this->GetPatchDegree(°ree[0]); >>> > >> return degree[dim]; >>> > >> } >>> > >> void GetPatchParameterRange(int dim, double paramRange[2]) >>> > >> { >>> > >> std::vector range(2 * this->GetPatchDimension()); >>> > >> this->GetPatchDegree(&range[0]); >>> > >> paramRange[0] = [2 * dim]; >>> > >> paramRange[1] = [2 * dim + 1]; >>> > >> } >>> > >> >>> > >> protected: >>> > >> vtkDataObject* ControlPointData; >>> > >> }; >>> > >> >>> > >> The B-spline subclass could then iterate over patches by keeping a >>> current "cell ID," which would be incremented by calling Next(). When asked >>> for the *patch* points (not the input points), the adaptor would create a >>> vtkMappedDataArray (see http://www.vtk.org/Wiki/VTK/InSituDataStructure >>> for more information) that did not copy control point coordinates from its >>> ControlPointData->GetPoints() but instead used the implicit connectivity to >>> provide access to underlying B-spline points. >>> > >> >>> > >> For example, consider the simple case of a rectangular B-spline >>> with degree 1 (bi-linear). We might be given a 5x6 grid of control points >>> as input and asked to iterate over all the patches. Each patch is simply a >>> quadrilateral, and there are (5-1)*(6-1) = 20 of them. >>> > >> >>> > >> adaptor->Begin(); // would initialize an internal "cell ID" to 0 >>> > >> adaptor->IsAtEnd(); // would return false for "cell ID" values in >>> [0,19] and true otherwise. >>> > >> adaptor->GetPatchDimension(); // would return 2 >>> > >> adaptor->GetPatchShape(); // would return VTK_QUAD >>> > >> adaptor->GetPatchDegree(degreeOut); // would populate degreeOut >>> with [1,1] >>> > >> adaptor->GetPatchPoints(pointsOut); // would populate pointsOut >>> with a vtkMappedDataArray. >>> > >> >>> > >> The vtkMappedDataArray would report having 4 tuples (one for each >>> corner of the quad... when the degree is higher, is would report the >>> product of (degreeOut[i]+1) for all i in GetPatchDimension()). The actual >>> points reported would depend on the "cell ID" in the adaptor. >>> > >> >>> > >> I have not figured out yet how the "w" homogeneous coordinate would >>> work with vtkPoints. A different adaptor API might work better (keeping the >>> "w" coordinate separate from the other points). >>> > >> >>> > >> > Another question is that currently the domain of parameter >>> coordinate is [0, 1] for each patch. Do you think it's better to make the >>> domain continuously, namely [0, 0.25] for the first quadrant, [0.25, 0.75] >>> for the second quadrant, etc? >>> > >> >>> > >> If we focus on the B-spline adaptor above, we get that for free >>> since the returned knot vector could be normalized to the range [0,1]. >>> > >> >>> > >> David >>> > >> >>> > > >>> > >>> > >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri Jun 19 18:30:56 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 19 Jun 2015 18:30:56 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> Message-ID: <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> Hi Lin, > I get it now. Previously I was thinking of bezier patches so we need explicit definition about the degree to each dimension given a control point array. We are now considering NURBS whose degree of interpolant has been implicit defined together by the knot vectors and control points (degree + number of control points = number of knot vector entries) but if we assume all the control points for all patches are stored in one vtkStructureGrid instance (the points are ultimately stored in the vtkDataArray* vtkStructureGrid->GetPoints()->GetData()), we still need to know where the i-th patch begins in the vtkDataArray. Right, but this can be inferred from the knot vector and the regular arrangement of the points in a spline's control polygon. > > What we want to implement now is to use vtkMappedDataArray to retrieve a "fake" vtkDataArray for one patch from the original vtkDataArray. Exactly! David From david.thompson at kitware.com Fri Jun 19 19:30:27 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 19 Jun 2015 19:30:27 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> Message-ID: <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> Hi Lin, I've just realized that the control points for B?zier patches will not have the same coordinates as the NURBs control points. That's because the B?zier patches interpolate their corner control points. So, we cannot just use a mapped data array to provide access to a subset of the NURBS control polygon. This site: http://www.mactech.com/articles/develop/issue_25/schneider.html describes the conversion process for curves in its "CONVERTING NURB TO B?ZIER CURVES" section. Basically, we need to implement knot insertion, which is described in Piegl's NURBS Book in Chapter 5. The adaptor class shouldn't need to change much, but it might be better not to use a vtkMappedDataArray for the NURBS adaptor since it will have to generate new control points. David > On Jun 19, 2015, at 7:04 PM, David Thompson wrote: > > Hi Lin, > >> Does different patches in one vtkStructuredGrid have same order of interpolant and same number of control points? > > No, all the patches in a NURBs control polygon should have the same degree and control-point topology. > >> Each patch should have its own knot vector, so number of patches = number of knot vectors. > > Not quite. Each patch has a range of knot values. Those ranges overlap more as the degree increases. > > David From bill.lorensen at gmail.com Sat Jun 20 14:31:09 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Sat, 20 Jun 2015 14:31:09 -0400 Subject: [vtk-developers] Pyramid and QuadraticPyramid formulation issues Message-ID: Folks, As I continue to work through a comprehensive unit test for vtk cells, I have found an issue(s) with vtkPyramid and vtkQuadraticPyramid. For example, the parametric coordinates for the Pyramid (and Quadratic Pyramid) place the apex at 0, 0, 1. I believe it should be centered on the base (which would be .5, .5, 1). Changing that causes other issues with the shape functions. I am seeking a copy of the reference quoted in the QuadraticPyramid code so that I can verify the implementation. // The shape functions and derivatives could be implemented thanks to // the report Pyramid Solid Elements Linear and Quadratic Iso-P Models // From Center For Aerospace Structures From madaramh at gmail.com Sun Jun 21 23:34:27 2015 From: madaramh at gmail.com (madz) Date: Sun, 21 Jun 2015 20:34:27 -0700 (MST) Subject: [vtk-developers] Bug in vtk 6.0 - vtkGenericEnSightReader Message-ID: <1434944067666-5732470.post@n5.nabble.com> I have tried to read an EnsightFile in vtk version 6.2 but it seems that I was not getting the correct result, so I tested the code in vtk version 6.0 it gives an erroneous value for the number of points as well; vtkSmartPointer reader = vtkSmartPointer::New(); reader->SetCaseFileName(name); reader->Update(); vtkSmartPointer compositeFilter = vtkSmartPointer::New(); compositeFilter->SetInputConnection(reader->GetOutputPort()); compositeFilter->Update(); int num = compositeFilter->GetOutput()->GetNumberOfPoints(); //for vs 6.0 and 6.2 this gives 163736 but in vtk 5.8 it gives 1098108 I have tried the same code in vtk version 5.8 and it seems to give the correct value, which is almost 7 times as large. I think that the latter versions omit the points inside the model and only gives the boundary points. What sort of workaround should I use to get the correct results in vtk 6.2? -- View this message in context: http://vtk.1045678.n5.nabble.com/Bug-in-vtk-6-0-vtkGenericEnSightReader-tp5732470.html Sent from the VTK - Dev mailing list archive at Nabble.com. From joachim.pouderoux at kitware.com Mon Jun 22 03:30:46 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Mon, 22 Jun 2015 09:30:46 +0200 Subject: [vtk-developers] Bug in vtk 6.0 - vtkGenericEnSightReader In-Reply-To: <1434944067666-5732470.post@n5.nabble.com> References: <1434944067666-5732470.post@n5.nabble.com> Message-ID: Hello, I am not sure to understand why this would be a bug? The geometry filter will indeed extract the boundary polygons of the provided input. There is no specific guaranty that the filter will shallow copy (ie. pass) the input points from the input to the output (and its even more true for structured data that have implicit point set). As far as the output of the geometry filter contains a point set (vtkPoints) that contains all the points needed to represent the 'crust', everything is OK. Take a look at DataSetSurfaceFilter v6.x (internally called bu CompositeDataGeometryFilter), if the data is unstructured (I guess it is your case), it will call the vtkUnstructuredGridGeometryFilter. What this filter does is that it will shallow copy input point set to the output if the grid does not contains any quadratic cells, otherwise it will create a new point set and add only points needed for boundary polygon cells. In VTK 5.8, this all happens in vtkGeometryFilter.cxx instead, and no support was done for quadratic cells, in all cases the points were pass from the input to the output. So if you need to know the number of the input grid, just call reader->GetOutput()->GetNumberOfPoints(), it will always be safer! Best, *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2015-06-22 5:34 GMT+02:00 madz : > I have tried to read an EnsightFile in vtk version 6.2 but it seems that I > was not getting the correct result, so I tested the code in vtk version 6.0 > it gives an erroneous value for the number of points as well; > > > vtkSmartPointer reader = > vtkSmartPointer::New(); > reader->SetCaseFileName(name); > reader->Update(); > vtkSmartPointer compositeFilter = > vtkSmartPointer::New(); > compositeFilter->SetInputConnection(reader->GetOutputPort()); > compositeFilter->Update(); > > int num = compositeFilter->GetOutput()->GetNumberOfPoints(); //for > vs 6.0 and 6.2 this gives 163736 but in vtk 5.8 it gives 1098108 > > I have tried the same code in vtk version 5.8 and it seems to give the > correct value, which is almost 7 times as large. I think that the latter > versions omit the points inside the model and only gives the boundary > points. What sort of workaround should I use to get the correct results in > vtk 6.2? > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Bug-in-vtk-6-0-vtkGenericEnSightReader-tp5732470.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From will.schroeder at kitware.com Mon Jun 22 06:29:12 2015 From: will.schroeder at kitware.com (Will Schroeder) Date: Mon, 22 Jun 2015 06:29:12 -0400 Subject: [vtk-developers] Pyramid and QuadraticPyramid formulation issues In-Reply-To: References: Message-ID: Bill it could be that the vtkPyramid functions were originally written (a long time ago) as degenerate hex shape functions which might explain the apex parametric coordinates. I believe Mathieu found and implemented an alternative formulation and also added the quadratic version; I'm not sure where to find that reference. W On Sat, Jun 20, 2015 at 2:31 PM, Bill Lorensen wrote: > Folks, > > As I continue to work through a comprehensive unit test for vtk cells, > I have found an issue(s) with vtkPyramid and vtkQuadraticPyramid. > > For example, the parametric coordinates for the Pyramid (and Quadratic > Pyramid) place the apex at 0, 0, 1. I believe it should be centered on > the base (which would be .5, .5, 1). > > Changing that causes other issues with the shape functions. > > I am seeking a copy of the reference quoted in the QuadraticPyramid > code so that I can verify the implementation. > // The shape functions and derivatives could be implemented thanks to > // the report Pyramid Solid Elements Linear and Quadratic Iso-P Models > // From Center For Aerospace Structures > -- 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 andy.bauer at kitware.com Mon Jun 22 14:17:26 2015 From: andy.bauer at kitware.com (Andy Bauer) Date: Mon, 22 Jun 2015 14:17:26 -0400 Subject: [vtk-developers] Pyramid and QuadraticPyramid formulation issues In-Reply-To: References: Message-ID: Hi Bill, It looks to me like the apex of vtkPyramid is at {.5, .5, 1}. I used this test code to play around with it: from vtk import * ugrid = vtkUnstructuredGrid() pts = vtkPoints() pts.InsertNextPoint(0, 0, 0) pts.InsertNextPoint(1, 0, 0) pts.InsertNextPoint(1, 1, 0) pts.InsertNextPoint(0, 1, 0) pts.InsertNextPoint(.5, .5, 1) ugrid.SetPoints(pts) ugrid.Allocate(10) p = [0, 1, 2, 3, 4] ugrid.InsertNextCell(VTK_PYRAMID, 5, p) c = ugrid.GetCell(0) pcoords = [0, 0, 0] x = [0, 0, 0] w = [0, 0, 0, 0, 0] subid = vtk.mutable(0) # EvaluateLocation() is from parametric to global coordinate c.EvaluateLocation(subid, pcoords, x, w) print x pcoords = [.5, .5, 1] c.EvaluateLocation(subid, pcoords, x, w) # EvaluatePosition() is from global to parametric coordinate x = [.5, .5, 1] closestpoint = [-1, -1, -1] dist2 = vtk.mutable(0) result = c.EvaluatePosition(x, closestpoint, subid, pcoords, dist2, w) print result, pcoords I didn't test vtkQuadraticPyramid though. Looking at the vtkPyramid.h though I see the following which looks wrong to me: //---------------------------------------------------------------------------- inline int vtkPyramid::GetParametricCenter(double pcoords[3]) { pcoords[0] = pcoords[1] = 0.4; pcoords[2] = 0.2; return 0; } I would have thought that pcoords[0] and pcoords[1] should be 0.5 instead of 0.4. Since the volume of the above cell is 1/3 I would also think that pcoords[2] should be 1/3 instead of 0.2, but I may be wrong on that. It's also kind of weird that in vtkQuadraticPyramid.h that method is: //---------------------------------------------------------------------------- // Return the center of the quadratic pyramid in parametric coordinates. // inline int vtkQuadraticPyramid::GetParametricCenter(double pcoords[3]) { pcoords[0] = pcoords[1] = 6./13; pcoords[2] = 3./13; return 0; } Just my 2 cents on the matter though since I haven't gone through the code that closely. Cheers, Andy On Mon, Jun 22, 2015 at 6:29 AM, Will Schroeder wrote: > Bill it could be that the vtkPyramid functions were originally written (a > long time ago) as degenerate hex shape functions which might explain the > apex parametric coordinates. I believe Mathieu found and implemented an > alternative formulation and also added the quadratic version; I'm not sure > where to find that reference. > W > > On Sat, Jun 20, 2015 at 2:31 PM, Bill Lorensen > wrote: > >> Folks, >> >> As I continue to work through a comprehensive unit test for vtk cells, >> I have found an issue(s) with vtkPyramid and vtkQuadraticPyramid. >> >> For example, the parametric coordinates for the Pyramid (and Quadratic >> Pyramid) place the apex at 0, 0, 1. I believe it should be centered on >> the base (which would be .5, .5, 1). >> >> Changing that causes other issues with the shape functions. >> >> I am seeking a copy of the reference quoted in the QuadraticPyramid >> code so that I can verify the implementation. >> // The shape functions and derivatives could be implemented thanks to >> // the report Pyramid Solid Elements Linear and Quadratic Iso-P Models >> // From Center For Aerospace Structures >> > > > > -- > 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 bill.lorensen at gmail.com Mon Jun 22 16:12:30 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Mon, 22 Jun 2015 16:12:30 -0400 Subject: [vtk-developers] Pyramid and QuadraticPyramid formulation issues In-Reply-To: References: Message-ID: Andy, Thanks, These are the sorts of things I am uncovering in the new unit test I'm working on. Bill On Mon, Jun 22, 2015 at 2:17 PM, Andy Bauer wrote: > Hi Bill, > > It looks to me like the apex of vtkPyramid is at {.5, .5, 1}. I used this > test code to play around with it: > from vtk import * > ugrid = vtkUnstructuredGrid() > pts = vtkPoints() > pts.InsertNextPoint(0, 0, 0) > pts.InsertNextPoint(1, 0, 0) > pts.InsertNextPoint(1, 1, 0) > pts.InsertNextPoint(0, 1, 0) > pts.InsertNextPoint(.5, .5, 1) > ugrid.SetPoints(pts) > ugrid.Allocate(10) > p = [0, 1, 2, 3, 4] > ugrid.InsertNextCell(VTK_PYRAMID, 5, p) > c = ugrid.GetCell(0) > pcoords = [0, 0, 0] > x = [0, 0, 0] > w = [0, 0, 0, 0, 0] > subid = vtk.mutable(0) > # EvaluateLocation() is from parametric to global coordinate > c.EvaluateLocation(subid, pcoords, x, w) > print x > pcoords = [.5, .5, 1] > c.EvaluateLocation(subid, pcoords, x, w) > > # EvaluatePosition() is from global to parametric coordinate > x = [.5, .5, 1] > closestpoint = [-1, -1, -1] > dist2 = vtk.mutable(0) > result = c.EvaluatePosition(x, closestpoint, subid, pcoords, dist2, w) > print result, pcoords > > > > > > I didn't test vtkQuadraticPyramid though. Looking at the vtkPyramid.h though > I see the following which looks wrong to me: > //---------------------------------------------------------------------------- > inline int vtkPyramid::GetParametricCenter(double pcoords[3]) > { > pcoords[0] = pcoords[1] = 0.4; > pcoords[2] = 0.2; > return 0; > } > > > I would have thought that pcoords[0] and pcoords[1] should be 0.5 instead of > 0.4. Since the volume of the above cell is 1/3 I would also think that > pcoords[2] should be 1/3 instead of 0.2, but I may be wrong on that. It's > also kind of weird that in vtkQuadraticPyramid.h that method is: > //---------------------------------------------------------------------------- > // Return the center of the quadratic pyramid in parametric coordinates. > // > inline int vtkQuadraticPyramid::GetParametricCenter(double pcoords[3]) > { > pcoords[0] = pcoords[1] = 6./13; > pcoords[2] = 3./13; > return 0; > } > > Just my 2 cents on the matter though since I haven't gone through the code > that closely. > > Cheers, > Andy > > On Mon, Jun 22, 2015 at 6:29 AM, Will Schroeder > wrote: >> >> Bill it could be that the vtkPyramid functions were originally written (a >> long time ago) as degenerate hex shape functions which might explain the >> apex parametric coordinates. I believe Mathieu found and implemented an >> alternative formulation and also added the quadratic version; I'm not sure >> where to find that reference. >> W >> >> On Sat, Jun 20, 2015 at 2:31 PM, Bill Lorensen >> wrote: >>> >>> Folks, >>> >>> As I continue to work through a comprehensive unit test for vtk cells, >>> I have found an issue(s) with vtkPyramid and vtkQuadraticPyramid. >>> >>> For example, the parametric coordinates for the Pyramid (and Quadratic >>> Pyramid) place the apex at 0, 0, 1. I believe it should be centered on >>> the base (which would be .5, .5, 1). >>> >>> Changing that causes other issues with the shape functions. >>> >>> I am seeking a copy of the reference quoted in the QuadraticPyramid >>> code so that I can verify the implementation. >>> // The shape functions and derivatives could be implemented thanks to >>> // the report Pyramid Solid Elements Linear and Quadratic Iso-P Models >>> // From Center For Aerospace Structures >> >> >> >> >> -- >> 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 >> >> > -- Unpaid intern in BillsBasement at noware dot com From majcjc at gmail.com Mon Jun 22 17:05:37 2015 From: majcjc at gmail.com (Lin M) Date: Mon, 22 Jun 2015 17:05:37 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> Message-ID: Hi Dr. Thompson, I think one of my problem now is that I'm not sure how patches connecting with each other. Originally I thought patches in a shape are irrelevant with each other. For example in the ellipse, we need 4 patches for each quadrant and I generate four patches independently only that they share same end points, but from your previous email I think for NURBs it's not exactly true. Another is that if a NURBs shape is given by a vtkStructuredGrid and a know vector, how to infer the number of patches, degree of interpolant and number of control points. Best, Lin On Fri, Jun 19, 2015 at 7:30 PM, David Thompson wrote: > Hi Lin, > > I've just realized that the control points for B?zier patches will not > have the same coordinates as the NURBs control points. That's because the > B?zier patches interpolate their corner control points. So, we cannot just > use a mapped data array to provide access to a subset of the NURBS control > polygon. > > This site: > > http://www.mactech.com/articles/develop/issue_25/schneider.html > > describes the conversion process for curves in its "CONVERTING NURB TO > B?ZIER CURVES" section. Basically, we need to implement knot insertion, > which is described in Piegl's NURBS Book in Chapter 5. > > The adaptor class shouldn't need to change much, but it might be better > not to use a vtkMappedDataArray for the NURBS adaptor since it will have to > generate new control points. > > David > > > > On Jun 19, 2015, at 7:04 PM, David Thompson > wrote: > > > > Hi Lin, > > > >> Does different patches in one vtkStructuredGrid have same order of > interpolant and same number of control points? > > > > No, all the patches in a NURBs control polygon should have the same > degree and control-point topology. > > > >> Each patch should have its own knot vector, so number of patches = > number of knot vectors. > > > > Not quite. Each patch has a range of knot values. Those ranges overlap > more as the degree increases. > > > > David > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon Jun 22 17:31:33 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 22 Jun 2015 17:31:33 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> Message-ID: <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> Hi Lin, > I think one of my problem now is that I'm not sure how patches connecting with each other. Yes, it is not straightforward. > Originally I thought patches in a shape are irrelevant with each other. For example in the ellipse, we need 4 patches for each quadrant and I generate four patches independently only that they share same end points, but from your previous email I think for NURBs it's not exactly true. Correct. The difference is that NURBS do not always interpolate their endpoints and can have regions whose parameter value ranges are non-uniform (the "NU" in "NURBS"), while B?zier patches interpolate their endpoints. NURBS only interpolate their control-polygon when a value in the knot vector is repeated the same number of times as the degree of the curve -- e.g., a quadratic NURBS curve with a knot vector of [0, 0, 1, 2, 2] will interpolate the endpoints of its control polygon. But the same control polygon could have a knot vector [0, 1, 2, 3, 3] and only the final control polygon point would be interpolated. See https://en.wikipedia.org/wiki/NURBS#Comparison_of_Knots_and_Control_Points for some more information. > Another is that if a NURBs shape is given by a vtkStructuredGrid and a know vector, how to infer the number of patches, degree of interpolant and number of control points. The wikipedia link above discusses this: "In general, the knots break the domain up into knot spans, but each control point corresponds to one basis function which spans a range of (degree+1) knot spans." So, knowing the length, K, of the knot vector (along one axis) and the number, N, of control-polygon points (along the same axis), you can get the degree of the interpolant: degree + N - 1 = K. In the wikipedia example, degree = 3, N = 7, and the knot vector is length K = 9. What all of this means is that there is a relationship between the NURBS control points and the corresponding B?zier control points, but they are not identical except for the special case where the knot values are always repeated degree-times. The knot insertion algorithm provides a way to obtain a NURBS curve that meets this condition, and then we can use its control points in the B?zier interpolation algorithm. So, the first step toward NURBS interpolation is to get knot insertion working. David > On Fri, Jun 19, 2015 at 7:30 PM, David Thompson wrote: > Hi Lin, > > I've just realized that the control points for B?zier patches will not have the same coordinates as the NURBs control points. That's because the B?zier patches interpolate their corner control points. So, we cannot just use a mapped data array to provide access to a subset of the NURBS control polygon. > > This site: > > http://www.mactech.com/articles/develop/issue_25/schneider.html > > describes the conversion process for curves in its "CONVERTING NURB TO B?ZIER CURVES" section. Basically, we need to implement knot insertion, which is described in Piegl's NURBS Book in Chapter 5. > > The adaptor class shouldn't need to change much, but it might be better not to use a vtkMappedDataArray for the NURBS adaptor since it will have to generate new control points. > > David > > > > On Jun 19, 2015, at 7:04 PM, David Thompson wrote: > > > > Hi Lin, > > > >> Does different patches in one vtkStructuredGrid have same order of interpolant and same number of control points? > > > > No, all the patches in a NURBs control polygon should have the same degree and control-point topology. > > > >> Each patch should have its own knot vector, so number of patches = number of knot vectors. > > > > Not quite. Each patch has a range of knot values. Those ranges overlap more as the degree increases. > > > > David > > From majcjc at gmail.com Mon Jun 22 18:46:15 2015 From: majcjc at gmail.com (Lin M) Date: Mon, 22 Jun 2015 18:46:15 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> Message-ID: I have some questions here. Correct. The difference is that NURBS do not always interpolate their endpoints and can have regions whose parameter value ranges are non-uniform (the "NU" in "NURBS"), while B?zier patches interpolate their endpoints. 1. The definition of knot vector seems to be a little different from the NURBS book. In the NURBS book, a knot vector is defined as U = {a,...,a,u_{p+1},...,u_{m-p-1},b,...,b} where a and b are repeated p+1 times (p is the degree of NURBS curve). And since NURBS cruve is defined as C(u) = sum_{i,n}(N_{i,p}(u)*P_{i}), the endpoints seems to be interpolated as well. So, knowing the length, K, of the knot vector (along one axis) and the number, N, of control-polygon points (along the same axis), you can get the degree of the interpolant: degree + N - 1 = K. In the wikipedia example, degree = 3, N = 7, and the knot vector is length K = 9. 2. The previous section of the wiki page writes "The number of knots is always equal to the number of control points plus curve degree plus one (i.e. number of control points plus curve order)." Should it be degree + N + 1 = K ? 3. I think the inference is only for a single patch. If there are several patches in the vtkStructuredGrid, we can not get the number of control points for a certain patch by vtkStructuredGrid->GetDimension() unless we know the number of patches and the number of control points are the same for all these patches. On Mon, Jun 22, 2015 at 5:31 PM, David Thompson wrote: > Hi Lin, > > > I think one of my problem now is that I'm not sure how patches > connecting with each other. > > Yes, it is not straightforward. > > > Originally I thought patches in a shape are irrelevant with each other. > For example in the ellipse, we need 4 patches for each quadrant and I > generate four patches independently only that they share same end points, > but from your previous email I think for NURBs it's not exactly true. > > Correct. The difference is that NURBS do not always interpolate their > endpoints and can have regions whose parameter value ranges are non-uniform > (the "NU" in "NURBS"), while B?zier patches interpolate their endpoints. > NURBS only interpolate their control-polygon when a value in the knot > vector is repeated the same number of times as the degree of the curve -- > e.g., a quadratic NURBS curve with a knot vector of [0, 0, 1, 2, 2] will > interpolate the endpoints of its control polygon. But the same control > polygon could have a knot vector [0, 1, 2, 3, 3] and only the final control > polygon point would be interpolated. > > See > https://en.wikipedia.org/wiki/NURBS#Comparison_of_Knots_and_Control_Points > for some more information. > > > Another is that if a NURBs shape is given by a vtkStructuredGrid and a > know vector, how to infer the number of patches, degree of interpolant and > number of control points. > > The wikipedia link above discusses this: "In general, the knots break the > domain up into knot spans, but each control point corresponds to one basis > function which spans a range of (degree+1) knot spans." So, knowing the > length, K, of the knot vector (along one axis) and the number, N, of > control-polygon points (along the same axis), you can get the degree of the > interpolant: degree + N - 1 = K. In the wikipedia example, degree = 3, N = > 7, and the knot vector is length K = 9. > > What all of this means is that there is a relationship between the NURBS > control points and the corresponding B?zier control points, but they are > not identical except for the special case where the knot values are always > repeated degree-times. The knot insertion algorithm provides a way to > obtain a NURBS curve that meets this condition, and then we can use its > control points in the B?zier interpolation algorithm. > > So, the first step toward NURBS interpolation is to get knot insertion > working. > > David > > > > On Fri, Jun 19, 2015 at 7:30 PM, David Thompson < > david.thompson at kitware.com> wrote: > > Hi Lin, > > > > I've just realized that the control points for B?zier patches will not > have the same coordinates as the NURBs control points. That's because the > B?zier patches interpolate their corner control points. So, we cannot just > use a mapped data array to provide access to a subset of the NURBS control > polygon. > > > > This site: > > > > http://www.mactech.com/articles/develop/issue_25/schneider.html > > > > describes the conversion process for curves in its "CONVERTING NURB TO > B?ZIER CURVES" section. Basically, we need to implement knot insertion, > which is described in Piegl's NURBS Book in Chapter 5. > > > > The adaptor class shouldn't need to change much, but it might be better > not to use a vtkMappedDataArray for the NURBS adaptor since it will have to > generate new control points. > > > > David > > > > > > > On Jun 19, 2015, at 7:04 PM, David Thompson < > david.thompson at kitware.com> wrote: > > > > > > Hi Lin, > > > > > >> Does different patches in one vtkStructuredGrid have same order of > interpolant and same number of control points? > > > > > > No, all the patches in a NURBs control polygon should have the same > degree and control-point topology. > > > > > >> Each patch should have its own knot vector, so number of patches = > number of knot vectors. > > > > > > Not quite. Each patch has a range of knot values. Those ranges overlap > more as the degree increases. > > > > > > David > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Mon Jun 22 18:54:17 2015 From: david.thompson at kitware.com (David Thompson) Date: Mon, 22 Jun 2015 18:54:17 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> Message-ID: <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> Hi Lin, > 1. The definition of knot vector seems to be a little different from the NURBS book. In the NURBS book, a knot vector is defined as U = {a,...,a,u_{p+1},...,u_{m-p-1},b,...,b} where a and b are repeated p+1 times (p is the degree of NURBS curve). And since NURBS cruve is defined as C(u) = sum_{i,n}(N_{i,p}(u)*P_{i}), the endpoints seems to be interpolated as well. NURBS do not require any knot vector entries to be repeated. Many examples in the NURBS book *happen* to have repeated entries, but it is not a requirement. > ... > 2. The previous section of the wiki page writes "The number of knots is always equal to the number of control points plus curve degree plus one (i.e. number of control points plus curve order)." Should it be degree + N + 1 = K ? From the wikipedia entry: "Some modelers that use older algorithms for NURBS evaluation require two extra knot values for a total of (degree+N+1) knots.[7]" You can use whichever you like. I would advise sticking with the NURBS book because it has many examples worked out in detail. (The NURBS book appears to use the degree + N + 1 = K formulation.) > 3. I think the inference is only for a single patch. If there are several patches in the vtkStructuredGrid, we can not get the number of control points for a certain patch by vtkStructuredGrid->GetDimension() unless we know the number of patches and the number of control points are the same for all these patches. Nope, you can use GetDimension() to discover the number, N, of control points for all patches. That is related to the degree by the number of knot vector entries for all patches. We have not specified how the knot vector would be stored. If stored as an array in vtkFieldData, then we would also have to store the number entries along each axis (the equivalent information as GetDimension() returns for the control points). Or we could store the degree along each axis and use that to determine the size of the knot vector along each axis... whichever you prefer. David From andrew.amaclean at gmail.com Tue Jun 23 03:00:25 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Tue, 23 Jun 2015 17:00:25 +1000 Subject: [vtk-developers] For those using OpenGL2 in the VTK build. Message-ID: Hi All On my laptop which has an Intel and NVidiia card, I just discovered that my VTK programs were crashing with this message: "Warning: In \VTK\Rendering\OpenGL2\vtkOpenGLRenderWindow.cxx, line 426 vtkWin32OpenGLRenderWindow (0000000604268430): VTK is designed to work with OpenGL version 3.2 but it appears it has been given a context that does not support 3.2. VTK will run in a compatibility mode designed to work with OpenGL 2.1 but some features may not work. ERROR: In\ VTK\Rendering\OpenGL2\vtkShaderProgram.cxx, line 366 vtkShaderProgram (0000000607E3F060): 1: ... ERROR: In \VTK\Rendering\OpenGL2\vtkShaderProgram.cxx, line 367 vtkShaderProgram (0000000607E3F060): ERROR: 0:20: '' : extension 'GL_EXT_gpu_shader4' is not supported " To get rid of this error you must set the NVidia graphics processor as default. To do this: Go to the NVIDIA Control Panel (right-click on the desktop), then: 3D Settings-> Manage 3D settings The Tab "Preferred graphics processor " , select High performance NVidia processor Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Tue Jun 23 03:55:42 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Tue, 23 Jun 2015 00:55:42 -0700 (MST) Subject: [vtk-developers] Android: undefined reference to vtkRenderWindow::New() In-Reply-To: <1434561416248-5732424.post@n5.nabble.com> References: <1434554986629-5732418.post@n5.nabble.com> <1434561416248-5732424.post@n5.nabble.com> Message-ID: <1435046142805-5732490.post@n5.nabble.com> I've added this to my android.mk: /LOCAL_STATIC_LIBRARIES := cpufeatures android_native_app_glue ndk_helper \ libvtkalglib-6.3 \ libvtkCommonColor-6.3 \ libvtkCommonComputationalGeometry-6.3 \ libvtkCommonCore-6.3 \ libvtkCommonMath-6.3 \ libvtkCommonMisc-6.3 \ libvtkCommonSystem-6.3 \ libvtkCommonTransforms-6.3 \ libvtkDICOMParser-6.3 \ libvtkexpat-6.3 \ libvtkFiltersCore-6.3 \ libvtkFiltersExtraction-6.3 \ libvtkFiltersGeneral-6.3 \ libvtkFiltersGeometry-6.3 \ libvtkFiltersModeling-6.3 \ libvtkFiltersSources-6.3 \ libvtkFiltersStatistics-6.3 \ libvtkglew-6.3 \ libvtkImagingCore-6.3 \ libvtkImagingFourier-6.3 \ libvtkImagingHybrid-6.3 \ libvtkInfovisCore-6.3 \ libvtkInteractionStyle-6.3 \ libvtkIOCore-6.3 \ libvtkIOGeometry-6.3 \ libvtkIOImage-6.3 \ libvtkIOInfovis-6.3 \ libvtkIOLegacy-6.3 \ libvtkIOPLY-6.3 \ libvtkIOXML-6.3 \ libvtkIOXMLParser-6.3 \ libvtkjpeg-6.3 \ libvtkjsoncpp-6.3 \ libvtklibxml2-6.3 \ libvtkmetaio-6.3 \ libvtkParallelCore-6.3 \ libvtkpng-6.3 \ libvtkRenderingCore-6.3 \ libvtkRenderingOpenGL2-6.3 \ libvtksys-6.3 \ libvtktiff-6.3 \ libvtkzlib-6.3 LOCAL_CPP_FEATURES := rtti exceptions LOCAL_CPPFLAGS += --std=c++11 / But it still doesn't work. However I've noticed that the errors I get depends on the orders in which I add the vtk modules in LOCAL_MODULE -- View this message in context: http://vtk.1045678.n5.nabble.com/Android-undefined-reference-to-vtkRenderWindow-New-tp5732418p5732490.html Sent from the VTK - Dev mailing list archive at Nabble.com. From madaramh at gmail.com Tue Jun 23 04:05:16 2015 From: madaramh at gmail.com (madz) Date: Tue, 23 Jun 2015 01:05:16 -0700 (MST) Subject: [vtk-developers] Bug in vtk 6.0 - vtkGenericEnSightReader In-Reply-To: References: <1434944067666-5732470.post@n5.nabble.com> Message-ID: <1435046716867-5732491.post@n5.nabble.com> Thank you for the reply. That seems to be the case. Then how do I get the output (all points, not just surface) to a single polydata? I cannot call, vtkSmartPointer polydata = reader->GetOutput(); because that will give a multiblock. I tried the vtkGeometryFilter but it doesn't seem to work. -- View this message in context: http://vtk.1045678.n5.nabble.com/Bug-in-vtk-6-0-vtkGenericEnSightReader-tp5732470p5732491.html Sent from the VTK - Dev mailing list archive at Nabble.com. From joachim.pouderoux at kitware.com Tue Jun 23 04:35:29 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Tue, 23 Jun 2015 10:35:29 +0200 Subject: [vtk-developers] Bug in vtk 6.0 - vtkGenericEnSightReader In-Reply-To: <1435046716867-5732491.post@n5.nabble.com> References: <1434944067666-5732470.post@n5.nabble.com> <1435046716867-5732491.post@n5.nabble.com> Message-ID: The ensight reader create multiblock (composite) data object, if you want to extract one block from it, just use the vtkMultiBlockDataSet::GetBlock() function. I can't name a filter (don't think it exists) that would extract a dataset from a multiblock dataobject - the vtkExtractBlock actually generates a multiblock even if a single block is selected. Regarding the geometry, I don't understand what you intend to do: you have an unstructured (or a set of inside a multiblock) data object and you would like to transform it to a polydata mesh? What for? The geometry filter extracts the external boundary surfaces (polygons) of a mesh and generate a mesh that can be rendered with OpenGL (ie a Polydata) as it is useless (and too costly) to render all internal faces of the model. Again, the unstructured grid describes cell types (3d cells, 2d quadratic cells etc.) that cannot be described in a vtkPolyData dataset. *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2015-06-23 10:05 GMT+02:00 madz : > Thank you for the reply. That seems to be the case. Then how do I get the > output (all points, not just surface) to a single polydata? > I cannot call, > > vtkSmartPointer polydata = reader->GetOutput(); > > because that will give a multiblock. I tried the vtkGeometryFilter but it > doesn't seem to work. > > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Bug-in-vtk-6-0-vtkGenericEnSightReader-tp5732470p5732491.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joachim.pouderoux at kitware.com Tue Jun 23 04:44:48 2015 From: joachim.pouderoux at kitware.com (Joachim Pouderoux) Date: Tue, 23 Jun 2015 10:44:48 +0200 Subject: [vtk-developers] Bug in vtk 6.0 - vtkGenericEnSightReader In-Reply-To: References: <1434944067666-5732470.post@n5.nabble.com> <1435046716867-5732491.post@n5.nabble.com> Message-ID: Forgot to mention the vtkCompositeDataToUnstructuredGridFilter: it appends all the blocks of a multiblock data to a single unstructured grid object. *Joachim Pouderoux* *PhD, Technical Expert* *Kitware SAS * 2015-06-23 10:35 GMT+02:00 Joachim Pouderoux : > The ensight reader create multiblock (composite) data object, if you want > to extract one block from it, just use the vtkMultiBlockDataSet::GetBlock() > function. I can't name a filter (don't think it exists) that would extract > a dataset from a multiblock dataobject - the vtkExtractBlock actually > generates a multiblock even if a single block is selected. > > Regarding the geometry, I don't understand what you intend to do: you have > an unstructured (or a set of inside a multiblock) data object and you would > like to transform it to a polydata mesh? What for? The geometry filter > extracts the external boundary surfaces (polygons) of a mesh and generate a > mesh that can be rendered with OpenGL (ie a Polydata) as it is useless (and > too costly) to render all internal faces of the model. Again, the > unstructured grid describes cell types (3d cells, 2d quadratic cells etc.) > that cannot be described in a vtkPolyData dataset. > > > *Joachim Pouderoux* > > *PhD, Technical Expert* > *Kitware SAS * > > > 2015-06-23 10:05 GMT+02:00 madz : > >> Thank you for the reply. That seems to be the case. Then how do I get the >> output (all points, not just surface) to a single polydata? >> I cannot call, >> >> vtkSmartPointer polydata = reader->GetOutput(); >> >> because that will give a multiblock. I tried the vtkGeometryFilter but it >> doesn't seem to work. >> >> >> >> >> -- >> View this message in context: >> http://vtk.1045678.n5.nabble.com/Bug-in-vtk-6-0-vtkGenericEnSightReader-tp5732470p5732491.html >> Sent from the VTK - Dev mailing list archive at Nabble.com. >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From madaramh at gmail.com Tue Jun 23 04:56:57 2015 From: madaramh at gmail.com (madz) Date: Tue, 23 Jun 2015 01:56:57 -0700 (MST) Subject: [vtk-developers] Bug in vtk 6.0 - vtkGenericEnSightReader In-Reply-To: References: <1434944067666-5732470.post@n5.nabble.com> <1435046716867-5732491.post@n5.nabble.com> Message-ID: <1435049817376-5732494.post@n5.nabble.com> Thank you again for the reply. I need the polydata because I plan to cut the surface and take all the points of the resulting plane. I need the inside points as well for this function. I used the following method to get the polydata, as you suggested; vtkSmartPointer multiBlock = vtkSmartPointer::New(); multiBlock = reader->GetOutput(); vtkSmartPointer polydata; vtkSmartPointer appendFilter = vtkSmartPointer::New(); for(int i = 0; i < multiBlock->GetNumberOfBlocks(); i++){ vtkSmartPointer geom = vtkSmartPointer::New(); geom->SetInput(multiBlock->GetBlock(i)); geom->Update(); appendFilter->AddInputConnection(geom->GetOutputPort()); } appendFilter->Update(); polydata = appendFilter->GetOutput(); It seems to work :) -- View this message in context: http://vtk.1045678.n5.nabble.com/Bug-in-vtk-6-0-vtkGenericEnSightReader-tp5732470p5732494.html Sent from the VTK - Dev mailing list archive at Nabble.com. From lonni.besancon at gmail.com Tue Jun 23 08:07:30 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Tue, 23 Jun 2015 05:07:30 -0700 (MST) Subject: [vtk-developers] Building VTK with QT5.4 Windows 8 In-Reply-To: <1434622420322-5732429.post@n5.nabble.com> References: <1434546846947-5732403.post@n5.nabble.com> <55817942.30802@student.hpi.uni-potsdam.de> <1434549029258-5732410.post@n5.nabble.com> <55817B9F.3010109@student.hpi.uni-potsdam.de> <1434549883778-5732412.post@n5.nabble.com> <1434622420322-5732429.post@n5.nabble.com> Message-ID: <1435061250629-5732496.post@n5.nabble.com> Hi everyone, Still stuck there. Any more insights from someone who actually managed to include Qt ? Thanks in advance -- View this message in context: http://vtk.1045678.n5.nabble.com/Building-VTK-with-QT5-4-Windows-8-tp5732403p5732496.html Sent from the VTK - Dev mailing list archive at Nabble.com. From ken.martin at kitware.com Tue Jun 23 08:37:39 2015 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 23 Jun 2015 08:37:39 -0400 Subject: [vtk-developers] For those using OpenGL2 in the VTK build. In-Reply-To: References: Message-ID: <93a9a0fe0e00b08a6a9682d837c2cf0f@mail.gmail.com> Morning Andrew, Yes, for laptops with multiple graphics options you probably want to go with the dedicated graphics chip. Having said that, recent Intel chips should work with VTK. This page provides more detail if you expand the 4th/3 rd generation sections, etc. http://www.intel.com/support/graphics/sb/CS-033757.htm Intel 2500, 4000, 4200, 4400, 4600, 5000, 5100, 5200 and later should all support OpenGL 3.2. Intel 3000/2000/HD Graphics support 2.1 but not 3.2, but I?m not sure if they provide the required extensions. 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. *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf Of *Andrew Maclean *Sent:* Tuesday, June 23, 2015 3:00 AM *To:* VTK Developers; vtk *Subject:* [vtk-developers] For those using OpenGL2 in the VTK build. Hi All On my laptop which has an Intel and NVidiia card, I just discovered that my VTK programs were crashing with this message: "Warning: In \VTK\Rendering\OpenGL2\vtkOpenGLRenderWindow.cxx, line 426 vtkWin32OpenGLRenderWindow (0000000604268430): VTK is designed to work with OpenGL version 3.2 but it appears it has been given a context that does not support 3.2. VTK will run in a compatibility mode designed to work with OpenGL 2.1 but some features may not work. ERROR: In\ VTK\Rendering\OpenGL2\vtkShaderProgram.cxx, line 366 vtkShaderProgram (0000000607E3F060): 1: ... ERROR: In \VTK\Rendering\OpenGL2\vtkShaderProgram.cxx, line 367 vtkShaderProgram (0000000607E3F060): ERROR: 0:20: '' : extension 'GL_EXT_gpu_shader4' is not supported " To get rid of this error you must set the NVidia graphics processor as default. To do this: Go to the NVIDIA Control Panel (right-click on the desktop), then: 3D Settings-> Manage 3D settings The Tab "Preferred graphics processor " , select High performance NVidia processor Regards Andrew -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Tue Jun 23 08:40:45 2015 From: ken.martin at kitware.com (Ken Martin) Date: Tue, 23 Jun 2015 08:40:45 -0400 Subject: [vtk-developers] Android: undefined reference to vtkRenderWindow::New() In-Reply-To: <1435046142805-5732490.post@n5.nabble.com> References: <1434554986629-5732418.post@n5.nabble.com> <1434561416248-5732424.post@n5.nabble.com> <1435046142805-5732490.post@n5.nabble.com> Message-ID: <29c436f64921d96ac967a3353496ee4c@mail.gmail.com> I checked the build on my local system and it is messed up. Something has changed in the past months to break it. Unfortunately I do not have time to dig into it right now but it is on my list. I suspect it is fairly minor but finding it can be tricky sometimes. 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. -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Lonni Besan?on Sent: Tuesday, June 23, 2015 3:56 AM To: vtk-developers at vtk.org Subject: Re: [vtk-developers] Android: undefined reference to vtkRenderWindow::New() I've added this to my android.mk: /LOCAL_STATIC_LIBRARIES := cpufeatures android_native_app_glue ndk_helper \ libvtkalglib-6.3 \ libvtkCommonColor-6.3 \ libvtkCommonComputationalGeometry-6.3 \ libvtkCommonCore-6.3 \ libvtkCommonMath-6.3 \ libvtkCommonMisc-6.3 \ libvtkCommonSystem-6.3 \ libvtkCommonTransforms-6.3 \ libvtkDICOMParser-6.3 \ libvtkexpat-6.3 \ libvtkFiltersCore-6.3 \ libvtkFiltersExtraction-6.3 \ libvtkFiltersGeneral-6.3 \ libvtkFiltersGeometry-6.3 \ libvtkFiltersModeling-6.3 \ libvtkFiltersSources-6.3 \ libvtkFiltersStatistics-6.3 \ libvtkglew-6.3 \ libvtkImagingCore-6.3 \ libvtkImagingFourier-6.3 \ libvtkImagingHybrid-6.3 \ libvtkInfovisCore-6.3 \ libvtkInteractionStyle-6.3 \ libvtkIOCore-6.3 \ libvtkIOGeometry-6.3 \ libvtkIOImage-6.3 \ libvtkIOInfovis-6.3 \ libvtkIOLegacy-6.3 \ libvtkIOPLY-6.3 \ libvtkIOXML-6.3 \ libvtkIOXMLParser-6.3 \ libvtkjpeg-6.3 \ libvtkjsoncpp-6.3 \ libvtklibxml2-6.3 \ libvtkmetaio-6.3 \ libvtkParallelCore-6.3 \ libvtkpng-6.3 \ libvtkRenderingCore-6.3 \ libvtkRenderingOpenGL2-6.3 \ libvtksys-6.3 \ libvtktiff-6.3 \ libvtkzlib-6.3 LOCAL_CPP_FEATURES := rtti exceptions LOCAL_CPPFLAGS += --std=c++11 / But it still doesn't work. However I've noticed that the errors I get depends on the orders in which I add the vtk modules in LOCAL_MODULE -- View this message in context: http://vtk.1045678.n5.nabble.com/Android-undefined-reference-to-vtkRenderW indow-New-tp5732418p5732490.html Sent from the VTK - Dev mailing list archive at Nabble.com. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers From lonni.besancon at gmail.com Tue Jun 23 08:42:57 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Tue, 23 Jun 2015 05:42:57 -0700 (MST) Subject: [vtk-developers] Android: undefined reference to vtkRenderWindow::New() In-Reply-To: <29c436f64921d96ac967a3353496ee4c@mail.gmail.com> References: <1434554986629-5732418.post@n5.nabble.com> <1434561416248-5732424.post@n5.nabble.com> <1435046142805-5732490.post@n5.nabble.com> <29c436f64921d96ac967a3353496ee4c@mail.gmail.com> Message-ID: <1435063377816-5732499.post@n5.nabble.com> So the android build is not working for now right? Any version that I could use in the meantime? Or a temporary solution that you would advise? -- View this message in context: http://vtk.1045678.n5.nabble.com/Android-undefined-reference-to-vtkRenderWindow-New-tp5732418p5732499.html Sent from the VTK - Dev mailing list archive at Nabble.com. From karsten.tausche at student.hpi.de Tue Jun 23 09:41:56 2015 From: karsten.tausche at student.hpi.de (Karsten Tausche) Date: Tue, 23 Jun 2015 15:41:56 +0200 Subject: [vtk-developers] Building VTK with QT5.4 Windows 8 In-Reply-To: <1435061250629-5732496.post@n5.nabble.com> References: <1434546846947-5732403.post@n5.nabble.com> <55817942.30802@student.hpi.uni-potsdam.de> <1434549029258-5732410.post@n5.nabble.com> <55817B9F.3010109@student.hpi.uni-potsdam.de> <1434549883778-5732412.post@n5.nabble.com> <1434622420322-5732429.post@n5.nabble.com> <1435061250629-5732496.post@n5.nabble.com> Message-ID: <55896224.6010304@student.hpi.de> Hi, I'm using Qt5.4 (precompiled binaries and compiled from Git) on Windows 7 and 8, using Visual Studio 2013,2015 and never had this problem. It seems to me that something is wrong with your project setup. Did you link the VTK libraries to your application/library in CMake? Something like: target_link_libraries( ${TARGET} ${VTK_LIBRARIES}) Cheers, Karsten On 2015-06-23 14:07, Lonni Besan?on wrote: > Hi everyone, > > Still stuck there. Any more insights from someone who actually managed to > include Qt ? > > Thanks in advance > > > > -- > View this message in context: http://vtk.1045678.n5.nabble.com/Building-VTK-with-QT5-4-Windows-8-tp5732403p5732496.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > From chinander at gmail.com Tue Jun 23 09:47:59 2015 From: chinander at gmail.com (Mike Chinander) Date: Tue, 23 Jun 2015 08:47:59 -0500 Subject: [vtk-developers] Building VTK with QT5.4 Windows 8 In-Reply-To: <1435061250629-5732496.post@n5.nabble.com> References: <1434546846947-5732403.post@n5.nabble.com> <55817942.30802@student.hpi.uni-potsdam.de> <1434549029258-5732410.post@n5.nabble.com> <55817B9F.3010109@student.hpi.uni-potsdam.de> <1434549883778-5732412.post@n5.nabble.com> <1434622420322-5732429.post@n5.nabble.com> <1435061250629-5732496.post@n5.nabble.com> Message-ID: Can you show us your CMakeLists.txt file for your project? On Tue, Jun 23, 2015 at 7:07 AM, Lonni Besan?on wrote: > Hi everyone, > > Still stuck there. Any more insights from someone who actually managed to > include Qt ? > > Thanks in advance > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Building-VTK-with-QT5-4-Windows-8-tp5732403p5732496.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joaorobertojr88 at gmail.com Tue Jun 23 13:03:07 2015 From: joaorobertojr88 at gmail.com (joaoroberto88) Date: Tue, 23 Jun 2015 10:03:07 -0700 (MST) Subject: [vtk-developers] Possible bug for string output in vtkXMLPolyDataWriter Message-ID: <1435078987400-5732503.post@n5.nabble.com> Hi Devs, I'm using vtkXMLPolyDataWriter to record a poly data as string in a database. I noticed that is mandatory to set the output file name (which doesn't make sense for a string output). Below is my code: vtkSmartPointer writer = vtkSmartPointer::New(); writer->SetFileName("MeshPolyData"); writer->SetInputData(this->polyData); writer->WriteToOutputStringOn(); writer->Write(); return QString::fromStdString(writer->GetOutputString()); If I remove SetFileName method call, an exception is thrown. Could anyone confirm this? -- View this message in context: http://vtk.1045678.n5.nabble.com/Possible-bug-for-string-output-in-vtkXMLPolyDataWriter-tp5732503.html Sent from the VTK - Dev mailing list archive at Nabble.com. From andrew.amaclean at gmail.com Tue Jun 23 19:40:43 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 24 Jun 2015 09:40:43 +1000 Subject: [vtk-developers] For those using OpenGL2 in the VTK build. In-Reply-To: <93a9a0fe0e00b08a6a9682d837c2cf0f@mail.gmail.com> References: <93a9a0fe0e00b08a6a9682d837c2cf0f@mail.gmail.com> Message-ID: Hi Ken, That is a useful link. My Laptop has an Intel HD Graphics 3000 and NVIDIA GeForceGT 540M. So the Intel card only supports OpenGL 3.1 whilst the NVidia card supports OpenGL4.5 and Open CL1.1 It seems the NVidia card is supporting all the required extensions but not the Intel card. Regards Andrew On Tue, Jun 23, 2015 at 10:37 PM, Ken Martin wrote: > Morning Andrew, > > > > Yes, for laptops with multiple graphics options you probably want to go > with the dedicated graphics chip. Having said that, recent Intel chips > should work with VTK. This page provides more detail if you expand the 4th > /3rd generation sections, etc. > > > > http://www.intel.com/support/graphics/sb/CS-033757.htm > > > > Intel 2500, 4000, 4200, 4400, 4600, 5000, 5100, 5200 and later should all > support OpenGL 3.2. Intel 3000/2000/HD Graphics support 2.1 but not 3.2, > but I?m not sure if they provide the required extensions. > > > > 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. > > > > *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf > Of *Andrew Maclean > *Sent:* Tuesday, June 23, 2015 3:00 AM > *To:* VTK Developers; vtk > *Subject:* [vtk-developers] For those using OpenGL2 in the VTK build. > > > > Hi All > > > > On my laptop which has an Intel and NVidiia card, I just discovered that > my VTK programs were crashing with this message: > > > > "Warning: In \VTK\Rendering\OpenGL2\vtkOpenGLRenderWindow.cxx, line 426 > > vtkWin32OpenGLRenderWindow (0000000604268430): VTK is designed to work > with OpenGL version 3.2 but it appears it has been given a context that > does not support 3.2. VTK will run in a compatibility mode designed to work > with OpenGL 2.1 but some features may not work. > > > > ERROR: In\ VTK\Rendering\OpenGL2\vtkShaderProgram.cxx, line 366 > > vtkShaderProgram (0000000607E3F060): 1: > > > > ... > > ERROR: In \VTK\Rendering\OpenGL2\vtkShaderProgram.cxx, line 367 > > vtkShaderProgram (0000000607E3F060): ERROR: 0:20: '' : extension > 'GL_EXT_gpu_shader4' is not supported > > " > > > > To get rid of this error you must set the NVidia graphics processor as > default. > > > > To do this: > > Go to the NVIDIA Control Panel (right-click on the desktop), then: > 3D Settings-> Manage 3D settings > The Tab "Preferred graphics processor " , select > High performance NVidia processor > > > > Regards > > Andrew > > -- > > ___________________________________________ > Andrew J. P. Maclean > > ___________________________________________ > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Wed Jun 24 02:10:37 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Tue, 23 Jun 2015 23:10:37 -0700 (MST) Subject: [vtk-developers] Building VTK with QT5.4 Windows 8 In-Reply-To: References: <1434546846947-5732403.post@n5.nabble.com> <55817942.30802@student.hpi.uni-potsdam.de> <1434549029258-5732410.post@n5.nabble.com> <55817B9F.3010109@student.hpi.uni-potsdam.de> <1434549883778-5732412.post@n5.nabble.com> <1434622420322-5732429.post@n5.nabble.com> <1435061250629-5732496.post@n5.nabble.com> Message-ID: <1435126237747-5732513.post@n5.nabble.com> I haven't used CMake to add Qt functionalities to my project. I indeed already had a project set up in visual studio and I thought it was possible to manually add Qt. the reason for me doing so is that when I tried before to CMake one of the example of the wiki using Qt I faced CMake errors. Maybe then I should start by posting the CMake errors I had? Basically he problem was that my version of Qt was not recognized and it failed while trying to load Qt 4. If needed I can give you the full error message. Just let me know. -- View this message in context: http://vtk.1045678.n5.nabble.com/Building-VTK-with-QT5-4-Windows-8-tp5732403p5732513.html Sent from the VTK - Dev mailing list archive at Nabble.com. From lonni.besancon at gmail.com Wed Jun 24 06:58:15 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Wed, 24 Jun 2015 03:58:15 -0700 (MST) Subject: [vtk-developers] Building VTK with QT5.4 Windows 8 In-Reply-To: <1435126237747-5732513.post@n5.nabble.com> References: <1434546846947-5732403.post@n5.nabble.com> <55817942.30802@student.hpi.uni-potsdam.de> <1434549029258-5732410.post@n5.nabble.com> <55817B9F.3010109@student.hpi.uni-potsdam.de> <1434549883778-5732412.post@n5.nabble.com> <1434622420322-5732429.post@n5.nabble.com> <1435061250629-5732496.post@n5.nabble.com> <1435126237747-5732513.post@n5.nabble.com> Message-ID: <1435143495909-5732515.post@n5.nabble.com> To be more precise about my previous post (sorry I did not have the windows computer nearby when I answered), when trying to use the example from the Wiki: RenderWindowNoUiFile I get the error in /Cmake: CMake Error at C:/Program Files (x86)/CMake/share/cmake-3.2/Modules/FindQt4.cmake:1326 (message): Found unsuitable Qt version "" from NOTFOUND, this code requires Qt 4.x Call Stack (most recent call first): CMakeLists.txt:18 (find_package) / Which is completely logical since I don't have QT4 installed. Yet if I take a look at the CMakeList.txt it doesn't make sense as the CMakeList contains: / cmake_minimum_required(VERSION 2.8) if(POLICY CMP0020) cmake_policy(SET CMP0020 NEW) endif() PROJECT(RenderWindowNoUiFile) find_package(VTK REQUIRED) include(${VTK_USE_FILE}) if(${VTK_VERSION} VERSION_GREATER "6" AND VTK_QT_VERSION VERSION_GREATER "4") # Instruct CMake to run moc automatically when needed. set(CMAKE_AUTOMOC ON) find_package(Qt5Widgets REQUIRED QUIET) else() find_package(Qt4 REQUIRED) include(${QT_USE_FILE}) endif() include_directories(${CMAKE_CURRENT_SOURCE_DIR} ${CMAKE_CURRENT_BINARY_DIR}) file(GLOB UI_FILES *.ui) file(GLOB QT_WRAP *.h) file(GLOB CXX_FILES *.cxx) if(${VTK_VERSION} VERSION_GREATER "6" AND VTK_QT_VERSION VERSION_GREATER "4") qt5_wrap_ui(UISrcs ${UI_FILES} ) # CMAKE_AUTOMOC in ON so the MocHdrs will be automatically wrapped. add_executable(RenderWindowNoUiFile MACOSX_BUNDLE ${CXX_FILES} ${UISrcs} ${QT_WRAP}) qt5_use_modules(RenderWindowNoUiFile Core Gui) target_link_libraries(RenderWindowNoUiFile ${VTK_LIBRARIES}) else() QT4_WRAP_UI(UISrcs ${UI_FILES}) QT4_WRAP_CPP(MOCSrcs ${QT_WRAP}) add_executable(RenderWindowNoUiFile MACOSX_BUNDLE ${CXX_FILES} ${UISrcs} ${MOCSrcs}) if(VTK_LIBRARIES) if(${VTK_VERSION} VERSION_LESS "6") target_link_libraries(RenderWindowNoUiFile ${VTK_LIBRARIES} QVTK) else() target_link_libraries(RenderWindowNoUiFile ${VTK_LIBRARIES}) endif() else() target_link_libraries(RenderWindowNoUiFile vtkHybrid QVTK vtkViews ${QT_LIBRARIES}) endif() endif() / -- View this message in context: http://vtk.1045678.n5.nabble.com/Building-VTK-with-QT5-4-Windows-8-tp5732403p5732515.html Sent from the VTK - Dev mailing list archive at Nabble.com. From lonni.besancon at gmail.com Wed Jun 24 09:13:21 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Wed, 24 Jun 2015 06:13:21 -0700 (MST) Subject: [vtk-developers] Android: undefined reference to vtkRenderWindow::New() In-Reply-To: <1435063377816-5732499.post@n5.nabble.com> References: <1434554986629-5732418.post@n5.nabble.com> <1434561416248-5732424.post@n5.nabble.com> <1435046142805-5732490.post@n5.nabble.com> <29c436f64921d96ac967a3353496ee4c@mail.gmail.com> <1435063377816-5732499.post@n5.nabble.com> Message-ID: <1435151601552-5732518.post@n5.nabble.com> For more information about what I've tried and what I've done so far, here is my post on Stack Overflow: http://stackoverflow.com/questions/30896155/android-ndk-undefined-reference We have here a couple of questions: does the order of the include matters, why do I get an undefined reference to a function that is actually in the same file ... You may to take a look at it. Again, if you think that is a problem with VTK itself and not with what I'm doing, what do you advise me to do then? Have a good day, Lonni -- View this message in context: http://vtk.1045678.n5.nabble.com/Android-undefined-reference-to-vtkRenderWindow-New-tp5732418p5732518.html Sent from the VTK - Dev mailing list archive at Nabble.com. From marcus.hanwell at kitware.com Wed Jun 24 10:35:07 2015 From: marcus.hanwell at kitware.com (Marcus D. Hanwell) Date: Wed, 24 Jun 2015 10:35:07 -0400 Subject: [vtk-developers] [vtkusers] For those using OpenGL2 in the VTK build. In-Reply-To: References: <93a9a0fe0e00b08a6a9682d837c2cf0f@mail.gmail.com> Message-ID: Hi, I think there is some additional complication here too, my Linux Dell Sputnik2 laptop has HD Graphics 4000 embedded graphics. On Ubuntu 14.04 (the last LTS) it only claims to support GL 3.0 (and fails to do volume rendering on master at present, although this was working and we are looking into it). The Intel driver on Linux is built on the Mesa infrastructure, and it seems to lag the chips capabilities (and is also held back by what Ubuntu backport in the mesa version they ship I believe). It does support a number of extensions, and I am trying to keep up with testing as I want to see our rendering working on machines like this if possible. Marcus On Tue, Jun 23, 2015 at 7:40 PM, Andrew Maclean wrote: > Hi Ken, > That is a useful link. > > My Laptop has an Intel HD Graphics 3000 and NVIDIA GeForceGT 540M. So the > Intel card only supports OpenGL 3.1 whilst the NVidia card supports > OpenGL4.5 and Open CL1.1 > It seems the NVidia card is supporting all the required extensions but not > the Intel card. > > Regards > Andrew > > On Tue, Jun 23, 2015 at 10:37 PM, Ken Martin wrote: >> >> Morning Andrew, >> >> >> >> Yes, for laptops with multiple graphics options you probably want to go >> with the dedicated graphics chip. Having said that, recent Intel chips >> should work with VTK. This page provides more detail if you expand the >> 4th/3rd generation sections, etc. >> >> >> >> http://www.intel.com/support/graphics/sb/CS-033757.htm >> >> >> >> Intel 2500, 4000, 4200, 4400, 4600, 5000, 5100, 5200 and later should all >> support OpenGL 3.2. Intel 3000/2000/HD Graphics support 2.1 but not 3.2, >> but I?m not sure if they provide the required extensions. >> >> >> >> 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. >> >> >> >> From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of >> Andrew Maclean >> Sent: Tuesday, June 23, 2015 3:00 AM >> To: VTK Developers; vtk >> Subject: [vtk-developers] For those using OpenGL2 in the VTK build. >> >> >> >> Hi All >> >> >> >> On my laptop which has an Intel and NVidiia card, I just discovered that >> my VTK programs were crashing with this message: >> >> >> >> "Warning: In \VTK\Rendering\OpenGL2\vtkOpenGLRenderWindow.cxx, line 426 >> >> vtkWin32OpenGLRenderWindow (0000000604268430): VTK is designed to work >> with OpenGL version 3.2 but it appears it has been given a context that does >> not support 3.2. VTK will run in a compatibility mode designed to work with >> OpenGL 2.1 but some features may not work. >> >> >> >> ERROR: In\ VTK\Rendering\OpenGL2\vtkShaderProgram.cxx, line 366 >> >> vtkShaderProgram (0000000607E3F060): 1: >> >> >> >> ... >> >> ERROR: In \VTK\Rendering\OpenGL2\vtkShaderProgram.cxx, line 367 >> >> vtkShaderProgram (0000000607E3F060): ERROR: 0:20: '' : extension >> 'GL_EXT_gpu_shader4' is not supported >> >> " >> >> >> >> To get rid of this error you must set the NVidia graphics processor as >> default. >> >> >> >> To do this: >> >> Go to the NVIDIA Control Panel (right-click on the desktop), then: >> 3D Settings-> Manage 3D settings >> The Tab "Preferred graphics processor " , select >> High performance NVidia processor >> >> >> >> Regards >> >> Andrew >> >> -- >> >> ___________________________________________ >> 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 > > 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 > From majcjc at gmail.com Wed Jun 24 10:43:30 2015 From: majcjc at gmail.com (Lin M) Date: Wed, 24 Jun 2015 10:43:30 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> Message-ID: Hi Dr. Thompson, I'm writing the knot insertion method InsertKnot() and I hope it can be used to handle both 1-d, 2-d and 3-d cases. 1. One question is that when converting a nurbs curve to a bezier curve, eaca segment of a nurbs curve will correspond to a new bezier curve. So we need to repeatedly retrieve a subset of the control points and the knot vector from the original nurbs curve. To make the InserKnot() method more generally. I define the API as void InsertKnot( vtkPoints* pointsOut, double tNew, int dim, vtkPoints* pointsIn, int* knotsLen, double* knotsArr) // pointsOut stores the new control points // tNew is the new knot we want to insert // dim is the dimension where the new knot is // pointsIn is the old control points (which is probably a subset of the original nurbs control points) // knotsLen stores the number of entries of the knots vector in each dimension (I'll assume it is always a 1*3 int array) // knotsArr stores the knot vector for all dimensions Do you think this API is proper? 2. The second question is that, as described in the first question, a p-degree nurbs curve with a given knot vector actually will generate a series of bezier curve. Each of the them corresponds to a segment of the original nurbs curve. How can I find the subset of the control points and knot vector for a segment? Best, Lin On Mon, Jun 22, 2015 at 6:54 PM, David Thompson wrote: > Hi Lin, > > > 1. The definition of knot vector seems to be a little different from the > NURBS book. In the NURBS book, a knot vector is defined as U = > {a,...,a,u_{p+1},...,u_{m-p-1},b,...,b} where a and b are repeated p+1 > times (p is the degree of NURBS curve). And since NURBS cruve is defined > as C(u) = sum_{i,n}(N_{i,p}(u)*P_{i}), the endpoints seems to be > interpolated as well. > > NURBS do not require any knot vector entries to be repeated. Many examples > in the NURBS book *happen* to have repeated entries, but it is not a > requirement. > > > ... > > 2. The previous section of the wiki page writes "The number of knots is > always equal to the number of control points plus curve degree plus one > (i.e. number of control points plus curve order)." Should it be degree + N > + 1 = K ? > > From the wikipedia entry: "Some modelers that use older algorithms for > NURBS evaluation require two extra knot values for a total of (degree+N+1) > knots.[7]" You can use whichever you like. I would advise sticking with > the NURBS book because it has many examples worked out in detail. (The > NURBS book appears to use the degree + N + 1 = K formulation.) > > > 3. I think the inference is only for a single patch. If there are > several patches in the vtkStructuredGrid, we can not get the number of > control points for a certain patch by vtkStructuredGrid->GetDimension() > unless we know the number of patches and the number of control points are > the same for all these patches. > > > Nope, you can use GetDimension() to discover the number, N, of control > points for all patches. That is related to the degree by the number of knot > vector entries for all patches. We have not specified how the knot vector > would be stored. If stored as an array in vtkFieldData, then we would > also have to store the number entries along each axis (the equivalent > information as GetDimension() returns for the control points). Or we could > store the degree along each axis and use that to determine the size of the > knot vector along each axis... whichever you prefer. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Wed Jun 24 16:38:18 2015 From: majcjc at gmail.com (Lin M) Date: Wed, 24 Jun 2015 16:38:18 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> Message-ID: Hi Dr. Thompson, I implemented the InserKnot() method. Currently the API is like: void InsertKnot( vtkDataArray* pointsOut, int* knotsLenNew, double* knotsArrNew, int* ctrlPtsNumNew, double tNew, int insertDim, vtkDataArray* pointsIn, int* knotsLen, double* knotsArr, int* ctrlPtsNum); I have submitted the code to gitlab ( https://gitlab.kitware.com/splines/vtk/merge_requests/4). Please take a look at it. Thanks. Best, Lin On Wed, Jun 24, 2015 at 10:43 AM, Lin M wrote: > Hi Dr. Thompson, > > I'm writing the knot insertion method InsertKnot() and I hope it can be > used to handle both 1-d, 2-d and 3-d cases. > > 1. One question is that when converting a nurbs curve to a bezier curve, > eaca segment of a nurbs curve will correspond to a new bezier curve. So we > need to repeatedly retrieve a subset of the control points and the knot > vector from the original nurbs curve. To make the InserKnot() method more > generally. I define the API as > > void InsertKnot( > vtkPoints* pointsOut, > double tNew, int dim, > vtkPoints* pointsIn, int* knotsLen, double* knotsArr) > > // pointsOut stores the new control points > // tNew is the new knot we want to insert > // dim is the dimension where the new knot is > // pointsIn is the old control points (which is probably a subset of the > original nurbs control points) > // knotsLen stores the number of entries of the knots vector in each > dimension (I'll assume it is always a 1*3 int array) > // knotsArr stores the knot vector for all dimensions > > Do you think this API is proper? > > 2. The second question is that, as described in the first question, a > p-degree nurbs curve with a given knot vector actually will generate a > series of bezier curve. Each of the them corresponds to a segment of the > original nurbs curve. How can I find the subset of the control points and > knot vector for a segment? > > Best, > Lin > > On Mon, Jun 22, 2015 at 6:54 PM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hi Lin, >> >> > 1. The definition of knot vector seems to be a little different from >> the NURBS book. In the NURBS book, a knot vector is defined as U = >> {a,...,a,u_{p+1},...,u_{m-p-1},b,...,b} where a and b are repeated p+1 >> times (p is the degree of NURBS curve). And since NURBS cruve is defined >> as C(u) = sum_{i,n}(N_{i,p}(u)*P_{i}), the endpoints seems to be >> interpolated as well. >> >> NURBS do not require any knot vector entries to be repeated. Many >> examples in the NURBS book *happen* to have repeated entries, but it is not >> a requirement. >> >> > ... >> > 2. The previous section of the wiki page writes "The number of knots is >> always equal to the number of control points plus curve degree plus one >> (i.e. number of control points plus curve order)." Should it be degree + N >> + 1 = K ? >> >> From the wikipedia entry: "Some modelers that use older algorithms for >> NURBS evaluation require two extra knot values for a total of (degree+N+1) >> knots.[7]" You can use whichever you like. I would advise sticking with >> the NURBS book because it has many examples worked out in detail. (The >> NURBS book appears to use the degree + N + 1 = K formulation.) >> >> > 3. I think the inference is only for a single patch. If there are >> several patches in the vtkStructuredGrid, we can not get the number of >> control points for a certain patch by vtkStructuredGrid->GetDimension() >> unless we know the number of patches and the number of control points are >> the same for all these patches. >> >> >> Nope, you can use GetDimension() to discover the number, N, of control >> points for all patches. That is related to the degree by the number of knot >> vector entries for all patches. We have not specified how the knot vector >> would be stored. If stored as an array in vtkFieldData, then we would >> also have to store the number entries along each axis (the equivalent >> information as GetDimension() returns for the control points). Or we could >> store the degree along each axis and use that to determine the size of the >> knot vector along each axis... whichever you prefer. >> >> David > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Thu Jun 25 19:04:52 2015 From: majcjc at gmail.com (Lin M) Date: Thu, 25 Jun 2015 19:04:52 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> Message-ID: Hi Dr.Thompson, I added the method to insert a knot multiple times based on the algorithm in the NURBS book. It supports knot insertion for 3-d patches if it works correctly. I tested it in 1-d case and it works well. Best, Lin On Wed, Jun 24, 2015 at 4:38 PM, Lin M wrote: > Hi Dr. Thompson, > > I implemented the InserKnot() method. Currently the API is like: > > void InsertKnot( > vtkDataArray* pointsOut, int* knotsLenNew, double* knotsArrNew, int* > ctrlPtsNumNew, > double tNew, int insertDim, > vtkDataArray* pointsIn, int* knotsLen, double* knotsArr, int* > ctrlPtsNum); > > I have submitted the code to gitlab ( > https://gitlab.kitware.com/splines/vtk/merge_requests/4). Please take a > look at it. Thanks. > > Best, > Lin > > On Wed, Jun 24, 2015 at 10:43 AM, Lin M wrote: > >> Hi Dr. Thompson, >> >> I'm writing the knot insertion method InsertKnot() and I hope it can be >> used to handle both 1-d, 2-d and 3-d cases. >> >> 1. One question is that when converting a nurbs curve to a bezier curve, >> eaca segment of a nurbs curve will correspond to a new bezier curve. So we >> need to repeatedly retrieve a subset of the control points and the knot >> vector from the original nurbs curve. To make the InserKnot() method more >> generally. I define the API as >> >> void InsertKnot( >> vtkPoints* pointsOut, >> double tNew, int dim, >> vtkPoints* pointsIn, int* knotsLen, double* knotsArr) >> >> // pointsOut stores the new control points >> // tNew is the new knot we want to insert >> // dim is the dimension where the new knot is >> // pointsIn is the old control points (which is probably a subset of the >> original nurbs control points) >> // knotsLen stores the number of entries of the knots vector in each >> dimension (I'll assume it is always a 1*3 int array) >> // knotsArr stores the knot vector for all dimensions >> >> Do you think this API is proper? >> >> 2. The second question is that, as described in the first question, a >> p-degree nurbs curve with a given knot vector actually will generate a >> series of bezier curve. Each of the them corresponds to a segment of the >> original nurbs curve. How can I find the subset of the control points and >> knot vector for a segment? >> >> Best, >> Lin >> >> On Mon, Jun 22, 2015 at 6:54 PM, David Thompson < >> david.thompson at kitware.com> wrote: >> >>> Hi Lin, >>> >>> > 1. The definition of knot vector seems to be a little different from >>> the NURBS book. In the NURBS book, a knot vector is defined as U = >>> {a,...,a,u_{p+1},...,u_{m-p-1},b,...,b} where a and b are repeated p+1 >>> times (p is the degree of NURBS curve). And since NURBS cruve is defined >>> as C(u) = sum_{i,n}(N_{i,p}(u)*P_{i}), the endpoints seems to be >>> interpolated as well. >>> >>> NURBS do not require any knot vector entries to be repeated. Many >>> examples in the NURBS book *happen* to have repeated entries, but it is not >>> a requirement. >>> >>> > ... >>> > 2. The previous section of the wiki page writes "The number of knots >>> is always equal to the number of control points plus curve degree plus one >>> (i.e. number of control points plus curve order)." Should it be degree + N >>> + 1 = K ? >>> >>> From the wikipedia entry: "Some modelers that use older algorithms for >>> NURBS evaluation require two extra knot values for a total of (degree+N+1) >>> knots.[7]" You can use whichever you like. I would advise sticking with >>> the NURBS book because it has many examples worked out in detail. (The >>> NURBS book appears to use the degree + N + 1 = K formulation.) >>> >>> > 3. I think the inference is only for a single patch. If there are >>> several patches in the vtkStructuredGrid, we can not get the number of >>> control points for a certain patch by vtkStructuredGrid->GetDimension() >>> unless we know the number of patches and the number of control points are >>> the same for all these patches. >>> >>> >>> Nope, you can use GetDimension() to discover the number, N, of control >>> points for all patches. That is related to the degree by the number of knot >>> vector entries for all patches. We have not specified how the knot vector >>> would be stored. If stored as an array in vtkFieldData, then we would >>> also have to store the number entries along each axis (the equivalent >>> information as GetDimension() returns for the control points). Or we could >>> store the degree along each axis and use that to determine the size of the >>> knot vector along each axis... whichever you prefer. >>> >>> David >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Thu Jun 25 19:07:13 2015 From: david.thompson at kitware.com (David Thompson) Date: Thu, 25 Jun 2015 19:07:13 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> Message-ID: Hi Lin, That sounds great. While I take a look at it, perhaps you could work on generating triangle strips for surfaces? Then we will be ready to render 2D versions as part of the test for knot insertion. Do you need more information on triangle strips in VTK or was my last message enough? Thanks, David > On Jun 25, 2015, at 7:04 PM, Lin M wrote: > > Hi Dr.Thompson, > > I added the method to insert a knot multiple times based on the algorithm in the NURBS book. It supports knot insertion for 3-d patches if it works correctly. I tested it in 1-d case and it works well. > > Best, > Lin > > On Wed, Jun 24, 2015 at 4:38 PM, Lin M wrote: > Hi Dr. Thompson, > > I implemented the InserKnot() method. Currently the API is like: > > void InsertKnot( > vtkDataArray* pointsOut, int* knotsLenNew, double* knotsArrNew, int* ctrlPtsNumNew, > double tNew, int insertDim, > vtkDataArray* pointsIn, int* knotsLen, double* knotsArr, int* ctrlPtsNum); > > I have submitted the code to gitlab (https://gitlab.kitware.com/splines/vtk/merge_requests/4). Please take a look at it. Thanks. > > Best, > Lin > > On Wed, Jun 24, 2015 at 10:43 AM, Lin M wrote: > Hi Dr. Thompson, > > I'm writing the knot insertion method InsertKnot() and I hope it can be used to handle both 1-d, 2-d and 3-d cases. > > 1. One question is that when converting a nurbs curve to a bezier curve, eaca segment of a nurbs curve will correspond to a new bezier curve. So we need to repeatedly retrieve a subset of the control points and the knot vector from the original nurbs curve. To make the InserKnot() method more generally. I define the API as > > void InsertKnot( > vtkPoints* pointsOut, > double tNew, int dim, > vtkPoints* pointsIn, int* knotsLen, double* knotsArr) > > // pointsOut stores the new control points > // tNew is the new knot we want to insert > // dim is the dimension where the new knot is > // pointsIn is the old control points (which is probably a subset of the original nurbs control points) > // knotsLen stores the number of entries of the knots vector in each dimension (I'll assume it is always a 1*3 int array) > // knotsArr stores the knot vector for all dimensions > > Do you think this API is proper? > > 2. The second question is that, as described in the first question, a p-degree nurbs curve with a given knot vector actually will generate a series of bezier curve. Each of the them corresponds to a segment of the original nurbs curve. How can I find the subset of the control points and knot vector for a segment? > > Best, > Lin > > On Mon, Jun 22, 2015 at 6:54 PM, David Thompson wrote: > Hi Lin, > > > 1. The definition of knot vector seems to be a little different from the NURBS book. In the NURBS book, a knot vector is defined as U = {a,...,a,u_{p+1},...,u_{m-p-1},b,...,b} where a and b are repeated p+1 times (p is the degree of NURBS curve). And since NURBS cruve is defined as C(u) = sum_{i,n}(N_{i,p}(u)*P_{i}), the endpoints seems to be interpolated as well. > > NURBS do not require any knot vector entries to be repeated. Many examples in the NURBS book *happen* to have repeated entries, but it is not a requirement. > > > ... > > 2. The previous section of the wiki page writes "The number of knots is always equal to the number of control points plus curve degree plus one (i.e. number of control points plus curve order)." Should it be degree + N + 1 = K ? > > From the wikipedia entry: "Some modelers that use older algorithms for NURBS evaluation require two extra knot values for a total of (degree+N+1) knots.[7]" You can use whichever you like. I would advise sticking with the NURBS book because it has many examples worked out in detail. (The NURBS book appears to use the degree + N + 1 = K formulation.) > > > 3. I think the inference is only for a single patch. If there are several patches in the vtkStructuredGrid, we can not get the number of control points for a certain patch by vtkStructuredGrid->GetDimension() unless we know the number of patches and the number of control points are the same for all these patches. > > > Nope, you can use GetDimension() to discover the number, N, of control points for all patches. That is related to the degree by the number of knot vector entries for all patches. We have not specified how the knot vector would be stored. If stored as an array in vtkFieldData, then we would also have to store the number entries along each axis (the equivalent information as GetDimension() returns for the control points). Or we could store the degree along each axis and use that to determine the size of the knot vector along each axis... whichever you prefer. > > David > > > From majcjc at gmail.com Thu Jun 25 19:29:02 2015 From: majcjc at gmail.com (Lin M) Date: Thu, 25 Jun 2015 19:29:02 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> Message-ID: Your last message is quite informative. I think it is mainly to implement a method in vtkPatchInterpolation which takes in a bezier patch, number of samples and return a vtkUnstructuredGrid? Best, Lin On Thu, Jun 25, 2015 at 7:07 PM, David Thompson wrote: > Hi Lin, > > That sounds great. While I take a look at it, perhaps you could work on > generating triangle strips for surfaces? Then we will be ready to render 2D > versions as part of the test for knot insertion. > > Do you need more information on triangle strips in VTK or was my last > message enough? > > Thanks, > David > > > On Jun 25, 2015, at 7:04 PM, Lin M wrote: > > > > Hi Dr.Thompson, > > > > I added the method to insert a knot multiple times based on the > algorithm in the NURBS book. It supports knot insertion for 3-d patches if > it works correctly. I tested it in 1-d case and it works well. > > > > Best, > > Lin > > > > On Wed, Jun 24, 2015 at 4:38 PM, Lin M wrote: > > Hi Dr. Thompson, > > > > I implemented the InserKnot() method. Currently the API is like: > > > > void InsertKnot( > > vtkDataArray* pointsOut, int* knotsLenNew, double* knotsArrNew, int* > ctrlPtsNumNew, > > double tNew, int insertDim, > > vtkDataArray* pointsIn, int* knotsLen, double* knotsArr, int* > ctrlPtsNum); > > > > I have submitted the code to gitlab ( > https://gitlab.kitware.com/splines/vtk/merge_requests/4). Please take a > look at it. Thanks. > > > > Best, > > Lin > > > > On Wed, Jun 24, 2015 at 10:43 AM, Lin M wrote: > > Hi Dr. Thompson, > > > > I'm writing the knot insertion method InsertKnot() and I hope it can be > used to handle both 1-d, 2-d and 3-d cases. > > > > 1. One question is that when converting a nurbs curve to a bezier curve, > eaca segment of a nurbs curve will correspond to a new bezier curve. So we > need to repeatedly retrieve a subset of the control points and the knot > vector from the original nurbs curve. To make the InserKnot() method more > generally. I define the API as > > > > void InsertKnot( > > vtkPoints* pointsOut, > > double tNew, int dim, > > vtkPoints* pointsIn, int* knotsLen, double* knotsArr) > > > > // pointsOut stores the new control points > > // tNew is the new knot we want to insert > > // dim is the dimension where the new knot is > > // pointsIn is the old control points (which is probably a subset of the > original nurbs control points) > > // knotsLen stores the number of entries of the knots vector in each > dimension (I'll assume it is always a 1*3 int array) > > // knotsArr stores the knot vector for all dimensions > > > > Do you think this API is proper? > > > > 2. The second question is that, as described in the first question, a > p-degree nurbs curve with a given knot vector actually will generate a > series of bezier curve. Each of the them corresponds to a segment of the > original nurbs curve. How can I find the subset of the control points and > knot vector for a segment? > > > > Best, > > Lin > > > > On Mon, Jun 22, 2015 at 6:54 PM, David Thompson < > david.thompson at kitware.com> wrote: > > Hi Lin, > > > > > 1. The definition of knot vector seems to be a little different from > the NURBS book. In the NURBS book, a knot vector is defined as U = > {a,...,a,u_{p+1},...,u_{m-p-1},b,...,b} where a and b are repeated p+1 > times (p is the degree of NURBS curve). And since NURBS cruve is defined > as C(u) = sum_{i,n}(N_{i,p}(u)*P_{i}), the endpoints seems to be > interpolated as well. > > > > NURBS do not require any knot vector entries to be repeated. Many > examples in the NURBS book *happen* to have repeated entries, but it is not > a requirement. > > > > > ... > > > 2. The previous section of the wiki page writes "The number of knots > is always equal to the number of control points plus curve degree plus one > (i.e. number of control points plus curve order)." Should it be degree + N > + 1 = K ? > > > > From the wikipedia entry: "Some modelers that use older algorithms for > NURBS evaluation require two extra knot values for a total of (degree+N+1) > knots.[7]" You can use whichever you like. I would advise sticking with > the NURBS book because it has many examples worked out in detail. (The > NURBS book appears to use the degree + N + 1 = K formulation.) > > > > > 3. I think the inference is only for a single patch. If there are > several patches in the vtkStructuredGrid, we can not get the number of > control points for a certain patch by vtkStructuredGrid->GetDimension() > unless we know the number of patches and the number of control points are > the same for all these patches. > > > > > > Nope, you can use GetDimension() to discover the number, N, of control > points for all patches. That is related to the degree by the number of knot > vector entries for all patches. We have not specified how the knot vector > would be stored. If stored as an array in vtkFieldData, then we would > also have to store the number entries along each axis (the equivalent > information as GetDimension() returns for the control points). Or we could > store the degree along each axis and use that to determine the size of the > knot vector along each axis... whichever you prefer. > > > > David > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Thu Jun 25 19:32:07 2015 From: david.thompson at kitware.com (David Thompson) Date: Thu, 25 Jun 2015 19:32:07 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> Message-ID: Hi Lin, > Your last message is quite informative. I think it is mainly to implement a method in vtkPatchInterpolation which takes in a bezier patch, number of samples and ... That would be a great start. Eventually it would be nice to have curvature-adapted surfaces, but just accepting a number of samples along each axis will be something we need in any event. > ... return a vtkUnstructuredGrid? I would accept a vtkUnstructuredGrid pointer as input and insert into it so that it is easy to create one grid with triangles from multiple patches. David From majcjc at gmail.com Fri Jun 26 01:06:58 2015 From: majcjc at gmail.com (Lin M) Date: Fri, 26 Jun 2015 01:06:58 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> Message-ID: Hi Dr. Thompson, I have added a method in vtkPatchInterpolation to generate triangle strips for surfaces. I tested a cylindrical surface patch from the NURBS book and I think it's correct. Best, Lin On Thu, Jun 25, 2015 at 7:32 PM, David Thompson wrote: > Hi Lin, > > > Your last message is quite informative. I think it is mainly to > implement a method in vtkPatchInterpolation which takes in a bezier patch, > number of samples and ... > > > That would be a great start. Eventually it would be nice to have > curvature-adapted surfaces, but just accepting a number of samples along > each axis will be something we need in any event. > > > ... return a vtkUnstructuredGrid? > > I would accept a vtkUnstructuredGrid pointer as input and insert into it > so that it is easy to create one grid with triangles from multiple patches. > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Fri Jun 26 16:08:27 2015 From: majcjc at gmail.com (Lin M) Date: Fri, 26 Jun 2015 16:08:27 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> Message-ID: Hi Dr. Thompson, I have a question about the knot vector and the knot insertion. Currently the method for knot insertion is based on the algorithm from the NURBS book where it always assumes that the first value and last value in the knot vector repeat p+1 times. This makes the endpoints of the curve always coincide with the first and last control points. As you mentioned before, the knot vector may not always be like this and in such cases the algorithm will fail. Is there any method to deal with this? Best, Lin On Fri, Jun 26, 2015 at 1:06 AM, Lin M wrote: > Hi Dr. Thompson, > > I have added a method in vtkPatchInterpolation to generate triangle > strips for surfaces. I tested a cylindrical surface patch from the NURBS > book and I think it's correct. > > Best, > Lin > > On Thu, Jun 25, 2015 at 7:32 PM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hi Lin, >> >> > Your last message is quite informative. I think it is mainly to >> implement a method in vtkPatchInterpolation which takes in a bezier patch, >> number of samples and ... >> >> >> That would be a great start. Eventually it would be nice to have >> curvature-adapted surfaces, but just accepting a number of samples along >> each axis will be something we need in any event. >> >> > ... return a vtkUnstructuredGrid? >> >> I would accept a vtkUnstructuredGrid pointer as input and insert into it >> so that it is easy to create one grid with triangles from multiple patches. >> >> David > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Fri Jun 26 16:41:58 2015 From: david.thompson at kitware.com (David Thompson) Date: Fri, 26 Jun 2015 16:41:58 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> Message-ID: <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> Hi Lin, Knot insertion should not fail when a knot is not repeated. Instead, by inserting the same knot value multiple times we can convert the control polygon to a series of B?zier patches. If you start with a knot vector of {0,1,2,3} for a degree 2 curve, then you can insert knots until the knot vector is {0,0,0,1,1,1,2,3}. The resulting control points for the knot interval [0,1] are a valid B?zier control polygon. You can do the same for other knot values to extract B?zier patches for the intervals [1,2] and [2,3]. David > On Jun 26, 2015, at 4:08 PM, Lin M wrote: > > Hi Dr. Thompson, > > I have a question about the knot vector and the knot insertion. > Currently the method for knot insertion is based on the algorithm from the NURBS book where it always assumes that the first value and last value in the knot vector repeat p+1 times. This makes the endpoints of the curve always coincide with the first and last control points. As you mentioned before, the knot vector may not always be like this and in such cases the algorithm will fail. Is there any method to deal with this? > > Best, > Lin > > On Fri, Jun 26, 2015 at 1:06 AM, Lin M wrote: > Hi Dr. Thompson, > > I have added a method in vtkPatchInterpolation to generate triangle strips for surfaces. I tested a cylindrical surface patch from the NURBS book and I think it's correct. > > Best, > Lin > > On Thu, Jun 25, 2015 at 7:32 PM, David Thompson wrote: > Hi Lin, > > > Your last message is quite informative. I think it is mainly to implement a method in vtkPatchInterpolation which takes in a bezier patch, number of samples and ... > > > That would be a great start. Eventually it would be nice to have curvature-adapted surfaces, but just accepting a number of samples along each axis will be something we need in any event. > > > ... return a vtkUnstructuredGrid? > > I would accept a vtkUnstructuredGrid pointer as input and insert into it so that it is easy to create one grid with triangles from multiple patches. > > David > > From majcjc at gmail.com Fri Jun 26 18:09:09 2015 From: majcjc at gmail.com (Lin M) Date: Fri, 26 Jun 2015 18:09:09 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> Message-ID: What confuses me a lot is the different definition of the knot vector. As in the wiki page "Some modelers that use older algorithms for NURBS evaluation require two extra knot values for a total of (degree+N+1) knots". But how can I get 3 2-degree B-spline basis functions N_{0,2}, N_{1,2} and N_{2,2} from the knot vector {0,1,2,3}? From the knot vector {0,1,2,3}, we can get at most 3 zero-degree B-spline basis functions N_{0,0}, N_{1,0} and N_{2,0} and then we can only get one 2-degree basis function N_{0,2}. The reason why I said the algorithm from the NURBS book would fail is because it use a loop variable start from kSpan - sMult (kSpan is the id of the knot span where the insert knot is, and sMult is the current multiplicity of the insert knot). For the knot vector {0,1,2,3}, if we insert a new knot 0, the kSpan = 0, sMult = 1 and kSpan - sMult = -1 which is not correct. On Fri, Jun 26, 2015 at 4:41 PM, David Thompson wrote: > Hi Lin, > > Knot insertion should not fail when a knot is not repeated. Instead, by > inserting the same knot value multiple times we can convert the control > polygon to a series of B?zier patches. If you start with a knot vector of > {0,1,2,3} for a degree 2 curve, then you can insert knots until the knot > vector is {0,0,0,1,1,1,2,3}. The resulting control points for the knot > interval [0,1] are a valid B?zier control polygon. You can do the same for > other knot values to extract B?zier patches for the intervals [1,2] and > [2,3]. > > David > > > > On Jun 26, 2015, at 4:08 PM, Lin M wrote: > > > > Hi Dr. Thompson, > > > > I have a question about the knot vector and the knot insertion. > > Currently the method for knot insertion is based on the algorithm from > the NURBS book where it always assumes that the first value and last value > in the knot vector repeat p+1 times. This makes the endpoints of the curve > always coincide with the first and last control points. As you mentioned > before, the knot vector may not always be like this and in such cases the > algorithm will fail. Is there any method to deal with this? > > > > Best, > > Lin > > > > On Fri, Jun 26, 2015 at 1:06 AM, Lin M wrote: > > Hi Dr. Thompson, > > > > I have added a method in vtkPatchInterpolation to generate triangle > strips for surfaces. I tested a cylindrical surface patch from the NURBS > book and I think it's correct. > > > > Best, > > Lin > > > > On Thu, Jun 25, 2015 at 7:32 PM, David Thompson < > david.thompson at kitware.com> wrote: > > Hi Lin, > > > > > Your last message is quite informative. I think it is mainly to > implement a method in vtkPatchInterpolation which takes in a bezier patch, > number of samples and ... > > > > > > That would be a great start. Eventually it would be nice to have > curvature-adapted surfaces, but just accepting a number of samples along > each axis will be something we need in any event. > > > > > ... return a vtkUnstructuredGrid? > > > > I would accept a vtkUnstructuredGrid pointer as input and insert into it > so that it is easy to create one grid with triangles from multiple patches. > > > > David > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lonni.besancon at gmail.com Mon Jun 29 06:59:07 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Mon, 29 Jun 2015 03:59:07 -0700 (MST) Subject: [vtk-developers] Android: undefined reference to vtkRenderWindow::New() In-Reply-To: <29c436f64921d96ac967a3353496ee4c@mail.gmail.com> References: <1434554986629-5732418.post@n5.nabble.com> <1434561416248-5732424.post@n5.nabble.com> <1435046142805-5732490.post@n5.nabble.com> <29c436f64921d96ac967a3353496ee4c@mail.gmail.com> Message-ID: <1435575547017-5732575.post@n5.nabble.com> Ken Martin, any news on this issue then? -- View this message in context: http://vtk.1045678.n5.nabble.com/Android-undefined-reference-to-vtkRenderWindow-New-tp5732418p5732575.html Sent from the VTK - Dev mailing list archive at Nabble.com. From dave.demarle at kitware.com Mon Jun 29 10:41:59 2015 From: dave.demarle at kitware.com (David E DeMarle) Date: Mon, 29 Jun 2015 10:41:59 -0400 Subject: [vtk-developers] vtk 6.3 and vtk 7.0 Message-ID: Hey vtkers, We are hoping to do a vtk 6.3 release in the next couple of weeks and then immediately follow that up with a 7.0 release. We'd are putting out a 6.3 out in order to: * deprecate the existing zero copy array API in preparation for a significant refactoring that will come in 7.0. The refactor will make zero copy arrays both simpler to use and perform better. * package up all of the progress that has been made in the master branch's OpenGL2 surface and volume rendering. The vtkpython binaries will switch over to using the OpenGL2 back end this release. Please let us know if you have any feedback, critical bugs especially, and developers let us know if there is any work you have in a partially finished state that we should be sure to get into 6.3. If all goes well we'll have a release candidate for 6.3 next week. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 -------------- next part -------------- An HTML attachment was scrubbed... URL: From majcjc at gmail.com Mon Jun 29 15:22:01 2015 From: majcjc at gmail.com (Lin M) Date: Mon, 29 Jun 2015 15:22:01 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> Message-ID: Hi Dr. Thompson, I just learnt the polar form about b-spline ( http://web.archive.org/web/20120227050519/http://tom.cs.byu.edu/~455/bs.pdf) which gives a more intuitive explanation for knot insertion. As the example you mentioned before, given a knot vector {0,1,2,3} for a 2-degree curve, we will have 3 control points P_0, P_1, P_2. They can be represented in polar form as P(0,1), P(1,2) and P(2,3). The control points for the bezier segments for this curve is Segment 1: P(0,0), P(0,1), P(1,1) Segment 2: P(1,1), P(1,2), P(2,2) Segment 3: P(2,2), P(2,3), P(3,3) What we need to generate is P(0,0), P(1,1), P(2,2) and P(3,3). From the affine combination property, we can get: P(1,1) by interpolating P(0,1) and P(1,2) P(2,2) by interpolating P(1,2) and P(2,3) for P(0,0) and P(3,3), it seems not that straightforward. It's possible to generate P(0,2) first by interpolation P(1,2) and P(2,3) and generate P(0,0) by interpolation P(0,1) and P(0,2). For P(3,3), first generate P(1,3) by interpolation P(0,1) and P(1,2) and then generate P(3,3) by interpolation P(1,3) and P(2,3). Best, Lin On Fri, Jun 26, 2015 at 6:09 PM, Lin M wrote: > What confuses me a lot is the different definition of the knot vector. As > in the wiki page "Some modelers that use older algorithms for NURBS > evaluation require two extra knot values for a total of (degree+N+1) > knots". But how can I get 3 2-degree B-spline basis functions N_{0,2}, > N_{1,2} and N_{2,2} from the knot vector {0,1,2,3}? From the knot vector > {0,1,2,3}, we can get at most 3 zero-degree B-spline basis functions > N_{0,0}, N_{1,0} and N_{2,0} and then we can only get one 2-degree basis > function N_{0,2}. > > The reason why I said the algorithm from the NURBS book would fail is > because it use a loop variable start from kSpan - sMult (kSpan is the id of > the knot span where the insert knot is, and sMult is the current > multiplicity of the insert knot). For the knot vector {0,1,2,3}, if we > insert a new knot 0, the kSpan = 0, sMult = 1 and kSpan - sMult = -1 which > is not correct. > > On Fri, Jun 26, 2015 at 4:41 PM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hi Lin, >> >> Knot insertion should not fail when a knot is not repeated. Instead, by >> inserting the same knot value multiple times we can convert the control >> polygon to a series of B?zier patches. If you start with a knot vector of >> {0,1,2,3} for a degree 2 curve, then you can insert knots until the knot >> vector is {0,0,0,1,1,1,2,3}. The resulting control points for the knot >> interval [0,1] are a valid B?zier control polygon. You can do the same for >> other knot values to extract B?zier patches for the intervals [1,2] and >> [2,3]. >> >> David >> >> >> > On Jun 26, 2015, at 4:08 PM, Lin M wrote: >> > >> > Hi Dr. Thompson, >> > >> > I have a question about the knot vector and the knot insertion. >> > Currently the method for knot insertion is based on the algorithm from >> the NURBS book where it always assumes that the first value and last value >> in the knot vector repeat p+1 times. This makes the endpoints of the curve >> always coincide with the first and last control points. As you mentioned >> before, the knot vector may not always be like this and in such cases the >> algorithm will fail. Is there any method to deal with this? >> > >> > Best, >> > Lin >> > >> > On Fri, Jun 26, 2015 at 1:06 AM, Lin M wrote: >> > Hi Dr. Thompson, >> > >> > I have added a method in vtkPatchInterpolation to generate triangle >> strips for surfaces. I tested a cylindrical surface patch from the NURBS >> book and I think it's correct. >> > >> > Best, >> > Lin >> > >> > On Thu, Jun 25, 2015 at 7:32 PM, David Thompson < >> david.thompson at kitware.com> wrote: >> > Hi Lin, >> > >> > > Your last message is quite informative. I think it is mainly to >> implement a method in vtkPatchInterpolation which takes in a bezier patch, >> number of samples and ... >> > >> > >> > That would be a great start. Eventually it would be nice to have >> curvature-adapted surfaces, but just accepting a number of samples along >> each axis will be something we need in any event. >> > >> > > ... return a vtkUnstructuredGrid? >> > >> > I would accept a vtkUnstructuredGrid pointer as input and insert into >> it so that it is easy to create one grid with triangles from multiple >> patches. >> > >> > David >> > >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Gerrick.Bivins at halliburton.com Mon Jun 29 17:42:36 2015 From: Gerrick.Bivins at halliburton.com (Gerrick Bivins) Date: Mon, 29 Jun 2015 21:42:36 +0000 Subject: [vtk-developers] [EXTERNAL] vtk 6.3 and vtk 7.0 In-Reply-To: References: Message-ID: ?* deprecate the existing zero copy array API in preparation for a significant refactoring that will come in 7.0. The refactor will make zero copy arrays both simpler to use and perform better.? Where can I find more information about this? Does the ?Zero copy array refactor? expose this framework to wrapped languages, Java in particular? Currently the duplication of data is one of the things holding up adoption of VTK in our application. Gerrick From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of David E DeMarle Sent: Monday, June 29, 2015 9:42 AM To: vtkdev; vtkusers at vtk.org Subject: [EXTERNAL] [vtk-developers] vtk 6.3 and vtk 7.0 Hey vtkers, We are hoping to do a vtk 6.3 release in the next couple of weeks and then immediately follow that up with a 7.0 release. We'd are putting out a 6.3 out in order to: * deprecate the existing zero copy array API in preparation for a significant refactoring that will come in 7.0. The refactor will make zero copy arrays both simpler to use and perform better. * package up all of the progress that has been made in the master branch's OpenGL2 surface and volume rendering. The vtkpython binaries will switch over to using the OpenGL2 back end this release. Please let us know if you have any feedback, critical bugs especially, and developers let us know if there is any work you have in a partially finished state that we should be sure to get into 6.3. If all goes well we'll have a release candidate for 6.3 next week. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 ---------------------------------------------------------------------- This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ken.martin at kitware.com Mon Jun 29 18:16:30 2015 From: ken.martin at kitware.com (Ken Martin) Date: Mon, 29 Jun 2015 18:16:30 -0400 Subject: [vtk-developers] Android: undefined reference to vtkRenderWindow::New() In-Reply-To: <1435575547017-5732575.post@n5.nabble.com> References: <1434554986629-5732418.post@n5.nabble.com> <1434561416248-5732424.post@n5.nabble.com> <1435046142805-5732490.post@n5.nabble.com> <29c436f64921d96ac967a3353496ee4c@mail.gmail.com> <1435575547017-5732575.post@n5.nabble.com> Message-ID: <546f3cfc067146b000b6d249744d5cc4@mail.gmail.com> I will definitely be taking a look at this in the future. But I am on vacation for the next ten days so it will be after that. 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. -----Original Message----- From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of Lonni Besan?on Sent: Monday, June 29, 2015 6:59 AM To: vtk-developers at vtk.org Subject: Re: [vtk-developers] Android: undefined reference to vtkRenderWindow::New() Ken Martin, any news on this issue then? -- View this message in context: http://vtk.1045678.n5.nabble.com/Android-undefined-reference-to-vtkRenderW indow-New-tp5732418p5732575.html Sent from the VTK - Dev mailing list archive at Nabble.com. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the list archives at: http://markmail.org/search/?q=vtk-developers Follow this link to subscribe/unsubscribe: http://public.kitware.com/mailman/listinfo/vtk-developers From lonni.besancon at gmail.com Tue Jun 30 04:15:38 2015 From: lonni.besancon at gmail.com (=?UTF-8?Q?Lonni_Besan=C3=A7on?=) Date: Tue, 30 Jun 2015 01:15:38 -0700 (MST) Subject: [vtk-developers] Android: undefined reference to vtkRenderWindow::New() In-Reply-To: <1435575547017-5732575.post@n5.nabble.com> References: <1434554986629-5732418.post@n5.nabble.com> <1434561416248-5732424.post@n5.nabble.com> <1435046142805-5732490.post@n5.nabble.com> <29c436f64921d96ac967a3353496ee4c@mail.gmail.com> <1435575547017-5732575.post@n5.nabble.com> Message-ID: <1435652138043-5732589.post@n5.nabble.com> Alright ! In that case when you come back and start looking at that would you mind posting to this thread again? Or maybe email me directly? Have fun in the meantime. Lonni -- View this message in context: http://vtk.1045678.n5.nabble.com/Android-undefined-reference-to-vtkRenderWindow-New-tp5732418p5732589.html Sent from the VTK - Dev mailing list archive at Nabble.com. From pieper at isomics.com Tue Jun 30 10:45:56 2015 From: pieper at isomics.com (Steve Pieper) Date: Tue, 30 Jun 2015 10:45:56 -0400 Subject: [vtk-developers] CommonGL idea Message-ID: Hi VTKers and CTKers - Nicolas and the XTK team [1,2] have been working on some upgrades to XTK's WebGL and volume rendering and I've been helping a bit while also playing with GLSL shaders in VTK. It seems to us that there's an opportunity to write the GLSL code in a way that would be usable in both the traditional desktop and the web/embedded use cases. Granted OpenGL != WebGL but the shaders are close enough that we think it's feasible to create a resource we're calling CommonGL. Anyway I wrote up some notes and ideas [2] and would appreciate any feedback or help. Best, Steve [1] https://github.com/xtk/X [2] http://slicedrop.com/ [3] https://docs.google.com/document/d/1-4Up_Shq6oFTGhwXIF5DuiXUYsdIMlAC1oK7eNHWP_o/edit?usp=sharing -------------- next part -------------- An HTML attachment was scrubbed... URL: From utkarsh.ayachit at kitware.com Tue Jun 30 10:46:57 2015 From: utkarsh.ayachit at kitware.com (Utkarsh Ayachit) Date: Tue, 30 Jun 2015 14:46:57 +0000 Subject: [vtk-developers] [EXTERNAL] vtk 6.3 and vtk 7.0 In-Reply-To: References: Message-ID: Gerrick, The *new* zero copy design literally started a week or two ago, so it is in its infancy, but I will write a design document soon. It doesn't however do anything new for access through wrapped languages. What exactly is your use-case. I am not sure what aspect is lacking in the current implementation in that regard. Utkarsh On Mon, Jun 29, 2015 at 6:04 PM Gerrick Bivins < Gerrick.Bivins at halliburton.com> wrote: > ?* deprecate the existing zero copy array API in preparation for a > significant refactoring that will come in 7.0. The refactor will make zero > copy arrays both simpler to use and perform better.? > > > > Where can I find more information about this? > > Does the ?Zero copy array refactor? expose this framework to wrapped > languages, Java in particular? > > Currently the duplication of data is one of the things holding up adoption > of VTK in our application. > > > > Gerrick > > > > *From:* vtk-developers [mailto:vtk-developers-bounces at vtk.org] *On Behalf > Of *David E DeMarle > *Sent:* Monday, June 29, 2015 9:42 AM > *To:* vtkdev; vtkusers at vtk.org > *Subject:* [EXTERNAL] [vtk-developers] vtk 6.3 and vtk 7.0 > > > > Hey vtkers, > > > > We are hoping to do a vtk 6.3 release in the next couple of weeks and then > immediately follow that up with a 7.0 release. > > > > We'd are putting out a 6.3 out in order to: > > * deprecate the existing zero copy array API in preparation for a > significant refactoring that will come in 7.0. The refactor will make zero > copy arrays both simpler to use and perform better. > > * package up all of the progress that has been made in the master branch's > OpenGL2 surface and volume rendering. The vtkpython binaries will switch > over to using the OpenGL2 back end this release. > > > > Please let us know if you have any feedback, critical bugs especially, and > developers let us know if there is any work you have in a partially > finished state that we should be sure to get into 6.3. > > > > If all goes well we'll have a release candidate for 6.3 next week. > > > > David E DeMarle > Kitware, Inc. > R&D Engineer > 21 Corporate Drive > Clifton Park, NY 12065-8662 > Phone: 518-881-4909 > This e-mail, including any attached files, may contain confidential and > privileged information for the sole use of the intended recipient. Any > review, use, distribution, or disclosure by others is strictly prohibited. > If you are not the intended recipient (or authorized to receive information > for the intended recipient), please contact the sender by reply e-mail and > delete all copies of this message. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the 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 Tue Jun 30 12:12:36 2015 From: majcjc at gmail.com (Lin M) Date: Tue, 30 Jun 2015 12:12:36 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> Message-ID: Hi Dr. Thompson, I have finished the conversion from NURBS patch to Bezier patch and generation of surface meshes. Now we can load some real nurbs shapes to test. :-) Best, Lin On Mon, Jun 29, 2015 at 3:22 PM, Lin M wrote: > Hi Dr. Thompson, > > I just learnt the polar form about b-spline ( > http://web.archive.org/web/20120227050519/http://tom.cs.byu.edu/~455/bs.pdf) > which gives a more intuitive explanation for knot insertion. > > As the example you mentioned before, given a knot vector {0,1,2,3} for a > 2-degree curve, we will have 3 control points P_0, P_1, P_2. They can be > represented in polar form as P(0,1), P(1,2) and P(2,3). > The control points for the bezier segments for this curve is > Segment 1: P(0,0), P(0,1), P(1,1) > Segment 2: P(1,1), P(1,2), P(2,2) > Segment 3: P(2,2), P(2,3), P(3,3) > > What we need to generate is P(0,0), P(1,1), P(2,2) and P(3,3). From > the affine combination property, we can get: > P(1,1) by interpolating P(0,1) and P(1,2) > P(2,2) by interpolating P(1,2) and P(2,3) > > for P(0,0) and P(3,3), it seems not that straightforward. It's possible to > generate P(0,2) first by interpolation P(1,2) and P(2,3) and generate > P(0,0) by interpolation P(0,1) and P(0,2). For P(3,3), first generate > P(1,3) by interpolation P(0,1) and P(1,2) and then generate P(3,3) by > interpolation P(1,3) and P(2,3). > > Best, > Lin > > > On Fri, Jun 26, 2015 at 6:09 PM, Lin M wrote: > >> What confuses me a lot is the different definition of the knot vector. As >> in the wiki page "Some modelers that use older algorithms for NURBS >> evaluation require two extra knot values for a total of (degree+N+1) >> knots". But how can I get 3 2-degree B-spline basis functions N_{0,2}, >> N_{1,2} and N_{2,2} from the knot vector {0,1,2,3}? From the knot vector >> {0,1,2,3}, we can get at most 3 zero-degree B-spline basis functions >> N_{0,0}, N_{1,0} and N_{2,0} and then we can only get one 2-degree basis >> function N_{0,2}. >> >> The reason why I said the algorithm from the NURBS book would fail is >> because it use a loop variable start from kSpan - sMult (kSpan is the id of >> the knot span where the insert knot is, and sMult is the current >> multiplicity of the insert knot). For the knot vector {0,1,2,3}, if we >> insert a new knot 0, the kSpan = 0, sMult = 1 and kSpan - sMult = -1 which >> is not correct. >> >> On Fri, Jun 26, 2015 at 4:41 PM, David Thompson < >> david.thompson at kitware.com> wrote: >> >>> Hi Lin, >>> >>> Knot insertion should not fail when a knot is not repeated. Instead, by >>> inserting the same knot value multiple times we can convert the control >>> polygon to a series of B?zier patches. If you start with a knot vector of >>> {0,1,2,3} for a degree 2 curve, then you can insert knots until the knot >>> vector is {0,0,0,1,1,1,2,3}. The resulting control points for the knot >>> interval [0,1] are a valid B?zier control polygon. You can do the same for >>> other knot values to extract B?zier patches for the intervals [1,2] and >>> [2,3]. >>> >>> David >>> >>> >>> > On Jun 26, 2015, at 4:08 PM, Lin M wrote: >>> > >>> > Hi Dr. Thompson, >>> > >>> > I have a question about the knot vector and the knot insertion. >>> > Currently the method for knot insertion is based on the algorithm from >>> the NURBS book where it always assumes that the first value and last value >>> in the knot vector repeat p+1 times. This makes the endpoints of the curve >>> always coincide with the first and last control points. As you mentioned >>> before, the knot vector may not always be like this and in such cases the >>> algorithm will fail. Is there any method to deal with this? >>> > >>> > Best, >>> > Lin >>> > >>> > On Fri, Jun 26, 2015 at 1:06 AM, Lin M wrote: >>> > Hi Dr. Thompson, >>> > >>> > I have added a method in vtkPatchInterpolation to generate triangle >>> strips for surfaces. I tested a cylindrical surface patch from the NURBS >>> book and I think it's correct. >>> > >>> > Best, >>> > Lin >>> > >>> > On Thu, Jun 25, 2015 at 7:32 PM, David Thompson < >>> david.thompson at kitware.com> wrote: >>> > Hi Lin, >>> > >>> > > Your last message is quite informative. I think it is mainly to >>> implement a method in vtkPatchInterpolation which takes in a bezier patch, >>> number of samples and ... >>> > >>> > >>> > That would be a great start. Eventually it would be nice to have >>> curvature-adapted surfaces, but just accepting a number of samples along >>> each axis will be something we need in any event. >>> > >>> > > ... return a vtkUnstructuredGrid? >>> > >>> > I would accept a vtkUnstructuredGrid pointer as input and insert into >>> it so that it is easy to create one grid with triangles from multiple >>> patches. >>> > >>> > David >>> > >>> > >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue Jun 30 12:42:09 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 30 Jun 2015 12:42:09 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> Message-ID: <27BBD790-73F3-4B89-A2F3-BDFC91DEED25@kitware.com> Hi Lin, > I have finished the conversion from NURBS patch to Bezier patch and generation of surface meshes. > > Now we can load some real nurbs shapes to test. :-) Great! I'm working on 2 sources of data. + [CGM](https://bitbucket.org/fathomteam/cgm) provides a nice interface to OpenCascade's surface definitions, including these methods: https://bitbucket.org/fathomteam/cgm/src/1aab72dc7c4ca6d0333a88df7b857e49d661db43/geom/Surface.hpp?at=master#cl-370 https://bitbucket.org/fathomteam/cgm/src/1aab72dc7c4ca6d0333a88df7b857e49d661db43/geom/Curve.hpp?at=master#cl-364 CGM has a few CAD models for testing in the "test" directory of the source repo. + [PetIGA](https://bitbucket.org/dalcinl/petiga) has 3D NURBS including simulation results but is in a binary file format that is undocumented (except in the source). David From majcjc at gmail.com Tue Jun 30 12:50:34 2015 From: majcjc at gmail.com (Lin M) Date: Tue, 30 Jun 2015 12:50:34 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <27BBD790-73F3-4B89-A2F3-BDFC91DEED25@kitware.com> References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> <27BBD790-73F3-4B89-A2F3-BDFC91DEED25@kitware.com> Message-ID: I forgot one thing, the vtkPoints can not hold a 4-dimension vtkDataArray so I cannot store the control points in the vtkStructuredGrid. Currently I stored it separately in a vtkDataArray for test. Do I need to implement a vtkPoints subclass likt vtkControlPoints to allow it store 4-dimension coordinates? On Tue, Jun 30, 2015 at 12:42 PM, David Thompson wrote: > Hi Lin, > > > I have finished the conversion from NURBS patch to Bezier patch and > generation of surface meshes. > > > > Now we can load some real nurbs shapes to test. :-) > > Great! I'm working on 2 sources of data. > > + [CGM](https://bitbucket.org/fathomteam/cgm) provides a nice interface > to OpenCascade's surface definitions, including these methods: > > > https://bitbucket.org/fathomteam/cgm/src/1aab72dc7c4ca6d0333a88df7b857e49d661db43/geom/Surface.hpp?at=master#cl-370 > > https://bitbucket.org/fathomteam/cgm/src/1aab72dc7c4ca6d0333a88df7b857e49d661db43/geom/Curve.hpp?at=master#cl-364 > > CGM has a few CAD models for testing in the "test" directory of the source > repo. > > + [PetIGA](https://bitbucket.org/dalcinl/petiga) has 3D NURBS including > simulation results but is in a binary file format that is undocumented > (except in the source). > > David -------------- next part -------------- An HTML attachment was scrubbed... URL: From cory.quammen at kitware.com Tue Jun 30 12:51:00 2015 From: cory.quammen at kitware.com (Cory Quammen) Date: Tue, 30 Jun 2015 12:51:00 -0400 Subject: [vtk-developers] CommonGL idea In-Reply-To: References: Message-ID: Hi Steve, How much does the OpenGL2 backend in VTK help in getting you to CommonGL? Thanks, Cory On Tue, Jun 30, 2015 at 10:45 AM, Steve Pieper wrote: > Hi VTKers and CTKers - > > Nicolas and the XTK team [1,2] have been working on some upgrades to XTK's > WebGL and volume rendering and I've been helping a bit while also playing > with GLSL shaders in VTK. > > It seems to us that there's an opportunity to write the GLSL code in a way > that would be usable in both the traditional desktop and the web/embedded > use cases. > > Granted OpenGL != WebGL but the shaders are close enough that we think > it's feasible to create a resource we're calling CommonGL. > > Anyway I wrote up some notes and ideas [2] and would appreciate any > feedback or help. > > Best, > Steve > > [1] https://github.com/xtk/X > > [2] http://slicedrop.com/ > > [3] > https://docs.google.com/document/d/1-4Up_Shq6oFTGhwXIF5DuiXUYsdIMlAC1oK7eNHWP_o/edit?usp=sharing > > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > > -- Cory Quammen R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue Jun 30 12:59:06 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 30 Jun 2015 12:59:06 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> <27BBD790-73F3-4B89-A2F3-BDFC91DEED25@kitware.com> Message-ID: <651081FE-9818-4935-A190-40DEF403C243@kitware.com> > I forgot one thing, the vtkPoints can not hold a 4-dimension vtkDataArray so I cannot store the control points in the vtkStructuredGrid. Currently I stored it separately in a vtkDataArray for test. Do I need to implement a vtkPoints subclass likt vtkControlPoints to allow it store 4-dimension coordinates? Hi Lin, I would not create a new class. There are two alternatives and different spline software packages use them both: + Do as you have done, keeping point coordinates separate from the homogenous coordinate. This approach increases the number of things that have to get passed around between functions. + Pass the points around as just a vtkDataArray with 4 components per tuple. This approach makes it hard to use just the first three coordinates as points when you know the homogeneous coordinate is 1 for all of the values you are dealing with. My mild preference is the latter (i.e., make the arguments to your functions take a vtkDataArray with 4 components per tuple), but either will be fine. I want to avoid writing a 4-D point subclass because then algorithms that generate patches as output will need a new dataset type and it will be hard to use existing filters (such as the vtkArrayCalculator) on them. David > > On Tue, Jun 30, 2015 at 12:42 PM, David Thompson wrote: > Hi Lin, > > > I have finished the conversion from NURBS patch to Bezier patch and generation of surface meshes. > > > > Now we can load some real nurbs shapes to test. :-) > > Great! I'm working on 2 sources of data. > > + [CGM](https://bitbucket.org/fathomteam/cgm) provides a nice interface to OpenCascade's surface definitions, including these methods: > > https://bitbucket.org/fathomteam/cgm/src/1aab72dc7c4ca6d0333a88df7b857e49d661db43/geom/Surface.hpp?at=master#cl-370 > https://bitbucket.org/fathomteam/cgm/src/1aab72dc7c4ca6d0333a88df7b857e49d661db43/geom/Curve.hpp?at=master#cl-364 > > CGM has a few CAD models for testing in the "test" directory of the source repo. > > + [PetIGA](https://bitbucket.org/dalcinl/petiga) has 3D NURBS including simulation results but is in a binary file format that is undocumented (except in the source). > > David > From majcjc at gmail.com Tue Jun 30 13:35:38 2015 From: majcjc at gmail.com (Lin M) Date: Tue, 30 Jun 2015 13:35:38 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <651081FE-9818-4935-A190-40DEF403C243@kitware.com> References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> <27BBD790-73F3-4B89-A2F3-BDFC91DEED25@kitware.com> <651081FE-9818-4935-A190-40DEF403C243@kitware.com> Message-ID: I didn't separate the homogenous coordinate with point coordinates but stored them all in a vtkDataArray with 4 components per tuple just as you suggest. In this way, vtkStructuredGrid cannot hold them as vtkPoints. The current API is like void vtkNURBSPatchAdaptor::GetPatchShape(vtkUnstructuredGrid* outputSp, vtkDataArray* ctrlPts, int* ctrlPtsNum) the outputSp holds the surface mesh, ctrlPts and ctrlPtsNum hold information and data of nurbs control points, and the vtkSturcturedGrid only holds knot vectors and length. On Tue, Jun 30, 2015 at 12:59 PM, David Thompson wrote: > > I forgot one thing, the vtkPoints can not hold a 4-dimension > vtkDataArray so I cannot store the control points in the vtkStructuredGrid. > Currently I stored it separately in a vtkDataArray for test. Do I need to > implement a vtkPoints subclass likt vtkControlPoints to allow it store > 4-dimension coordinates? > > Hi Lin, > > I would not create a new class. There are two alternatives and different > spline software packages use them both: > > + Do as you have done, keeping point coordinates separate from the > homogenous coordinate. This approach increases the number of things that > have to get passed around between functions. > > + Pass the points around as just a vtkDataArray with 4 components per > tuple. This approach makes it hard to use just the first three coordinates > as points when you know the homogeneous coordinate is 1 for all of the > values you are dealing with. > > My mild preference is the latter (i.e., make the arguments to your > functions take a vtkDataArray with 4 components per tuple), but either will > be fine. > > I want to avoid writing a 4-D point subclass because then algorithms that > generate patches as output will need a new dataset type and it will be hard > to use existing filters (such as the vtkArrayCalculator) on them. > > David > > > > > On Tue, Jun 30, 2015 at 12:42 PM, David Thompson < > david.thompson at kitware.com> wrote: > > Hi Lin, > > > > > I have finished the conversion from NURBS patch to Bezier patch and > generation of surface meshes. > > > > > > Now we can load some real nurbs shapes to test. :-) > > > > Great! I'm working on 2 sources of data. > > > > + [CGM](https://bitbucket.org/fathomteam/cgm) provides a nice interface > to OpenCascade's surface definitions, including these methods: > > > > > https://bitbucket.org/fathomteam/cgm/src/1aab72dc7c4ca6d0333a88df7b857e49d661db43/geom/Surface.hpp?at=master#cl-370 > > > https://bitbucket.org/fathomteam/cgm/src/1aab72dc7c4ca6d0333a88df7b857e49d661db43/geom/Curve.hpp?at=master#cl-364 > > > > CGM has a few CAD models for testing in the "test" directory of the > source repo. > > > > + [PetIGA](https://bitbucket.org/dalcinl/petiga) has 3D NURBS including > simulation results but is in a binary file format that is undocumented > (except in the source). > > > > David > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Tue Jun 30 13:58:56 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 30 Jun 2015 13:58:56 -0400 Subject: [vtk-developers] VTK Roadmap Message-ID: Hi folks, As Dave DeMarle mentioned, we are gearing towards a VTK 6.3 release. VTK 7 will follow very shortly (in weeks). I'd like to shed some light here on our thinking and how we are planning to move forward. As was previously discussed in the VTK developers list [1] [2], we are considering maintaining VTK 6.x for a long time (3-5 years) while moving forward with VTK 7 and 8 in 2015 and 2016. There are some major changes happening in the computing and C++ worlds and we would like evolve VTK more quickly to stay up to date. Some of the major changes that we are considering and/or working on are: * Major refactoring of rendering (OpenGL as well as ray tracing etc.) * Multi/many-core support / SMP computing on CPUs and accelerators. VTK-m integration [3]. * Changes to data model to support zero copy interface to other data layouts, more efficient APIs, more cell types, more dataset types etc. * Better separation of a public, wrapped API and toolkit/C++ internal API mainly to support efficiency * Introduction of C++ 11 features Much of this will require introducing changes that break backwards compatibility and also require newer compilers, graphics cards / drivers etc. So the idea is that we will do our best to support as much as possible a broad set of architectures and backwards compatibility but break things when necessary in VTK 7 and beyond. We will maintain VTK 6.x so that folks that are stuck on legacy systems or code bases can continue to benefit from bug fixes. We have a way of continuing to maintain a broad set of dashboards and also the same review process as VTK master so that we can continue to ensure the quality of VTK 6.x as well as new releases. What do you guys think? Please provide feedback so that we can adjust our plans to meet the needs of the community as much as possible. Best, -berk [1] : http://bit.ly/1BUHFKT [2] : http://bit.ly/1g7LSRG [3] : http://m.vtk.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue Jun 30 14:10:22 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 30 Jun 2015 14:10:22 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> <27BBD790-73F3-4B89-A2F3-BDFC91DEED25@kitware.com> <651081FE-9818-4935-A190-40DEF403C243@kitware.com> Message-ID: Hi Lin, > I didn't separate the homogenous coordinate with point coordinates but stored them all in a vtkDataArray with 4 components per tuple just as you suggest. In this way, vtkStructuredGrid cannot hold them as vtkPoints. The current API is like > > void vtkNURBSPatchAdaptor::GetPatchShape(vtkUnstructuredGrid* outputSp, vtkDataArray* ctrlPts, int* ctrlPtsNum) > the outputSp holds the surface mesh, ctrlPts and ctrlPtsNum hold information and data of nurbs control points, and the vtkSturcturedGrid only holds knot vectors and length. Actually, the vtkStructuredGrid can hold the control points as PointData() (as opposed to Point coordinates). There is no constraint on the number of components per tuple. The idea is to access the control points and knot data like this: vtkStructuredGrid* splineData; vtkDataArray* controlPoints = splineData->GetPointData()->GetArrayByName("control polygon"); vtkDataArray* knotVector = splineData->GetFieldData()->GetArrayByName("knot vector"); int numControlPointsPerAxis[3]; splineData->GetDimensions(numControlPointsPerAxis); That way all of the spline data is grouped into one dataset; it's just that the splineData's vtkPoints would not hold the control points. We could also store additional information in the arrays of splineData->GetFieldData(). For example, flags indicating which axes (if any) were periodic could be stored in a separate field-data array since there is no constraint on the number of components or tuples of field-data arrays. Does that make sense? David From Gerrick.Bivins at halliburton.com Tue Jun 30 14:06:55 2015 From: Gerrick.Bivins at halliburton.com (Gerrick Bivins) Date: Tue, 30 Jun 2015 18:06:55 +0000 Subject: [vtk-developers] [EXTERNAL] vtk 6.3 and vtk 7.0 In-Reply-To: References: Message-ID: Hi Utkarsh, Totally understandable. ? I?m actually basing my question about wrapped languages (specifically Java) on my previous attempt to use the? zero copy API?. It seemed like all the references/examples were for accessing the data from the c++/native side so I just went for it. After getting things built and attempting to implement things, I saw that most of the referenced classes were not produced for Java and then I think I realized that I would have to implement data access on native side and then allow vtk to wrap my implementations. (Is that true?) That felt a bit unnatural as a Java developer especially if my originating data is accessed from a Java API. What I would expect is that classes like vtkMappedUnstructuredGrid ,vtkMappedDataArray ,vtkUnstructuredGridBase etc (or some equivalent) would show up as abstract Java classes (better yet interfaces) that I could implement/extend and work within the framework. Is that more clear? Gerrick From: Utkarsh Ayachit [mailto:utkarsh.ayachit at kitware.com] Sent: Tuesday, June 30, 2015 9:47 AM To: Gerrick Bivins; David E DeMarle; vtkdev; vtkusers at vtk.org Subject: Re: [vtk-developers] [EXTERNAL] vtk 6.3 and vtk 7.0 Gerrick, The *new* zero copy design literally started a week or two ago, so it is in its infancy, but I will write a design document soon. It doesn't however do anything new for access through wrapped languages. What exactly is your use-case. I am not sure what aspect is lacking in the current implementation in that regard. Utkarsh On Mon, Jun 29, 2015 at 6:04 PM Gerrick Bivins > wrote: ?* deprecate the existing zero copy array API in preparation for a significant refactoring that will come in 7.0. The refactor will make zero copy arrays both simpler to use and perform better.? Where can I find more information about this? Does the ?Zero copy array refactor? expose this framework to wrapped languages, Java in particular? Currently the duplication of data is one of the things holding up adoption of VTK in our application. Gerrick From: vtk-developers [mailto:vtk-developers-bounces at vtk.org] On Behalf Of David E DeMarle Sent: Monday, June 29, 2015 9:42 AM To: vtkdev; vtkusers at vtk.org Subject: [EXTERNAL] [vtk-developers] vtk 6.3 and vtk 7.0 Hey vtkers, We are hoping to do a vtk 6.3 release in the next couple of weeks and then immediately follow that up with a 7.0 release. We'd are putting out a 6.3 out in order to: * deprecate the existing zero copy array API in preparation for a significant refactoring that will come in 7.0. The refactor will make zero copy arrays both simpler to use and perform better. * package up all of the progress that has been made in the master branch's OpenGL2 surface and volume rendering. The vtkpython binaries will switch over to using the OpenGL2 back end this release. Please let us know if you have any feedback, critical bugs especially, and developers let us know if there is any work you have in a partially finished state that we should be sure to get into 6.3. If all goes well we'll have a release candidate for 6.3 next week. David E DeMarle Kitware, Inc. R&D Engineer 21 Corporate Drive Clifton Park, NY 12065-8662 Phone: 518-881-4909 This e-mail, including any attached files, may contain confidential and privileged information for the sole use of the intended recipient. Any review, use, distribution, or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive information for the intended recipient), please contact the sender by reply e-mail and delete all copies of this message. _______________________________________________ Powered by www.kitware.com Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html Search the 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 matthew.brett at gmail.com Tue Jun 30 14:47:05 2015 From: matthew.brett at gmail.com (Matthew Brett) Date: Tue, 30 Jun 2015 11:47:05 -0700 Subject: [vtk-developers] [vtkusers] VTK Roadmap In-Reply-To: References: Message-ID: Hi, On Tue, Jun 30, 2015 at 10:58 AM, Berk Geveci wrote: > Hi folks, > > As Dave DeMarle mentioned, we are gearing towards a VTK 6.3 release. VTK 7 > will follow very shortly (in weeks). I'd like to shed some light here on our > thinking and how we are planning to move forward. > > As was previously discussed in the VTK developers list [1] [2], we are > considering maintaining VTK 6.x for a long time (3-5 years) while moving > forward with VTK 7 and 8 in 2015 and 2016. There are some major changes > happening in the computing and C++ worlds and we would like evolve VTK more > quickly to stay up to date. Some of the major changes that we are > considering and/or working on are: > > * Major refactoring of rendering (OpenGL as well as ray tracing etc.) > * Multi/many-core support / SMP computing on CPUs and accelerators. VTK-m > integration [3]. > * Changes to data model to support zero copy interface to other data > layouts, more efficient APIs, more cell types, more dataset types etc. > * Better separation of a public, wrapped API and toolkit/C++ internal API > mainly to support efficiency > * Introduction of C++ 11 features > > Much of this will require introducing changes that break backwards > compatibility and also require newer compilers, graphics cards / drivers > etc. So the idea is that we will do our best to support as much as possible > a broad set of architectures and backwards compatibility but break things > when necessary in VTK 7 and beyond. We will maintain VTK 6.x so that folks > that are stuck on legacy systems or code bases can continue to benefit from > bug fixes. We have a way of continuing to maintain a broad set of dashboards > and also the same review process as VTK master so that we can continue to > ensure the quality of VTK 6.x as well as new releases. > > What do you guys think? Please provide feedback so that we can adjust our > plans to meet the needs of the community as much as possible. I would like to put in a humble plea to add Python 3 compatibility to that list: http://astrofrog.github.io/blog/2015/05/09/2015-survey-results Best, Matthew From majcjc at gmail.com Tue Jun 30 15:19:26 2015 From: majcjc at gmail.com (Lin M) Date: Tue, 30 Jun 2015 15:19:26 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> <27BBD790-73F3-4B89-A2F3-BDFC91DEED25@kitware.com> <651081FE-9818-4935-A190-40DEF403C243@kitware.com> Message-ID: Yes, I can store it in PointData(), but splineData->GetDimensions(numControlPointsPerAxis) will not return the correct number of control points. It will return {0,0,0} if we hold the control points in PointData(). Though we can also hold a simple 1*3 array in vtkFieldData just like we store the length of knot vectors. On Tue, Jun 30, 2015 at 2:10 PM, David Thompson wrote: > Hi Lin, > > > I didn't separate the homogenous coordinate with point coordinates but > stored them all in a vtkDataArray with 4 components per tuple just as you > suggest. In this way, vtkStructuredGrid cannot hold them as vtkPoints. The > current API is like > > > > void vtkNURBSPatchAdaptor::GetPatchShape(vtkUnstructuredGrid* outputSp, > vtkDataArray* ctrlPts, int* ctrlPtsNum) > > the outputSp holds the surface mesh, ctrlPts and ctrlPtsNum hold > information and data of nurbs control points, and the vtkSturcturedGrid > only holds knot vectors and length. > > Actually, the vtkStructuredGrid can hold the control points as PointData() > (as opposed to Point coordinates). There is no constraint on the number of > components per tuple. The idea is to access the control points and knot > data like this: > > vtkStructuredGrid* splineData; > vtkDataArray* controlPoints = > splineData->GetPointData()->GetArrayByName("control polygon"); > vtkDataArray* knotVector = > splineData->GetFieldData()->GetArrayByName("knot vector"); > int numControlPointsPerAxis[3]; > splineData->GetDimensions(numControlPointsPerAxis); > > That way all of the spline data is grouped into one dataset; it's just > that the splineData's vtkPoints would not hold the control points. We could > also store additional information in the arrays of > splineData->GetFieldData(). For example, flags indicating which axes (if > any) were periodic could be stored in a separate field-data array since > there is no constraint on the number of components or tuples of field-data > arrays. > > Does that make sense? > > David > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.thompson at kitware.com Tue Jun 30 15:24:36 2015 From: david.thompson at kitware.com (David Thompson) Date: Tue, 30 Jun 2015 15:24:36 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> <27BBD790-73F3-4B89-A2F3-BDFC91DEED25@kitware.com> <651081FE-9818-4935-A190-40DEF403C243@kitware.com> Message-ID: <9A878527-ACE1-421E-BDD7-36BC97FA6D9F@kitware.com> Hmmm. I think this would be a good time to use vtkMappedDataArray to create a version of the control point coordinates with 3 components that divides x, y, and z by the homogeneous coordinate. The vtkStructuredGrid's vtkPoints instance would own the vtkMappedDataArray, which would own a reference to the 4-component array (also owned by the PointData() of the vtkStructuredGrid). That will make rendering the control polygon easy and let GetDimensions() return the correct value. Just make sure that you call SetDimensions() before setting the vtkPoints array to be the vtkMappedDataArray. David > On Jun 30, 2015, at 3:19 PM, Lin M wrote: > > Yes, I can store it in PointData(), but splineData->GetDimensions(numControlPointsPerAxis) will not return the correct number of control points. It will return {0,0,0} if we hold the control points in PointData(). Though we can also hold a simple 1*3 array in vtkFieldData just like we store the length of knot vectors. > > On Tue, Jun 30, 2015 at 2:10 PM, David Thompson wrote: > Hi Lin, > > > I didn't separate the homogenous coordinate with point coordinates but stored them all in a vtkDataArray with 4 components per tuple just as you suggest. In this way, vtkStructuredGrid cannot hold them as vtkPoints. The current API is like > > > > void vtkNURBSPatchAdaptor::GetPatchShape(vtkUnstructuredGrid* outputSp, vtkDataArray* ctrlPts, int* ctrlPtsNum) > > the outputSp holds the surface mesh, ctrlPts and ctrlPtsNum hold information and data of nurbs control points, and the vtkSturcturedGrid only holds knot vectors and length. > > Actually, the vtkStructuredGrid can hold the control points as PointData() (as opposed to Point coordinates). There is no constraint on the number of components per tuple. The idea is to access the control points and knot data like this: > > vtkStructuredGrid* splineData; > vtkDataArray* controlPoints = splineData->GetPointData()->GetArrayByName("control polygon"); > vtkDataArray* knotVector = splineData->GetFieldData()->GetArrayByName("knot vector"); > int numControlPointsPerAxis[3]; > splineData->GetDimensions(numControlPointsPerAxis); > > That way all of the spline data is grouped into one dataset; it's just that the splineData's vtkPoints would not hold the control points. We could also store additional information in the arrays of splineData->GetFieldData(). For example, flags indicating which axes (if any) were periodic could be stored in a separate field-data array since there is no constraint on the number of components or tuples of field-data arrays. > > Does that make sense? > > David > > From majcjc at gmail.com Tue Jun 30 15:30:16 2015 From: majcjc at gmail.com (Lin M) Date: Tue, 30 Jun 2015 15:30:16 -0400 Subject: [vtk-developers] Class design for spline visualizations In-Reply-To: <9A878527-ACE1-421E-BDD7-36BC97FA6D9F@kitware.com> References: <32159C29-5A99-4818-970A-166B2F74A178@kitware.com> <3C513D9F-71D5-4D1F-B35F-C82A45CD5BB0@kitware.com> <20150420131200.GA450@megas.kitware.com> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> <27BBD790-73F3-4B89-A2F3-BDFC91DEED25@kitware.com> <651081FE-9818-4935-A190-40DEF403C243@kitware.com> <9A878527-ACE1-421E-BDD7-36BC97FA6D9F@kitware.com> Message-ID: This is a good idea! On Tue, Jun 30, 2015 at 3:24 PM, David Thompson wrote: > Hmmm. I think this would be a good time to use vtkMappedDataArray to > create a version of the control point coordinates with 3 components that > divides x, y, and z by the homogeneous coordinate. The vtkStructuredGrid's > vtkPoints instance would own the vtkMappedDataArray, which would own a > reference to the 4-component array (also owned by the PointData() of the > vtkStructuredGrid). > > That will make rendering the control polygon easy and let GetDimensions() > return the correct value. Just make sure that you call SetDimensions() > before setting the vtkPoints array to be the vtkMappedDataArray. > > David > > > On Jun 30, 2015, at 3:19 PM, Lin M wrote: > > > > Yes, I can store it in PointData(), but > splineData->GetDimensions(numControlPointsPerAxis) will not return the > correct number of control points. It will return {0,0,0} if we hold the > control points in PointData(). Though we can also hold a simple 1*3 array > in vtkFieldData just like we store the length of knot vectors. > > > > On Tue, Jun 30, 2015 at 2:10 PM, David Thompson < > david.thompson at kitware.com> wrote: > > Hi Lin, > > > > > I didn't separate the homogenous coordinate with point coordinates but > stored them all in a vtkDataArray with 4 components per tuple just as you > suggest. In this way, vtkStructuredGrid cannot hold them as vtkPoints. The > current API is like > > > > > > void vtkNURBSPatchAdaptor::GetPatchShape(vtkUnstructuredGrid* > outputSp, vtkDataArray* ctrlPts, int* ctrlPtsNum) > > > the outputSp holds the surface mesh, ctrlPts and ctrlPtsNum hold > information and data of nurbs control points, and the vtkSturcturedGrid > only holds knot vectors and length. > > > > Actually, the vtkStructuredGrid can hold the control points as > PointData() (as opposed to Point coordinates). There is no constraint on > the number of components per tuple. The idea is to access the control > points and knot data like this: > > > > vtkStructuredGrid* splineData; > > vtkDataArray* controlPoints = > splineData->GetPointData()->GetArrayByName("control polygon"); > > vtkDataArray* knotVector = > splineData->GetFieldData()->GetArrayByName("knot vector"); > > int numControlPointsPerAxis[3]; > > splineData->GetDimensions(numControlPointsPerAxis); > > > > That way all of the spline data is grouped into one dataset; it's just > that the splineData's vtkPoints would not hold the control points. We could > also store additional information in the arrays of > splineData->GetFieldData(). For example, flags indicating which axes (if > any) were periodic could be stored in a separate field-data array since > there is no constraint on the number of components or tuples of field-data > arrays. > > > > Does that make sense? > > > > David > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at isomics.com Tue Jun 30 15:37:38 2015 From: pieper at isomics.com (Steve Pieper) Date: Tue, 30 Jun 2015 15:37:38 -0400 Subject: [vtk-developers] CommonGL idea In-Reply-To: References: Message-ID: Hi Cory - I know there is more OpenGL2 work for VTK coming down the pipeline but I've looked through the what is in VTK 6.2 and clearly there is a lot of logic in the C++ code for generating and manipulating the GLSL shader code. I think it would be hard to meaningfully re-use the current VTK shader code in WebGL, but I think we can write new code that works either place, or at least that's the hypothesis. For people wanting a concrete example, this script works with some minor modifications to VTK (in the same wrap-shaders branch -- basically just some extra classes wrapped for python). https://github.com/pieper/VTK/blob/wrap-shaders/Rendering/OpenGL/Testing/Python/DynamicShader.py The shader itself came from this source with only minor modifications: http://glslsandbox.com/e#25816.0 -Steve On Tue, Jun 30, 2015 at 12:51 PM, Cory Quammen wrote: > Hi Steve, > > How much does the OpenGL2 backend in VTK help in getting you to CommonGL? > > Thanks, > Cory > > On Tue, Jun 30, 2015 at 10:45 AM, Steve Pieper wrote: > >> Hi VTKers and CTKers - >> >> Nicolas and the XTK team [1,2] have been working on some upgrades to >> XTK's WebGL and volume rendering and I've been helping a bit while also >> playing with GLSL shaders in VTK. >> >> It seems to us that there's an opportunity to write the GLSL code in a >> way that would be usable in both the traditional desktop and the >> web/embedded use cases. >> >> Granted OpenGL != WebGL but the shaders are close enough that we think >> it's feasible to create a resource we're calling CommonGL. >> >> Anyway I wrote up some notes and ideas [2] and would appreciate any >> feedback or help. >> >> Best, >> Steve >> >> [1] https://github.com/xtk/X >> >> [2] http://slicedrop.com/ >> >> [3] >> https://docs.google.com/document/d/1-4Up_Shq6oFTGhwXIF5DuiXUYsdIMlAC1oK7eNHWP_o/edit?usp=sharing >> >> _______________________________________________ >> Powered by www.kitware.com >> >> Visit other Kitware open-source projects at >> http://www.kitware.com/opensource/opensource.html >> >> Search the list archives at: http://markmail.org/search/?q=vtk-developers >> >> Follow this link to subscribe/unsubscribe: >> http://public.kitware.com/mailman/listinfo/vtk-developers >> >> >> > > > -- > Cory Quammen > R&D Engineer > Kitware, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Jun 30 15:48:01 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 30 Jun 2015 13:48:01 -0600 Subject: [vtk-developers] [vtkusers] VTK Roadmap In-Reply-To: References: Message-ID: On Tue, Jun 30, 2015 at 12:47 PM, Matthew Brett wrote: > Hi, > > On Tue, Jun 30, 2015 at 10:58 AM, Berk Geveci > wrote: > > Hi folks, > > > > As Dave DeMarle mentioned, we are gearing towards a VTK 6.3 release. VTK > 7 > > will follow very shortly (in weeks). I'd like to shed some light here on > our > > thinking and how we are planning to move forward. > > > > As was previously discussed in the VTK developers list [1] [2], we are > > considering maintaining VTK 6.x for a long time (3-5 years) while moving > > forward with VTK 7 and 8 in 2015 and 2016. There are some major changes > > happening in the computing and C++ worlds and we would like evolve VTK > more > > quickly to stay up to date. Some of the major changes that we are > > considering and/or working on are: > > > > * Major refactoring of rendering (OpenGL as well as ray tracing etc.) > > * Multi/many-core support / SMP computing on CPUs and accelerators. VTK-m > > integration [3]. > > * Changes to data model to support zero copy interface to other data > > layouts, more efficient APIs, more cell types, more dataset types etc. > > * Better separation of a public, wrapped API and toolkit/C++ internal API > > mainly to support efficiency > > * Introduction of C++ 11 features > > > > Much of this will require introducing changes that break backwards > > compatibility and also require newer compilers, graphics cards / drivers > > etc. So the idea is that we will do our best to support as much as > possible > > a broad set of architectures and backwards compatibility but break things > > when necessary in VTK 7 and beyond. We will maintain VTK 6.x so that > folks > > that are stuck on legacy systems or code bases can continue to benefit > from > > bug fixes. We have a way of continuing to maintain a broad set of > dashboards > > and also the same review process as VTK master so that we can continue to > > ensure the quality of VTK 6.x as well as new releases. > > > > What do you guys think? Please provide feedback so that we can adjust our > > plans to meet the needs of the community as much as possible. > > I would like to put in a humble plea to add Python 3 compatibility to that > list: > > http://astrofrog.github.io/blog/2015/05/09/2015-survey-results Python 3 is being worked on (right now by me, and others can join in a couple weeks once the core pieces are in place). No, it won't be part of 6.3, however. - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From berk.geveci at kitware.com Tue Jun 30 16:24:17 2015 From: berk.geveci at kitware.com (Berk Geveci) Date: Tue, 30 Jun 2015 16:24:17 -0400 Subject: [vtk-developers] [vtkusers] VTK Roadmap In-Reply-To: References: Message-ID: Yup. Python 3 is now on the roadmap. Probably the first release after 7, in a few months. -berk On Tue, Jun 30, 2015 at 3:48 PM, David Gobbi wrote: > On Tue, Jun 30, 2015 at 12:47 PM, Matthew Brett > wrote: > >> Hi, >> >> On Tue, Jun 30, 2015 at 10:58 AM, Berk Geveci >> wrote: >> > Hi folks, >> > >> > As Dave DeMarle mentioned, we are gearing towards a VTK 6.3 release. >> VTK 7 >> > will follow very shortly (in weeks). I'd like to shed some light here >> on our >> > thinking and how we are planning to move forward. >> > >> > As was previously discussed in the VTK developers list [1] [2], we are >> > considering maintaining VTK 6.x for a long time (3-5 years) while moving >> > forward with VTK 7 and 8 in 2015 and 2016. There are some major changes >> > happening in the computing and C++ worlds and we would like evolve VTK >> more >> > quickly to stay up to date. Some of the major changes that we are >> > considering and/or working on are: >> > >> > * Major refactoring of rendering (OpenGL as well as ray tracing etc.) >> > * Multi/many-core support / SMP computing on CPUs and accelerators. >> VTK-m >> > integration [3]. >> > * Changes to data model to support zero copy interface to other data >> > layouts, more efficient APIs, more cell types, more dataset types etc. >> > * Better separation of a public, wrapped API and toolkit/C++ internal >> API >> > mainly to support efficiency >> > * Introduction of C++ 11 features >> > >> > Much of this will require introducing changes that break backwards >> > compatibility and also require newer compilers, graphics cards / drivers >> > etc. So the idea is that we will do our best to support as much as >> possible >> > a broad set of architectures and backwards compatibility but break >> things >> > when necessary in VTK 7 and beyond. We will maintain VTK 6.x so that >> folks >> > that are stuck on legacy systems or code bases can continue to benefit >> from >> > bug fixes. We have a way of continuing to maintain a broad set of >> dashboards >> > and also the same review process as VTK master so that we can continue >> to >> > ensure the quality of VTK 6.x as well as new releases. >> > >> > What do you guys think? Please provide feedback so that we can adjust >> our >> > plans to meet the needs of the community as much as possible. >> >> I would like to put in a humble plea to add Python 3 compatibility to >> that list: >> >> http://astrofrog.github.io/blog/2015/05/09/2015-survey-results > > > Python 3 is being worked on (right now by me, and others can join in a > couple weeks once the core pieces are in place). No, it won't be part of > 6.3, however. > > - 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 Tue Jun 30 16:55:43 2015 From: majcjc at gmail.com (Lin M) Date: Tue, 30 Jun 2015 16:55:43 -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> <8ABE4DD7-1ABC-4E73-8485-6723EB219B58@kitware.com> <8CC007FF-63D3-43E0-998F-E01C7706DA27@kitware.com> <8D1A06AE-FAFD-4C44-B5D6-A935A286C558@kitware.com> <05F898A4-3C1B-42C9-9DD9-84C3549BF306@kitware.com> <20E54E98-A9A4-4DF4-8819-A7636FA5FBDE@kitware.com> <4E3EDA6D-F497-43B8-88E5-7042EAE43A16@kitware.com> <6A8A7932-997F-4E4B-B846-2DE1B1CF69CD@kitware.com> <1E02FEEE-83A2-4523-88FE-5C91FEB508A3@kitware.com> <6A57F067-C491-41E6-BFFF-F67D63F76AB0@kitware.com> <7F01008B-CD01-4DF2-AD0C-320B8FC77DB5@kitware.com> <278C1819-8F89-4385-AABB-84F2BEBC7AB3@kitware.com> <37FFE363-365B-4EAC-A0E2-714B1DADB4EA@kitware.com> <27BBD790-73F3-4B89-A2F3-BDFC91DEED25@kitware.com> <651081FE-9818-4935-A190-40DEF403C243@kitware.com> <9A878527-ACE1-421E-BDD7-36BC97FA6D9F@kitware.com> Message-ID: It works. :-) I will look into the CGM then. On Tue, Jun 30, 2015 at 3:30 PM, Lin M wrote: > This is a good idea! > > On Tue, Jun 30, 2015 at 3:24 PM, David Thompson < > david.thompson at kitware.com> wrote: > >> Hmmm. I think this would be a good time to use vtkMappedDataArray to >> create a version of the control point coordinates with 3 components that >> divides x, y, and z by the homogeneous coordinate. The vtkStructuredGrid's >> vtkPoints instance would own the vtkMappedDataArray, which would own a >> reference to the 4-component array (also owned by the PointData() of the >> vtkStructuredGrid). >> >> That will make rendering the control polygon easy and let GetDimensions() >> return the correct value. Just make sure that you call SetDimensions() >> before setting the vtkPoints array to be the vtkMappedDataArray. >> >> David >> >> > On Jun 30, 2015, at 3:19 PM, Lin M wrote: >> > >> > Yes, I can store it in PointData(), but >> splineData->GetDimensions(numControlPointsPerAxis) will not return the >> correct number of control points. It will return {0,0,0} if we hold the >> control points in PointData(). Though we can also hold a simple 1*3 array >> in vtkFieldData just like we store the length of knot vectors. >> > >> > On Tue, Jun 30, 2015 at 2:10 PM, David Thompson < >> david.thompson at kitware.com> wrote: >> > Hi Lin, >> > >> > > I didn't separate the homogenous coordinate with point coordinates >> but stored them all in a vtkDataArray with 4 components per tuple just as >> you suggest. In this way, vtkStructuredGrid cannot hold them as vtkPoints. >> The current API is like >> > > >> > > void vtkNURBSPatchAdaptor::GetPatchShape(vtkUnstructuredGrid* >> outputSp, vtkDataArray* ctrlPts, int* ctrlPtsNum) >> > > the outputSp holds the surface mesh, ctrlPts and ctrlPtsNum hold >> information and data of nurbs control points, and the vtkSturcturedGrid >> only holds knot vectors and length. >> > >> > Actually, the vtkStructuredGrid can hold the control points as >> PointData() (as opposed to Point coordinates). There is no constraint on >> the number of components per tuple. The idea is to access the control >> points and knot data like this: >> > >> > vtkStructuredGrid* splineData; >> > vtkDataArray* controlPoints = >> splineData->GetPointData()->GetArrayByName("control polygon"); >> > vtkDataArray* knotVector = >> splineData->GetFieldData()->GetArrayByName("knot vector"); >> > int numControlPointsPerAxis[3]; >> > splineData->GetDimensions(numControlPointsPerAxis); >> > >> > That way all of the spline data is grouped into one dataset; it's just >> that the splineData's vtkPoints would not hold the control points. We could >> also store additional information in the arrays of >> splineData->GetFieldData(). For example, flags indicating which axes (if >> any) were periodic could be stored in a separate field-data array since >> there is no constraint on the number of components or tuples of field-data >> arrays. >> > >> > Does that make sense? >> > >> > David >> > >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.gobbi at gmail.com Tue Jun 30 17:09:46 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 30 Jun 2015 15:09:46 -0600 Subject: [vtk-developers] Nomenclature - "Reference" data set Message-ID: Hi All, I have three filters in VTK that have a method called "SetInformationInput()", but the method name is confusing and I'm seeking advice on how to change it. The method's purpose it to provide a reference image. For example, vtkImageChangeInformation has two inputs: the first image provides the voxel data, and the 2nd input provides a reference image that has the desired voxel spacing and origin. Another example is vtkImageReslice, which can resample its first input by using the spacing & origin of a second input. I looked to see if any geometry filters to see if any of them had a good name for such an input, and I found that vtkProbeFilter and vtkGlyph3D use the name "SetSourceConnection()". That name doesn't sound right for the image filters. So, I'm thinking of renaming vtkImageChangeInformation::SetInformationInputData() as follows, to make its meaning more apparent: SetReferenceData() - accepts a vtkDataObject SetReferenceConnection() - creates a pipeline connection Imaging scientists generally understand what is meant by a "reference" image in this context. The old method (which only accepts data, not a pipeline connection) would be deprecated in VTK 7. Any thoughts? - David -------------- next part -------------- An HTML attachment was scrubbed... URL: From pieper at isomics.com Tue Jun 30 17:22:25 2015 From: pieper at isomics.com (Steve Pieper) Date: Tue, 30 Jun 2015 17:22:25 -0400 Subject: [vtk-developers] Nomenclature - "Reference" data set In-Reply-To: References: Message-ID: +1 for the term "Reference". That's what we use in Slicer for this concept. On Tue, Jun 30, 2015 at 5:09 PM, David Gobbi wrote: > Hi All, > > I have three filters in VTK that have a method called > "SetInformationInput()", but the method name is confusing and I'm seeking > advice on how to change it. > > The method's purpose it to provide a reference image. For example, > vtkImageChangeInformation has two inputs: the first image provides the > voxel data, and the 2nd input provides a reference image that has the > desired voxel spacing and origin. Another example is vtkImageReslice, > which can resample its first input by using the spacing & origin of a > second input. > > I looked to see if any geometry filters to see if any of them had a good > name for such an input, and I found that vtkProbeFilter and vtkGlyph3D use > the name "SetSourceConnection()". That name doesn't sound right for the > image filters. > > So, I'm thinking of renaming > vtkImageChangeInformation::SetInformationInputData() as follows, to make > its meaning more apparent: > > SetReferenceData() - accepts a vtkDataObject > SetReferenceConnection() - creates a pipeline connection > > Imaging scientists generally understand what is meant by a "reference" > image in this context. The old method (which only accepts data, not a > pipeline connection) would be deprecated in VTK 7. > > Any thoughts? > > - 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 bill.lorensen at gmail.com Tue Jun 30 17:26:18 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 30 Jun 2015 17:26:18 -0400 Subject: [vtk-developers] Nomenclature - "Reference" data set In-Reply-To: References: Message-ID: In ITK we use ReferenceImage in the itkChangeInformationImageFilter. On Tue, Jun 30, 2015 at 5:09 PM, David Gobbi wrote: > Hi All, > > I have three filters in VTK that have a method called > "SetInformationInput()", but the method name is confusing and I'm seeking > advice on how to change it. > > The method's purpose it to provide a reference image. For example, > vtkImageChangeInformation has two inputs: the first image provides the voxel > data, and the 2nd input provides a reference image that has the desired > voxel spacing and origin. Another example is vtkImageReslice, which can > resample its first input by using the spacing & origin of a second input. > > I looked to see if any geometry filters to see if any of them had a good > name for such an input, and I found that vtkProbeFilter and vtkGlyph3D use > the name "SetSourceConnection()". That name doesn't sound right for the > image filters. > > So, I'm thinking of renaming > vtkImageChangeInformation::SetInformationInputData() as follows, to make its > meaning more apparent: > > SetReferenceData() - accepts a vtkDataObject > SetReferenceConnection() - creates a pipeline connection > > Imaging scientists generally understand what is meant by a "reference" image > in this context. The old method (which only accepts data, not a pipeline > connection) would be deprecated in VTK 7. > > Any thoughts? > > - 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 bill.lorensen at gmail.com Tue Jun 30 17:29:12 2015 From: bill.lorensen at gmail.com (Bill Lorensen) Date: Tue, 30 Jun 2015 17:29:12 -0400 Subject: [vtk-developers] Nomenclature - "Reference" data set In-Reply-To: References: Message-ID: Since vtkImageChangeInformation deals with images, I think SetReferenceImage is a logical choice. On Tue, Jun 30, 2015 at 5:26 PM, Bill Lorensen wrote: > In ITK we use ReferenceImage in the itkChangeInformationImageFilter. > > On Tue, Jun 30, 2015 at 5:09 PM, David Gobbi wrote: >> Hi All, >> >> I have three filters in VTK that have a method called >> "SetInformationInput()", but the method name is confusing and I'm seeking >> advice on how to change it. >> >> The method's purpose it to provide a reference image. For example, >> vtkImageChangeInformation has two inputs: the first image provides the voxel >> data, and the 2nd input provides a reference image that has the desired >> voxel spacing and origin. Another example is vtkImageReslice, which can >> resample its first input by using the spacing & origin of a second input. >> >> I looked to see if any geometry filters to see if any of them had a good >> name for such an input, and I found that vtkProbeFilter and vtkGlyph3D use >> the name "SetSourceConnection()". That name doesn't sound right for the >> image filters. >> >> So, I'm thinking of renaming >> vtkImageChangeInformation::SetInformationInputData() as follows, to make its >> meaning more apparent: >> >> SetReferenceData() - accepts a vtkDataObject >> SetReferenceConnection() - creates a pipeline connection >> >> Imaging scientists generally understand what is meant by a "reference" image >> in this context. The old method (which only accepts data, not a pipeline >> connection) would be deprecated in VTK 7. >> >> Any thoughts? >> >> - 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 -- Unpaid intern in BillsBasement at noware dot com From david.gobbi at gmail.com Tue Jun 30 18:19:45 2015 From: david.gobbi at gmail.com (David Gobbi) Date: Tue, 30 Jun 2015 16:19:45 -0600 Subject: [vtk-developers] Nomenclature - "Reference" data set In-Reply-To: References: Message-ID: So the VTK method names (in VTK 6 style) would be these: SetReferenceImageConnection() SetReferenceImageData() GetReferenceImage() But, yes, I'm tempted to use SetInputImage() and not use the Data suffix. - David On Tue, Jun 30, 2015 at 3:29 PM, Bill Lorensen wrote: > Since vtkImageChangeInformation deals with images, I think > SetReferenceImage is a logical choice. > > > On Tue, Jun 30, 2015 at 5:26 PM, Bill Lorensen > wrote: > > In ITK we use ReferenceImage in the itkChangeInformationImageFilter. > > > > On Tue, Jun 30, 2015 at 5:09 PM, David Gobbi > wrote: > >> Hi All, > >> > >> I have three filters in VTK that have a method called > >> "SetInformationInput()", but the method name is confusing and I'm > seeking > >> advice on how to change it. > >> > >> The method's purpose it to provide a reference image. For example, > >> vtkImageChangeInformation has two inputs: the first image provides the > voxel > >> data, and the 2nd input provides a reference image that has the desired > >> voxel spacing and origin. Another example is vtkImageReslice, which can > >> resample its first input by using the spacing & origin of a second > input. > >> > >> I looked to see if any geometry filters to see if any of them had a good > >> name for such an input, and I found that vtkProbeFilter and vtkGlyph3D > use > >> the name "SetSourceConnection()". That name doesn't sound right for the > >> image filters. > >> > >> So, I'm thinking of renaming > >> vtkImageChangeInformation::SetInformationInputData() as follows, to > make its > >> meaning more apparent: > >> > >> SetReferenceData() - accepts a vtkDataObject > >> SetReferenceConnection() - creates a pipeline connection > >> > >> Imaging scientists generally understand what is meant by a "reference" > image > >> in this context. The old method (which only accepts data, not a > pipeline > >> connection) would be deprecated in VTK 7. > >> > >> Any thoughts? > >> > >> - 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 > > > > -- > Unpaid intern in BillsBasement at noware dot com > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joaorobertojr88 at gmail.com Tue Jun 30 18:39:41 2015 From: joaorobertojr88 at gmail.com (joaoroberto88) Date: Tue, 30 Jun 2015 15:39:41 -0700 (MST) Subject: [vtk-developers] Which is the official VTK bug tracker? Message-ID: <1435703981458-5732635.post@n5.nabble.com> Sorry for the short question, I'll remove this post when I get a answer. Is it http://www.vtk.org/Bug? Thanks, Joao. -- View this message in context: http://vtk.1045678.n5.nabble.com/Which-is-the-official-VTK-bug-tracker-tp5732635.html Sent from the VTK - Dev mailing list archive at Nabble.com. From cory.quammen at kitware.com Tue Jun 30 19:00:55 2015 From: cory.quammen at kitware.com (Cory Quammen) Date: Tue, 30 Jun 2015 19:00:55 -0400 Subject: [vtk-developers] Which is the official VTK bug tracker? In-Reply-To: <1435703981458-5732635.post@n5.nabble.com> References: <1435703981458-5732635.post@n5.nabble.com> Message-ID: Yes, that's right. - Cory On Tue, Jun 30, 2015 at 6:39 PM, joaoroberto88 wrote: > Sorry for the short question, I'll remove this post when I get a answer. Is > it http://www.vtk.org/Bug? > > Thanks, > > Joao. > > > > -- > View this message in context: > http://vtk.1045678.n5.nabble.com/Which-is-the-official-VTK-bug-tracker-tp5732635.html > Sent from the VTK - Dev mailing list archive at Nabble.com. > _______________________________________________ > Powered by www.kitware.com > > Visit other Kitware open-source projects at > http://www.kitware.com/opensource/opensource.html > > Search the list archives at: http://markmail.org/search/?q=vtk-developers > > Follow this link to subscribe/unsubscribe: > http://public.kitware.com/mailman/listinfo/vtk-developers > > -- Cory Quammen R&D Engineer Kitware, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joaorobertojr88 at gmail.com Tue Jun 30 19:02:54 2015 From: joaorobertojr88 at gmail.com (joaoroberto88) Date: Tue, 30 Jun 2015 16:02:54 -0700 (MST) Subject: [vtk-developers] Which is the official VTK bug tracker? In-Reply-To: References: <1435703981458-5732635.post@n5.nabble.com> Message-ID: <1435705374822-5732637.post@n5.nabble.com> Thanks! -- View this message in context: http://vtk.1045678.n5.nabble.com/Which-is-the-official-VTK-bug-tracker-tp5732635p5732637.html Sent from the VTK - Dev mailing list archive at Nabble.com. From andrew.amaclean at gmail.com Tue Jun 30 20:23:10 2015 From: andrew.amaclean at gmail.com (Andrew Maclean) Date: Wed, 1 Jul 2015 10:23:10 +1000 Subject: [vtk-developers] [vtkusers] VTK Roadmap Message-ID: David, Berk, That's good news about Python3. Let me know what I can do to help with Python 3 when the time comes. I think there will need to be some minor changes to the tests to make them work Ok in python 3.x/2.7. David, aside from the wrapping are you also looking at the FindPythonLibs.cmake and FindPythonModules.cmake? For instance if Anaconda Python is installed in a user's directory in Windows then VTK requires the user to manually set PYTHON_INCLUDE_DIR and PYTHON_LIBRARY. This does not seem to be the case with the CMake versions. All the Tcl tests that are currently running (except for Tcl specific ones) have now been converted to Python. So we are in a good position there. Regards Andrew. ---------- Forwarded message ---------- > From: Berk Geveci > To: David Gobbi > Cc: VTK Developers , VTK Users > Date: Tue, 30 Jun 2015 16:24:17 -0400 > Subject: Re: [vtk-developers] [vtkusers] VTK Roadmap > Yup. Python 3 is now on the roadmap. Probably the first release after 7, > in a few months. > > -berk > > On Tue, Jun 30, 2015 at 3:48 PM, David Gobbi > wrote: > >> On Tue, Jun 30, 2015 at 12:47 PM, Matthew Brett >> wrote: >> >>> Hi, >>> >>> On Tue, Jun 30, 2015 at 10:58 AM, Berk Geveci >>> wrote: >>> > Hi folks, >>> > >>> > As Dave DeMarle mentioned, we are gearing towards a VTK 6.3 release. >>> VTK 7 >>> > will follow very shortly (in weeks). I'd like to shed some light here >>> on our >>> > thinking and how we are planning to move forward. >>> > >>> > As was previously discussed in the VTK developers list [1] [2], we are >>> > considering maintaining VTK 6.x for a long time (3-5 years) while >>> moving >>> > forward with VTK 7 and 8 in 2015 and 2016. There are some major changes >>> > happening in the computing and C++ worlds and we would like evolve VTK >>> more >>> > quickly to stay up to date. Some of the major changes that we are >>> > considering and/or working on are: >>> > >>> > * Major refactoring of rendering (OpenGL as well as ray tracing etc.) >>> > * Multi/many-core support / SMP computing on CPUs and accelerators. >>> VTK-m >>> > integration [3]. >>> > * Changes to data model to support zero copy interface to other data >>> > layouts, more efficient APIs, more cell types, more dataset types etc. >>> > * Better separation of a public, wrapped API and toolkit/C++ internal >>> API >>> > mainly to support efficiency >>> > * Introduction of C++ 11 features >>> > >>> > Much of this will require introducing changes that break backwards >>> > compatibility and also require newer compilers, graphics cards / >>> drivers >>> > etc. So the idea is that we will do our best to support as much as >>> possible >>> > a broad set of architectures and backwards compatibility but break >>> things >>> > when necessary in VTK 7 and beyond. We will maintain VTK 6.x so that >>> folks >>> > that are stuck on legacy systems or code bases can continue to benefit >>> from >>> > bug fixes. We have a way of continuing to maintain a broad set of >>> dashboards >>> > and also the same review process as VTK master so that we can continue >>> to >>> > ensure the quality of VTK 6.x as well as new releases. >>> > >>> > What do you guys think? Please provide feedback so that we can adjust >>> our >>> > plans to meet the needs of the community as much as possible. >>> >>> I would like to put in a humble plea to add Python 3 compatibility to >>> that list: >>> >>> http://astrofrog.github.io/blog/2015/05/09/2015-survey-results >> >> >> Python 3 is being worked on (right now by me, and others can join in a >> couple weeks once the core pieces are in place). No, it won't be part of >> 6.3, however. >> >> - David >> >> _______________________________________________ >> > -- ___________________________________________ Andrew J. P. Maclean ___________________________________________ -------------- next part -------------- An HTML attachment was scrubbed... URL: