[Ves] VTK pipelines in VES

[Matthias Baitsch]

Dear Ashish,

attached a zipped Xcode workspace with three projects:

- mVES -- c++ and objective c code for building VES/VTK apps on iOS.

- SimpleVES2 -- Sample storyboard app showing one cube, the code setting up the pipeline is in ViewController.mm. 

- HelloVES -- A slightly more complex demo/testing app.

Both demos are based on GLKViewController which is probably not the most efficient way but worked fine for us. 

All projects are configured with one .xcconfig file in the workspace folder, modify the path to VES as needed.

We would be happy to contribute the code to VES if useful.

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 --------------
A non-text attachment was scrubbed...
Name: mves.zip
Type: application/zip
Size: 220274 bytes
Desc: not available
URL: <http://public.kitware.com/pipermail/ves/attachments/20130916/6af3b622/attachment-0003.zip>
-------------- next part --------------