[Ves] VTK pipelines in VES

[Matthias Baitsch]

Hi Aashish,

after some code cleanup, I will send you two Xcode projects (bridging/utilities and one example project).

Best, 

Matthias



On Sep 12, 2013, at 2:42 PM, Aashish Chaudhary <aashish.chaudhary at kitware.com> wrote:

> 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   

---
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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://public.kitware.com/pipermail/ves/attachments/20130913/1c01955b/attachment-0002.html>