[vtkusers] [vtk-developers] VTK Roadmap

Thu Jul 2 09:20:44 EDT 2015

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.

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.

Best,
-berk

On Thu, Jul 2, 2015 at 9:01 AM, David Thompson <david.thompson at kitware.com>
wrote:

> Hi Alex,
>
> 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.
>
>         David
>
> On Jul 1, 2015, at 11:49 PM, Alex Malyushytskyy <alexmalvtk at gmail.com>
> wrote:
>
> > 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.
> >
> > Let me explain. Typical CAD application functionality can be
> demonstrated on the building model.
> > Building consists of a few type of structural components: columns,
> beams, slabs and walls.
> > Geometry of such component is defined by different attributes. For
> column for example it might be section shape, cross-section dimension, etc.
> > 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.
> >
> > Lets say we want to create 60 story building with 100 rooms per floor.
> > This gives us 6000 components or about 50k rectangular cells.
> >
> > With vtk developer basically has 2 choices of the implementation:
> > 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.
> > 2) create actor per component. In this case you have 1 dataset, 1 mapper
> and 1 actor per component.
> >
> > Unfortunately neither approach works well for CAD application when model
> has to be editable by user. At least not with VTK 6.0.1.
> >
> > Comparison of usage cases:
> >
> > - when you need to re-generate whole model geometry (for example file
> withy model description loaded).
> > Approach 1 demonstrates  better performance even though it requires
> additional append filter execution.
> > 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.
> >
> > - when you need to modify a single component and update presentation.
> >
> > Approach 1 takes basically the same time as regenerate model from the
> scratch.
> > It takes basically the same time as regenerate model from the scratch.
> > But 7 sec are not acceptable anymore.
> > Modification of the dataset itself takes no time. All time is taken by
> vtk pipeline.
> > So basically there is no way for improvement.
> >
> > - picking/selection components.
> > Approach 1 is slow. Keep in mind that user have to select components,
> not cells.
> > 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.
> > This is definitely slower than for Approach 2. When all you need to keep
> tracking and select appropriate actor .
> >
> >
> > Approach 2 is very fast(less than second).
> > User would might be able to survive slow initial model loading,
> > if there were not any other differences.
> >
> > 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.
> > That is for single view. You would not be able to display such model in
> 2 views on 32 bit Windows.
> >
> >
> > That is counting that you static mode and ImmediateModeRenderingOn were
> set for mapper,
> > and no intermediate filters are stored ( vtkPolydata -> Mapper -> actor
> pipeline is used).
> >
> > With number of components increasing memory usage and time grow.
> > So basically described above model is about as big editable model as VTK
> can handle without user breaking monitor after 30 min of work.
> >
> > 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.
> > I blame changes in vtk 5 and 6.
> >
> > 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.
> >
> > I wish that was targeted. If not in vtk 6, may be in vtk7.
> >
> >
> > On Tue, Jun 30, 2015 at 1:24 PM, Berk Geveci <berk.geveci at kitware.com>
> wrote:
> > 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 <david.gobbi at gmail.com>
> wrote:
> > On Tue, Jun 30, 2015 at 12:47 PM, Matthew Brett <matthew.brett at gmail.com>
> wrote:
> > Hi,
> >
> > On Tue, Jun 30, 2015 at 10:58 AM, Berk Geveci <berk.geveci at kitware.com>
> 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
> >
> >
> >
> >
> > _______________________________________________
> > 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
>
> 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: <http://public.kitware.com/pipermail/vtkusers/attachments/20150702/a15f5fa5/attachment.html>