[vtkusers] [vtk-developers] VTK Roadmap

Wed Jul 1 23:49:35 EDT 2015

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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/vtkusers/attachments/20150701/97798fff/attachment.html>