[vtkusers] [vtk-developers] VTK Roadmap

Thu Jul 9 01:47:40 EDT 2015

Thanks David, Berk and Ken for suggestions!

vtkMultiBlockDataSet with vtkPolyData as blocks did produce the best
performing results.

Usage of vtkCompositePolyDataMapper2  gives more flexibility - no need to
remove and re-add polydata in/out multiblock dataset which simplified my
code greatly if you want to hide/show blocks , ability to color and set
transparency (have not used yet) for each block is very useful.

On top it seems fixes (might be only partially) behavior of
vtkHardwareSelector. At least now it returns selection which I can track
back to block. Why partially? Cause even I am sure I am selecting a single
block area selection produces extra blocks. Interesting that if window is
defined as a point (x1=x2, y1=y2) only correct result is produced.
This may be either vtkHardwareSelector or
vtkConvertSelection::ToSelectionType  which I use to convert selection to
vtkSelectionNode::BLOCKS.
Mostly likely in vtkHardwareSelector cause selection it produces has too
many Cell ids (checked with Dump).
But at this moment I have not found an easy way to verify where exactly, so
it will be probably a subject of another post tomorrow.

Thanks again for suggestions!

   Alex

On Wed, Jul 8, 2015 at 2:19 PM, Ken Martin <ken.martin at kitware.com> wrote:

> Hello Alex,
>
>
>
> Your use case is definitely one that I would like to see work well in the
> current VTK with the new OpenGL2 backend. Currently the right mapper for
> this type of work is something called vtkCompositePolyDataMapper2  taking a
> composite dataset as input (See
> Rendering/Core/Testing/Cxx/TestCompositePolyDataMapper2.cxx for an
> example)  Your use case may still run into performance issues as I have not
> tested changing just one part of a composite dataset, but if it does run
> into performance issues let me know as I do want that use case to work well
> and it really should :-)
>
>
>
> 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 *Berk Geveci
> *Sent:* Thursday, July 2, 2015 9:21 AM
> *To:* David Thompson
> *Cc:* Alex Malyushytskyy; VTK Developers; VTK Users
> *Subject:* Re: [vtk-developers] [vtkusers] VTK Roadmap
>
>
>
> 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/20150708/67b16bc1/attachment.html>