Only registered users can see emails on this board!Get registred or enter the forums!

)> wrote:
Now I’m trying to build osgqtquick library (or just code that is responsible to create QQuickItem) for Android. However I would like to know is there any library that surely works under desktop platforms (Windows, Linux, macOS) and mobile (Android and maybe iOS)?

There’s another approach you can use, which is simpler than these examples, using the beforeRendering hook of QQ2 to run the OSG render frame. I think I have an example of that somewhere, but would need to check.

I’m currently working on an integration in the other direction, where QQ2 lives in a custom drawable / post-render camera. This uses QQuickRenderControl and has the advantage of rendering on the OSG graphics thread, so in theorey it’s compatible will all the OSg threading modes and hence offers better performance. It does rely on using a forked implementation of GraphcisWindowQt based on QWindow and QGOpenGLContext. Some of that code is already public (inside FlightGear), the rest should hopfully be published in the next few weeks.

I don’t sure that using QQuickWindow::beforeRendering() or QQuickWindow::afterRendering() signal will help since it also uses same OpenGL context as Qt Quick Scene Graph, but I will try it.

Solution that uses QQuickRender sound good, I will lock at FlightGear sources.

Best regards,
Kamil.

Quote:

On 22 Sep 2017, at 11:17, James Turner < (

Only registered users can see emails on this board!Get registred or enter the forums!

)> wrote:

Quote:

On 19 Sep 2017, at 15:28, Kamil Zaripov < (

Only registered users can see emails on this board!Get registred or enter the forums!

)> wrote:
Now I’m trying to build osgqtquick library (or just code that is responsible to create QQuickItem) for Android. However I would like to know is there any library that surely works under desktop platforms (Windows, Linux, macOS) and mobile (Android and maybe iOS)?

There’s another approach you can use, which is simpler than these examples, using the beforeRendering hook of QQ2 to run the OSG render frame. I think I have an example of that somewhere, but would need to check.

I’m currently working on an integration in the other direction, where QQ2 lives in a custom drawable / post-render camera. This uses QQuickRenderControl and has the advantage of rendering on the OSG graphics thread, so in theorey it’s compatible will all the OSg threading modes and hence offers better performance. It does rely on using a forked implementation of GraphcisWindowQt based on QWindow and QGOpenGLContext. Some of that code is already public (inside FlightGear), the rest should hopfully be published in the next few weeks.

Kind regards,
James

_______________________________________________osg-users mailing (

Only registered users can see emails on this board!Get registred or enter the forums!

Only registered users can see emails on this board!Get registred or enter the forums!

)> wrote:
I don’t sure that using QQuickWindow::beforeRendering() or QQuickWindow::afterRendering() signal will help since it also uses same OpenGL context as Qt Quick Scene Graph, but I will try it.

Is that a problem? Keep in mind you can set any QSurfaceFormat as the default (before creating the first QQuickWindow, if you want to work on Mac) and hence request an arbitrary frame-buffer format or context profile, with the Qt API, and QtQuick can still use it.

(And there is QQuickView::resetOpenGLState to avoid any state pollution)

Of course the QQFBOItem approach is nice if you want to keep the contexts separate for some reason.

Quote:

Solution that uses QQuickRender sound good, I will lock at FlightGear sources.

The QQuickRenderControl part isn’t pushed to FlightGear yet, I have it on a local branch since right now it’s not threadsafe, until I find a safe way to run QQuickRenderControl::sync from the OSG graphics thread, but with the main thread guaranteed to be locked. I can guess a few solutions to that but I’m hoping some people more familiar with the threading in osgViewer[base] will have some definitive answers.

BTW both of my solutions above rely on using my GraphicsWindowQt5 which is a port+evolution of the old GraphicsWindowQt5 to QWIndow+QOpenGLContext; that part /is/ in FlightGear already but I’m still debugging some issues, especially mouse-pointer-warping, which FlightGear uses, is not working reliably compared to the ‘native’ GraphicsWindows (Cocoa, Win32, X11, etc)

