<div dir="ltr"><div class="gmail_extra">Hi Matthias</div><div><br><br><div class="gmail_quote">On Thu, Sep 12, 2013 at 3:31 AM, Matthias Baitsch <span dir="ltr"><<a href="mailto:matthias.baitsch@uni-kassel.de" target="_blank">matthias.baitsch@uni-kassel.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">Hi Pat,<div><br></div><div>
thanks a lot for your email and clarification. I agree, for large datasets it makes sense not to block the rendering thread. </div><div><br></div><div>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. </div>
<div><br></div><div><div>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.</div></div><div><br></div><div>
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.</div>
</div></blockquote><div><br></div><div style>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? </div>
<div style><br></div><div style>Thanks, </div><div style> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word"><div><br></div><div>Best,</div><div><br></div><div>Matthias</div><div><br></div><div><br></div><div><br></div><div><br></div><div><div><div class="h5"><div><blockquote type="cite"><div dir="ltr">
<div><div>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.<br>
<br></div><div>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.<br>
</div><div><br></div>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.<br>
<br></div>Pat<br></div>
</blockquote></div><br></div></div><div class="im"><div>
<span style="border-collapse:separate;border-spacing:0px"><div style="word-wrap:break-word"><span style="border-spacing:0px;text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div style="word-wrap:break-word">
<span style="border-spacing:0px;text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div style="word-wrap:break-word">
<span style="border-spacing:0px;text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:-webkit-auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div style="word-wrap:break-word">
---<br>Vertr.-Prof. Dr.-Ing. Matthias Baitsch<br><br></div><div style="word-wrap:break-word">Universität Kassel <br>FB 14 – FG Baustatik</div><div style="word-wrap:break-word">Raum 2512<br>Mönchebergstr. 7<br>D-34125 Kassel</div>
<div style="word-wrap:break-word"><br>Tel: <a href="tel:%2B49%20561%20804%203475" value="+495618043475" target="_blank">+49 561 804 3475</a><br><br><br><br></div></span></div></span></div></span></div></span>
</div>
<br></div></div></div><br>_______________________________________________<br>
Ves mailing list<br>
<a href="mailto:Ves@public.kitware.com">Ves@public.kitware.com</a><br>
<a href="http://public.kitware.com/cgi-bin/mailman/listinfo/ves" target="_blank">http://public.kitware.com/cgi-bin/mailman/listinfo/ves</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>| Aashish Chaudhary <br>| R&D Engineer <br>| Kitware Inc. <br>| <a href="http://www.kitware.com">www.kitware.com</a>
</div></div>