[osg-users] Qt5 integration

[Riccardo Corsi]

Hi Werner,

no problem, I was just sharing some use cases.

Regarding the embedding use case you mention, if that is QtQuick/qml based,
you're most welcome to take a look to the implementation I mentioned in my
previous email, hopefully that might helpful for your development.

Cheers,
Ricky

On Mon, Aug 17, 2015 at 6:54 PM, Werner Modenbach <
Werner.Modenbach at texion.eu> wrote:

> Hi Ricky,
> I understand your point of view here. But I think there are multiple use
> cases.
> If I understand your approach well you intend having a 3d rendering app
> with some nice qt based features.
> On the other hand we are developing a lot of software in the textile
> environment and 3d simulation of the fabric is just an optional add-on. So
> the main aspect in our case is having a geometry managed embedded window
> showing an ist scene.
> So for us James's contribution is just what we need.
> As I said before, there are many scenarios for interacting qt and osg.
>
>
> On 17. August 2015 18:33:46 MESZ, Riccardo Corsi <
> riccardo.corsi at kairos3d.it> wrote:
>>
>> Hi James,
>>
>> I haven't looked into osg+qt integration since a while so I might not be
>> aware of the latest features available.
>>
>> From my point of view the most desired feature is to be able to integrate
>> a qt scene (a GUI layout or a browser/pdf/svg viewer widget) inside an osg
>> driven application smoothly - i.e. without the need of a Qt application to
>> run as main thread loop, but hiding it as a "slave" somewhere in an osg
>> module/node, to make those widget pluggable in a "regular" osg application.
>>
>> Instead if you're interested, a while ago I coded an integration to
>> render with osg inside a QtQuick+QML application.
>> Basically the solution implements a custom QtQuick node which renders an
>> osgViewer scene to an FBO, and then copies the FBO contents back to the Qt
>> context, to make it available in the qt/qml scenegraph which renders the
>> widgets.
>> The osgQuickNode uses a separate OpenGL context, not to interfere with
>> the one used by Qt for its own scene rendering.
>> All the code is here: https://github.com/rickyviking/qmlosg
>> If you have questions about the implementation feel free to write me.
>>
>> Ricky
>>
>> On Mon, Aug 17, 2015 at 12:54 PM, Robert Osfield <
>> robert.osfield at gmail.com> wrote :
>>
>>> HI Alistair,
>>>
>>> I'm not familiar with Qt5/QQuck2 so can't comment on the Qt side, so
>>> have to defer to others on this.
>>>
>>> On the OSG side osgViewer is designed specifically to handle a thread
>>> per graphics context/window - it's a core feature of how
>>> osg::GraphicsContext, osg::GraphicsThread are designed and implemented.  If
>>> Qt5 requires a thread per window then this is a model that osgViewer can be
>>> capable of handling since it's inception (well before Qt5), the only
>>> question would be to how to integrate the threading in synchronization
>>> operations that Qt5 is forcing upon the set up with the way that the OSG
>>> manages things.  Perhaps subclassing from osg::GraphicsThread might be one
>>> approach or other classes.
>>>
>>> I don't know if the other direction might be possible - stop Qt trying
>>> to do eve rything that the OSG can already do perfectly without it.
>>>
>>> Robert.
>>>
>>> On 17 August 2015 at 09:48, Alistair Baxter <alistair at mve.com> wrote:
>>>
>>>> As you are no doubt aware, James, we've been looking into this sort of
>>>> integration ourselves. QQuick 2 integration is part of our goal, although
>>>> we hadn't been planning direct interaction between QML and out osg scenes,
>>>> since we have a separate data model. Although if such a thing existed, and
>>>> were sufficiently convenient to use, then we might be interested in
>>>> integrating it in a similar way to how we use the existing 3D osg
>>>> manipulators. We've never really been interested in QWidgetImage, we only
>>>> ever used it to try and get round a window composition issue on OSX.
>>>>
>>>> Our main concern at the moment is that we need a multi-window viewer.
>>>> Due to the way Qt 5 has a separate opengl render thread per Window, this
>>>> has meant reimplementing a significant chunk of OSGCompositeViewer in order
>>>> to get it to work at all, and we are discovering a variety of
>>>> thread-synchronisation issues.
>>>> _______________________________________________
>>>> osg-users mailing list
>>>> osg-users at lists.openscenegraph.org
>>>>
>>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>>
>>>
>>>
>>> _______________________________________________
>>> osg-users mailing list
>>> osg-users at lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>>
>> ------------------------------
>>
>> osg-users mailing list
>> osg-users at lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20150818/5621f2bf/attachment-0003.htm>