<div dir="ltr">I agree with David. This is currently the best path for scene graph style use, especially combined with the OpenGL2 backend. This will be available in VTK 6.3 and VTK 7 but continues to evolve. So please let us know if you run into issues, performance or otherwise.<div><br></div><div>We also discussed developing a full-featured scene graph actor but it was not a high priority. VTK's major use cases center around a few large geometry objects or a large number of small objects that have related properties coming from a point/cell array (molecules, tensors etc.) However, we will continue to add more scene graph style capabilities to multi-block rendering. Probably including transform support per block, inheritance of properties from an upper node etc.</div><div><br></div><div>Best,</div><div>-berk</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jul 2, 2015 at 9:01 AM, David Thompson <span dir="ltr"><<a href="mailto:david.thompson@kitware.com" target="_blank">david.thompson@kitware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Alex,<br>
<br>
I think there is a third option that would be much more usable; generating a multiblock dataset that uses a single actor and mapper, but in which each block can be independently replaced with an edited version. As long as the source only regenerates a small number of leaf nodes, this would not have a large impact on memory, rendering, or picking performance.<br>
<span class="HOEnZb"><font color="#888888"><br>
        David<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Jul 1, 2015, at 11:49 PM, Alex Malyushytskyy <<a href="mailto:alexmalvtk@gmail.com">alexmalvtk@gmail.com</a>> wrote:<br>
