[osg-users] Integrate Qt into OSG - not OSG into Qt osgQt

Raymond de Vries reedevee at gmail.com
Thu Oct 3 03:49:44 PDT 2019


Wrt Qt: you might be interested in the upcoming rendering interface 
abstraction where no direct OpenGL calls are made anymore. Not sure if 
it helps, let us know!

Cheers, good luck,

On 10/2/2019 8:02 PM, Jan Ciger wrote:
> Hello,
> On 02/10/2019 15:23, Trajce Nikolov NICK wrote:
>> Hi community,
>> I am struggling with the design of such a task. And I am a bit
>> familiar with Qt and other UI frameworks. The task is to embed the
>> whole Qt framework into OSG - including the event processing and let
>> OSG render ( through RTT ) the widgets content.
>> Any clue, hints what direction I should take?
>> Thanks a bunch as always!
>> Nick
> Ufff, you are in for quite a battle, I am afraid. I have done this few
> years ago when we were using Ogre and OSG for our virtual reality
> simulators at work and we needed a proper UI framework to display user
> interfaces inside the application.
> You have basically two options:
> a) Render the Qt widget/window into a texture/image, grab that and
> display it as an OSG texture. Input from OSG can be fed into Qt's event
> system by artificially creating and injecting events.
> This works and it is how we have done it. Qt widgets can render
> themselves into an image/texture directly, simply by calling their
> render() method with proper arguments. We were able to display most Qt
> widgets and render QML using OSG textures. Where things get very hairy
> is the state management between OSG and Qt (Qt uses its own OpenGL
> backend for rendering and assumes that it is in a certain state!) and
> then input. When you aren't rendering Qt the usual way by showing
> windows on screen but you only call render() and grab a texture, Qt will
> not initialize some internal state relating to issues such as cursor,
> keyboard focus, state of some widgets, etc.
> The result is that you will have problems with cursor disappearing,
> widgets not accepting keyboard input, keyboard shortcuts not working and
> myriads of other problems like this. It can be solved to some degree by
> digging into the Qt's source code, seeing which flags it is relying on
> where and then manually calling the necessary functions to ensure that
> they are set correctly. We have managed to get it to such shape that the
> UIs were usable but if you need a very complex UI you will likely run
> into problems. Also OSG's event system doesn't handle anywhere close to
> the gamut of input events that Qt does, so a lot of things will have to
> be emulated.
> b) Implement a new Qt backend running on top of OSG.
> Qt implements several of these backends, including a basic framebuffer
> and OpenGL already, that is how they port Qt to different platforms,
> such as phones or embedded hardware. This would be probably cleaner
> approach if you really need the entire Qt to work but also a lot more
> work than the above, because the API is fairly extensive, not super well
> documented (this are really the dirty guts of Qt you aren't supposed to
> normally see)  and may not have a completely straightforward mapping to OSG.
> Good luck,
> Jan
> _______________________________________________
> osg-users mailing list
> osg-users at lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
> ---
> This email has been checked for viruses by AVG.
> https://www.avg.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20191003/832028e7/attachment.html>

More information about the osg-users mailing list