Hi Chris,<div><br></div><div>Sorry for the confusion, yes I am doing what you describe. The difference may be that perhaps your app has only one viewport. In my case there are a number of different viewports (aka vtkRenderWindow) each has its own qml item and is each rendering on it's own thread. Plus the qml composition thread which is managed by Qt.</div><div><br></div><div>I was just making the point that this architecture let's you draw different viewports in parallel provided that each one has its own mappers and actors.</div><div><br></div><div>G</div><div><br><br><div class="gmail_quote"><div dir="ltr">On Tue, May 16, 2017, 4:13 PM <<a href="mailto:c.sell@byterefinery.de">c.sell@byterefinery.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Geoff,<br>
<br>
as I understand it, the blog post you linked to doesn't mention<br>
multiple threads beyond the QML UI thread and the scenegraph render<br>
thread.<br>
<br>
So far, I am using that approach with QQuickFrameBufferObject as<br>
starting point and vtkExternalOpenGLRenderWindow for the VTK side,<br>
which causes VTK to use QML's OpenGL context and thus render into the<br>
FBO maintained by QQuickFrameBufferObject. That seems to work<br>
flawlessly, as long as ALL rendering is kept on the scenegraph thread,<br>
which is not always obvious to do at first, because VTK's API's don't<br>
separate between reading event values and rendering them (e.g.,<br>
SetSlice(2) will internally set the current slice and then do a<br>
Render()).<br>
<br>
But why maintain more threads?<br>
<br>
Anyway, please go ahead and explain your approach as detailed as<br>
possible, I am all ears.<br>
<br>
regards,<br>
Chris<br>
<br>
Zitat von Geoff Wright <<a href="mailto:gpwright@gmail.com" target="_blank">gpwright@gmail.com</a>>:<br>
<br>
> Hi guys,<br>
><br>
> I would argue that for qml integration the best approach is for each vtk<br>
> viewport to render into a texture on a dedicated thread, not the qml<br>
> rendering thread. Qml then draws the resulting texture which is more in<br>
> line with the Qt design intention ( see<br>
> <a href="http://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/" rel="noreferrer" target="_blank">http://blog.qt.io/blog/2015/05/11/integrating-custom-opengl-rendering-with-qt-quick-via-qquickframebufferobject/</a><br>
> )<br>
><br>
> I have been using this approach for a couple of years in a high performance<br>
> real time application. The code is unfortunately proprietary but very<br>
> happy to explain more about the approach. It would be great to add support<br>
> for this to VTK.<br>
><br>
> For the interactor part I do what Sankesh said, defer the events and apply<br>
> them on the render thread of the particular vtk item.<br>
><br>
> Regards,<br>
><br>
> G<br>
><br>
><br>
><br>
> On Tue, May 16, 2017, 3:06 PM Sankhesh Jhaveri <<a href="mailto:sankhesh.jhaveri@kitware.com" target="_blank">sankhesh.jhaveri@kitware.com</a>><br>
> wrote:<br>
><br>
>> Hi Christian,<br>
>><br>
>> Doing all VTK rendering on the QML render thread is the right thing to do.<br>
>> As far as interaction is concerned, make sure that Qt events are queued on<br>
>> the main thread and processed when execution reaches the render thread.<br>
>><br>
>> I have done some work on VTK and QtQuick integration that I’m planning to<br>
>> add to a VTK remote module. That way, it will be available as part of VTK.<br>
>><br>
>> Thanks,<br>
>> Sankhesh<br>
>> <br>
>><br>
>> On Tue, May 16, 2017 at 4:57 AM <<a href="mailto:c.sell@byterefinery.de" target="_blank">c.sell@byterefinery.de</a>> wrote:<br>
>><br>
>>> just for the record (nobody care about this subject?):<br>
>>><br>
>>> I found that contrary to what I said I had NOT adhered to the<br>
>>> principle established with protoype 1 while implementing protoype 2.<br>
>>> Rather, I had directly called into the VTK interactor from the QML UI<br>
>>> thread. And because the VTK interactors immediately go into rendering,<br>
>>> all hell broke loose.<br>
>>><br>
>>> After cleaning up example 2 according to the rule laid out earlier<br>
>>> ("store event data in RenderDelegate, call update() on the QML item,<br>
>>> pass the event to VTK inside RenderDelgate.Render()", all works well.<br>
>>><br>
>>> What I would like to do is validate the solution against findings made<br>
>>> elsewhere, and then establish the "canonical" way of integrating VTK<br>
>>> with QML. As I said, there are some architectural quirks with the<br>
>>> solution which I would also like to address.<br>
>>><br>
>>> regards,<br>
>>> Christian<br>
>>><br>
>>><br>
>>> Zitat von <a href="mailto:c.sell@byterefinery.de" target="_blank">c.sell@byterefinery.de</a>:<br>
>>><br>
>>> > Hello all,<br>
>>> ><br>
>>> > I am looking into the possibility of replacing the 3D rendering<br>
>>> > engine in my Qt5 / QML based mobile tablet-oriented application with<br>
>>> > VTK. What I need is a first class QtQuick integration (not a hack or<br>
>>> > workaround) that is 100% stable in every context (not an unusual<br>
>>> > requirement, I admit). To my amazement, nothing of that kind seems<br>
>>> > to exist (correct me if I'm wrong).<br>
>>> ><br>
>>> > I went on to investigate what had been done so far and to implement<br>
>>> > my first prototypes, using the QQuickFrameBufferObject approach.<br>
>>> > From the very start this felt like an uphill battle, because VTK<br>
>>> > seems to come from a Windowing background and is quite tightly<br>
>>> > integrated with concepts that are not valid in a QML context.<br>
>>> ><br>
>>> > I'll describe my findings together with the 2 prototypical QML items<br>
>>> > I implemented:<br>
>>> ><br>
>>> > 1st was an adaptation of the DICOM example which now runs as a QML<br>
>>> > item. All user interaction is handled by QML and forwarded to VTK<br>
>>> > (which is one thing that doesn't come naturally with VTK), and after<br>
>>> > some non-elegant tweaking I was able to have the UI move from slice<br>
>>> > to slice and re-render upon mouse wheel events as expected. The<br>
>>> > problem here was, that QML insists on keeping mouse event handling<br>
>>> > and OpenGL rendering on separate threads, with one "rendering<br>
>>> > thread" dedicated to OpenGL. However, the pre-existing VTK<br>
>>> > Interactors directly call Render() after reconfiguring the UI from<br>
>>> > the mouse event data, which is an absolute QML No-Go. I had to<br>
>>> > introduce a RenderDelegate that works somewhat like this:<br>
>>> ><br>
>>> > QML mouse event:<br>
>>> > tell RenderDelegate about the event<br>
>>> > call update() on the QML item, which triggers rer-endering on<br>
>>> > the dedicated thread<br>
>>> > on the QML rendering thread:<br>
>>> > call Render() on the RenderWindow<br>
>>> > inside the RenderDelegate, look at whether a mouse event is<br>
>>> > pending, and call the corresponding VTK mouse handler<br>
>>> > call the renderer's default Render() function while setting the<br>
>>> > delegate's "Used" flag to false<br>
>>> ><br>
>>> > 2nd was a QML item that displays a model loaded from a 3ds file. My<br>
>>> > goal here was to move the model around using mouse drag events. I<br>
>>> > took the lessons learned from the first example, threw in a<br>
>>> > vtkInteractorStyleTrackballCamera and hoped for the best. First<br>
>>> > thing I found was that I needed a specialized<br>
>>> > RenderWindowInteractor, which I provided. When I realized that the<br>
>>> > most important requirement for that class was to provide access to<br>
>>> > timer functionality, I already got wary, as throwing around events<br>
>>> > and doing stuff offline while on the QML rendering thread is never a<br>
>>> > good idea. My fears came true when I finished wiring everything<br>
>>> > together: I was able to move the model using the mouse, but after a<br>
>>> > few moments things got whacky with error output written to the<br>
>>> > console and finally a segemtation fault from deep inside VTK.<br>
>>> ><br>
>>> > I still need to investigate the second example, but would like to<br>
>>> > synchronize with the community at this point in order to avoid<br>
>>> > errors/misconceptions on my side, to seek help if possible and to<br>
>>> > offer my contribution to the VTK code base once this becomes<br>
>>> > functional. My first impression is that there are some issues that<br>
>>> > lie on an architectural level and cannot be (elegantly) dealt with<br>
>>> > on the QML side alone. Any comments?<br>
>>> ><br>
>>> > thanks,<br>
>>> > Christian Sell<br>
>>> ><br>
>>> > _______________________________________________<br>
>>> > Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
>>> ><br>
>>> > Visit other Kitware open-source projects at<br>
>>> > <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>>> ><br>
>>> > Search the list archives at:<br>
>>> <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
>>> ><br>
>>> > Follow this link to subscribe/unsubscribe:<br>
>>> > <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
>>><br>
>>><br>
>>><br>
>>> _______________________________________________<br>
>>> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
>>><br>
>>> Visit other Kitware open-source projects at<br>
>>> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>>><br>
>>> Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
>>><br>
>>> Follow this link to subscribe/unsubscribe:<br>
>>> <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
>>><br>
>>> --<br>
>> Sankhesh Jhaveri *Sr. Research & Development Engineer* | Kitware<br>
>> <<a href="http://www.kitware.com/" rel="noreferrer" target="_blank">http://www.kitware.com/</a>> | (518) 881-4417<br>
>> <br>
>> _______________________________________________<br>
>> Powered by <a href="http://www.kitware.com" rel="noreferrer" target="_blank">www.kitware.com</a><br>
>><br>
>> Visit other Kitware open-source projects at<br>
>> <a href="http://www.kitware.com/opensource/opensource.html" rel="noreferrer" target="_blank">http://www.kitware.com/opensource/opensource.html</a><br>
>><br>
>> Search the list archives at: <a href="http://markmail.org/search/?q=vtk-developers" rel="noreferrer" target="_blank">http://markmail.org/search/?q=vtk-developers</a><br>
>><br>
>> Follow this link to subscribe/unsubscribe:<br>
>> <a href="http://public.kitware.com/mailman/listinfo/vtk-developers" rel="noreferrer" target="_blank">http://public.kitware.com/mailman/listinfo/vtk-developers</a><br>
>><br>
>><br>
<br>
<br>
<br>
</blockquote></div></div>