<br>
> As a user I think VTK during last 2 major releases acquired performance issues which makes it very difficult if not impossible to use for my needs as a developer of CAD type applications.<br>
><br>
> Let me explain. Typical CAD application functionality can be demonstrated on the building model.<br>
> Building consists of a few type of structural components: columns, beams, slabs and walls.<br>
> Geometry of such component is defined by different attributes. For column for example it might be section shape, cross-section dimension, etc.<br>
> User of the CAD system should be able to select/pick components on the screen, change such component attributes and should see geometry change on the screen fast enough.<br>
><br>
> Lets say we want to create 60 story building with 100 rooms per floor.<br>
> This gives us 6000 components or about 50k rectangular cells.<br>
><br>
> With vtk developer basically has 2 choices of the implementation:<br>
> 1) minimize number of actors.  Lets say actor for whole building. In such case every component geometry is appended to the building polydata. So finally you have only 1 dataset, 1 mapper and 1 actor.<br>
> 2) create actor per component. In this case you have 1 dataset, 1 mapper and 1 actor per component.<br>
><br>
> Unfortunately neither approach works well for CAD application when model has to be editable by user. At least not with VTK 6.0.1.<br>
><br>
> Comparison of usage cases:<br>
><br>
> - when you need to re-generate whole model geometry (for example file withy model description loaded).<br>
> Approach 1 demonstrates  better performance even though it requires additional append filter execution.<br>
> Approach 2 is slow -  from 6 to 10 times slower. For a building described above it would be 7-8 sec for Approach 1 and 30-40 sec for approach 2 on my system.<br>
><br>
> - when you need to modify a single component and update presentation.<br>
><br>
> Approach 1 takes basically the same time as regenerate model from the scratch.<br>
> It takes basically the same time as regenerate model from the scratch.<br>
> But 7 sec are not acceptable anymore.<br>
> Modification of the dataset itself takes no time. All time is taken by vtk pipeline.<br>
> So basically there is no way for improvement.<br>
><br>
> - picking/selection components.<br>
> Approach 1 is slow. Keep in mind that user have to select components, not cells.<br>
> So in this case you have to add to cell field which would allow to keep track which component picked cells belong to.  Then selection is equivalent of adding data field to polydata and after picking setting value to such field for all cells which belong to that component.<br>
> This is definitely slower than for Approach 2. When all you need to keep tracking and select appropriate actor .<br>
><br>
><br>
> Approach 2 is very fast(less than second).<br>
> User would might be able to survive slow initial model loading,<br>
> if there were not any other differences.<br>
><br>
> Unfortunately when you look at the application  memory usage such model when approach 2 is used will take over 1.5 GB of memory when in case of approach 1 just about 140k.<br>
> That is for single view. You would not be able to display such model in 2 views on 32 bit Windows.<br>
><br>
><br>
> That is counting that you static mode and ImmediateModeRenderingOn were set for mapper,<br>
> and no intermediate filters are stored ( vtkPolydata -> Mapper -> actor pipeline is used).<br>
><br>
> With number of components increasing memory usage and time grow.<br>
> So basically described above model is about as big editable model as VTK can handle without user breaking monitor after 30 min of work.<br>
><br>
> For comparison I was using hoops3d (1998-2000) for developing of 3D FEM pre-, post-processing application with similar capabilities. 15 years ago on the appropriate systems I've seen better performance. Also I believe that 10 years ago VTK did not require such memory to display such size of data with exactly the same pipeline.<br>
> I blame changes in vtk 5 and 6.<br>
><br>
> As a conclusion I afraid vtk 6 is not useable if you have to deal with dynamic changeable systems of average size on a single computer.<br>
><br>
> I wish that was targeted. If not in vtk 6, may be in vtk7.<br>
><br>
><br>
> On Tue, Jun 30, 2015 at 1:24 PM, Berk Geveci <<a href="mailto:berk.geveci@kitware.com">berk.geveci@kitware.com</a>> wrote:<br>
> Yup. Python 3 is now on the roadmap. Probably the first release after 7,  in a few months.<br>
><br>
> -berk<br>
><br>
> On Tue, Jun 30, 2015 at 3:48 PM, David Gobbi <<a href="mailto:david.gobbi@gmail.com">david.gobbi@gmail.com</a>> wrote:<br>
> On Tue, Jun 30, 2015 at 12:47 PM, Matthew Brett <<a href="mailto:matthew.brett@gmail.com">matthew.brett@gmail.com</a>> wrote:<br>
> Hi,<br>
><br>
> On Tue, Jun 30, 2015 at 10:58 AM, Berk Geveci <<a href="mailto:berk.geveci@kitware.com">berk.geveci@kitware.com</a>> wrote:<br>
> > Hi folks,<br>
> ><br>
> > As Dave DeMarle mentioned, we are gearing towards a VTK 6.3 release. VTK 7<br>
> > will follow very shortly (in weeks). I'd like to shed some light here on our<br>
> > thinking and how we are planning to move forward.<br>
> ><br>
> > As was previously discussed in the VTK developers list [1] [2], we are<br>
> > considering maintaining VTK 6.x for a long time (3-5 years) while moving<br>
> > forward with VTK 7 and 8 in 2015 and 2016. There are some major changes<br>
> > happening in the computing and C++ worlds and we would like evolve VTK more<br>
> > quickly to stay up to date. Some of the major changes that we are<br>
> > considering and/or working on are:<br>
> ><br>
> > * Major refactoring of rendering (OpenGL as well as ray tracing etc.)<br>
> > * Multi/many-core support / SMP computing on CPUs and accelerators. VTK-m<br>
> > integration [3].<br>
> > * Changes to data model to support zero copy interface to other data<br>
> > layouts, more efficient APIs, more cell types, more dataset types etc.<br>
> > * Better separation of a public, wrapped API and toolkit/C++ internal API<br>
> > mainly to support efficiency<br>
> > * Introduction of C++ 11 features<br>
> ><br>
> > Much of this will require introducing changes that break backwards<br>
> > compatibility and also require newer compilers, graphics cards / drivers<br>
> > etc. So the idea is that we will do our best to support as much as possible<br>
> > a broad set of architectures and backwards compatibility but break things<br>
> > when necessary in VTK 7 and beyond. We will maintain VTK 6.x so that folks<br>
> > that are stuck on legacy systems or code bases can continue to benefit from<br>
> > bug fixes. We have a way of continuing to maintain a broad set of dashboards<br>
> > and also the same review process as VTK master so that we can continue to<br>
> > ensure the quality of VTK 6.x as well as new releases.<br>
> ><br>
> > What do you guys think? Please provide feedback so that we can adjust our<br>
> > plans to meet the needs of the community as much as possible.<br>
><br>
> I would like to put in a humble plea to add Python 3 compatibility to that list:<br>
><br>
> <a href="http://astrofrog.github.io/blog/2015/05/09/2015-survey-results" rel="noreferrer" target="_blank">http://astrofrog.github.io/blog/2015/05/09/2015-survey-results</a><br>
><br>
> 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.<br>
><br>
>  - David<br>
><br>
> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Please keep messages on-topic and check the VTK FAQ at: <a href="http://www.vtk.org/Wiki/VTK_FAQ" rel="noreferrer" target="_blank">http://www.vtk.org/Wiki/VTK_FAQ</a><br>
><br>
> Search the list archives at: <a href="http://markmail.org/search/?q=vtkusers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtkusers</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://public.kitware.com/mailman/listinfo/vtkusers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtkusers</a><br>
><br>
><br>
> _______________________________________________<br>
> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
><br>
> Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
><br>
> Please keep messages on-topic and check the VTK FAQ at: <a href="http://www.vtk.org/Wiki/VTK_FAQ" rel="noreferrer" target="_blank">http://www.vtk.org/Wiki/VTK_FAQ</a><br>
><br>
> Search the list archives at: <a href="http://markmail.org/search/?q=vtkusers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtkusers</a><br>
><br>
> Follow this link to subscribe/unsubscribe:<br>
> <a href="http://public.kitware.com/mailman/listinfo/vtkusers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtkusers</a><br>
<br>
_______________________________________________<br>
Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
<br>
Visit other Kitware open-source projects at <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
<br>
Please keep messages on-topic and check the VTK FAQ at: <a href="http://www.vtk.org/Wiki/VTK_FAQ" rel="noreferrer" target="_blank">http://www.vtk.org/Wiki/VTK_FAQ</a><br>
<br>
Search the list archives at: <a href="http://markmail.org/search/?q=vtkusers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtkusers</a><br>
<br>
Follow this link to subscribe/unsubscribe:<br>
<a href="http://public.kitware.com/mailman/listinfo/vtkusers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtkusers</a><br>
</div></div></blockquote></div><br></div>