[Ves] VTK pipelines in VES

[Aashish Chaudhary]

Cool!.. I will give it a try today / tomorrow. Just to be sure, what
version of VES did you use on your side?

Thanks a bunch.

- Aashish


On Mon, Sep 16, 2013 at 9:19 AM, Matthias Baitsch <
matthias.baitsch at uni-kassel.de> wrote:

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


-- 
| 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/20130916/e1d7b57f/attachment-0001.html>