James can you just confirm that, with the QQuickRenderControl approach, it's no more mandatory to have the main application loop handled by a Qt application class?

At the time when I wrote https://github.com/rickyviking/qmlosg (probably it was against Qt 4. the only option available was to render custom GL stuff within a QtQuick node, and as such I had opted for osgViewer to render into an FBO created on a separate GL context, to avoid any conflict between the GL state used/updated by OSG and the one used by Qt to render its own widgets.

Riccardo

On Mon, Sep 25, 2017 at 5:53 PM, James Turner < (

Only registered users can see emails on this board!Get registred or enter the forums!

)> wrote:

Quote:

Quote:

On 22 Sep 2017, at 20:55, Kamil Zaripov < (

Only registered users can see emails on this board!Get registred or enter the forums!

)> wrote:
I don’t sure that using QQuickWindow::beforeRendering() or QQuickWindow::afterRendering() signal will help since it also uses same OpenGL context as Qt Quick Scene Graph, but I will try it.

Is that a problem? Keep in mind you can set any QSurfaceFormat as the default (before creating the first QQuickWindow, if you want to work on Mac) and hence request an arbitrary frame-buffer format or context profile, with the Qt API, and QtQuick can still use it.

(And there is QQuickView::resetOpenGLState to avoid any state pollution)

Of course the QQFBOItem approach is nice if you want to keep the contexts separate for some reason.

Quote:

Solution that uses QQuickRender sound good, I will lock at FlightGear sources.

The QQuickRenderControl part isn’t pushed to FlightGear yet, I have it on a local branch since right now it’s not threadsafe, until I find a safe way to run QQuickRenderControl::sync from the OSG graphics thread, but with the main thread guaranteed to be locked. I can guess a few solutions to that but I’m hoping some people more familiar with the threading in osgViewer[base] will have some definitive answers.

BTW both of my solutions above rely on using my GraphicsWindowQt5 which is a port+evolution of the old GraphicsWindowQt5 to QWIndow+QOpenGLContext; that part /is/ in FlightGear already but I’m still debugging some issues, especially mouse-pointer-warping, which FlightGear uses, is not working reliably compared to the ‘native’ GraphicsWindows (Cocoa, Win32, X11, etc)

Only registered users can see emails on this board!Get registred or enter the forums!

)> wrote:
James can you just confirm that, with the QQuickRenderControl approach, it's no more mandatory to have the main application loop handled by a Qt application class?

At the time when I wrote https://github.com/rickyviking/qmlosg (probably it was against Qt 4. the only option available was to render custom GL stuff within a QtQuick node, and as such I had opted for osgViewer to render into an FBO created on a separate GL context, to avoid any conflict between the GL state used/updated by OSG and the one used by Qt to render its own widgets.

Uh, these two points are unrelated I think!

First thing - it’s never been necessary to have Qt handle the main application loop : so long as you call QCore|GuiApplication ::proccessEvents periodcilly, eg once per frame. That’s true since 4.x

Second thing, rendering in QtQuick 1 vs 2 (i.e Qt 4.x vs Qt5) changed completed, so yes most concepts are different. There’s several different ways to do OSG + QtQuick, some are easy but restrict OSG to rendering in the QtQuick render thread, which still gives overlapping of the main-thread and GL drawing. What I’m trying with the QQuickRenderControl stuff is to make a maximally performance solution for Flightgear which is compatible with /all/ the OSG threading modes. At the moment I’m not sure how well I will succeed.

Alas, no one replied to my message here about running tasks before the rendering starts, but I think I’ve worked out a solution, with some restrictions. I didn’t have time to work on this stuff in the past week, so a little more patience is needed before I can try out my theories.

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot vote in polls in this forumYou cannot attach files in this forumYou cannot download files in this forum