[Ves] VTK pipelines in VES

Aashish Chaudhary aashish.chaudhary at kitware.com
Thu Sep 12 08:42:51 EDT 2013


Hi Matthias


On Thu, Sep 12, 2013 at 3:31 AM, Matthias Baitsch <
matthias.baitsch at uni-kassel.de> wrote:

> Hi Pat,
>
> thanks a lot for your email and clarification. I agree, for large datasets
> it makes sense not to block the rendering thread.
>
> In our app, we decided to do pipeline processing in the rendering thread
> (VTK with Java does the same) mostly for the sake of simplicity: Avoid the
> problems associated with concurrent access to data. And since our models
> are rather small (10k - 20k polygons typically) we get a sufficient
> framerate during user interactions (like moving a part of the model) when
> processing data synchronously.
>
> One possible advantage of a multi-threaded approach could be the
> possibility to coalesce multiple interactive modifications, but I am not
> really clear about that yet.
>
> In order to integrate VES and VTK, we wrote some bridging classes which
> are in a small project of its own. It works fine except for a problem
> with boundsDirty in our vesMapper subclass. Please let me know if we can
> contribute something.
>

It would be great if you can share some of this new functionality to VES.
We will make sure that we provide proper credit to your team for the work.
Would it be possible for us to look at your code somewhere? Also would you
be willing to provide it under VES license?

Thanks,


>
> Best,
>
> Matthias
>
>
>
>
> I just wanted to point out one consideration...  many VES based mobile
> apps use multiple threads, and it can be important to separate data
> processing from the rendering thread. In that case, it might be better to
> explicitly update & convert data arrays instead of doing so automatically
> at render time.  That way, you don't have the rendering thread accessing
> data objects at the same time as data processing tasks, and you can ensure
> the render thread will never block while waiting for a data update.
>
> KiwiViewer for iOS does rendering on the main UI thread, and all data
> processing is done on separate threads via grand central dispatch.  On
> Android, rendering is performed on a dedicated thread, and data processing
> is performed using AsyncTask objects.  The data processing tasks convert
> the vtkPolyData to vesGeometryData, then the rendering thread swaps in the
> newest vesGeometryData.
>
> Of course, every app is different, so for some apps there might be no
> issues at all with accessing VTK data objects at render timer.  I agree, it
> is convenient to have the ability to automatically update the ves data from
> the vtkPolyData, it would be a nice feature to have in VES or Kiwi, with
> the ability to switch it off.  I think, with the current library
> organization, the feature would have to exist in the kiwi library, since
> libves has no dependency on VTK.
>
> Pat
>
>
> ---
> Vertr.-Prof. Dr.-Ing. Matthias Baitsch
>
> Universität Kassel
> FB 14 – FG Baustatik
> Raum 2512
> Mönchebergstr. 7
> D-34125 Kassel
>
> Tel: +49 561 804 3475
>
>
>
>
>
> _______________________________________________
> Ves mailing list
> Ves at public.kitware.com
> http://public.kitware.com/cgi-bin/mailman/listinfo/ves
>
>


-- 
| Aashish Chaudhary
| R&D Engineer
| Kitware Inc.
| www.kitware.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ves/attachments/20130912/2a94b0f8/attachment-0001.html>


More information about the Ves mailing list