QOpenGLWidget bugs with map layers and draping

classic Classic list List threaded Threaded
5 messages Options
Blanky Blanky
Reply | Threaded
Open this post in threaded view
|

QOpenGLWidget bugs with map layers and draping

Hi everyone,

I'm working with Qt 5.10.1 and used to embed an osgEarth::QtGui::ViewerWidget in my code. Seeing as how I needed to embed it in a QGraphicsScene, it turns out QGLWidgets cannot be, even according to the Qt references. As a result, I took it upon myself to create a custom QOpenGLWidget instead of a QGLWidget that the ViewerWidget inherited from.

Some strange issues persisted after this change.

1) Shared osgEarth::MapNodes set as the root of a viewer (1 root to many viewers/cameras) seemed to have an OpenGL draw issue when it traverses the ImageLayers containing the earth's .tif image. Some of the tiles do not render, but if on creation of one of these new viewers if I remove each layer of the MapNode and add it back in a foreach loop, everything seems fine. I don't understand why I'd have to manually "refresh" the layers, the code essentially is doing nothing.

2) Any osgEarth of type Annotation Node or anything that can be styled with the AltitudeSymbol for its drape technique set to anything will destroy the entire scenegraph and the MapNode will not render anything. I noticed this effect occurs when you have invalid vertexes assigned to an osg::Geometry. So my question is, is this a bug with the QOpenGLWidget or is there something I should additionally do in the paintGL() call other than calling frame on that widget's osg::Viewer?

If I just call run on the viewer and pop it out without Qt, everything runs fine. If I use a ViewerWidget, everything is fine.

Thanks!
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: QOpenGLWidget bugs with map layers and draping

Blanky,
Details are hazy, but IIRC there is some kind of issue with the way QOpenGLWidget renders using an FBO that makes it incompatible with osgEarth's FBO usage (which includes draping). The issue likely extends to OSG in general, though I have not seen much in the way of testing. QGLWidget does not have this problem.
Glenn Waldron / Pelican Mapping
gwaldron gwaldron
Reply | Threaded
Open this post in threaded view
|

Re: QOpenGLWidget bugs with map layers and draping

Found it:
http://forum.openscenegraph.org/viewtopic.php?t=15097

Basically, OSG does not expect an FBO as the active super-target.
Glenn Waldron / Pelican Mapping
Blanky Blanky
Reply | Threaded
Open this post in threaded view
|

Re: QOpenGLWidget bugs with map layers and draping

Thank you so much Glenn, this is exactly what I was looking for. Looking forward to 3.0 release and I'm happy to hear your ideas for API changes and cleanup despite possible backwards compatibility issues.

- Blanky
Blanky Blanky
Reply | Threaded
Open this post in threaded view
|

Re: QOpenGLWidget bugs with map layers and draping

This post was updated on .
In reply to this post by gwaldron
Hey Glenn,

I looked into the post you linked from the osg forum. My colleague and I attempted all of the solutions in that post, however something strange within the osg::CullVisitor's apply, specifically for an osg::Camera came up. The forum's solution says to essentially create a custom CullVisitor for the camera and that we needed to copy the entire apply function for the camera and add a little tid bit of code as suggested in his post half way down.

After applying the solution it appears as if a recursive camera is being displayed offset in our earth layer as well as the draped feature nodes that I created. The issue however is that these draped nodes are not positioned correctly and also shift with the earth's layers while we interact with the earth manipulator handler. This isn't much better than a blue screen, but it does appear to be on track as a possible solution. Do you have any clue what may be happening to the textures/cameras?

If we get this, we may have a more modern solution to replace the deprecated ViewerWidget. Thanks for any input and help.

- Blanky