[osg-users] osgQt + OSG 3.6.2 Status

[Wojciech Lewandowski]

Hi,

I have just investigated the issue with OSG view set in QT window and
osgEarth REX engine which resulted in completely black screen. This was
probably different problem, but it sounds bit like yours so I decided I
will share my observations. Maybe it will help someone. What I found to be
an issue in our case was a missing call when setting our main view camera :

main_camera->setDrawBuffer( GL_BACK )

This call makes sure the glDrawBuffer is set to main window BACK buffer
before drawing main view frames. In my case REX engine was setting up RTT
camera (without Color attachment) which swtiched DrawBuffer to GL_NONE. And
main window was not restoring it before drawing the frame. So the effect
was a completely black screen. I suspect similar problem may happen not
only with osgEearth REX but with any RTT camera (without color attachments
like shadowmap cameras). When I added above line while setting main camera
problem vanished. I hope this may help somebody.

With classic OSG Viewer this call is made inside SceneView ctor when
setting up the camera. I believe our app also set up SceneView with QT
window at startup but somehow DrawBuffer setting was later
reverted/discarded. You may check if this hints helps you.

Cheers,
Wojtek Lewandowski

sob., 28 lip 2018 o 11:51 Robert Osfield <robert.osfield at gmail.com>
napisał(a):

> ?!?! gmail just sent the email mid sentence....
>
> > That exactly the same can be said for the OSG.  Doesn't mean
>
> Mean't to say:
>
> On Sat, 28 Jul 2018 at 10:20, Robert Osfield <robert.osfield at gmail.com>
> wrote:
> > > Now, there are huge firms that adopted Qt for decades and run multi
> billion dollars systems on it.
>
> The exactly the same can be said about the OSG.  It's widely used for
> decades on serious extensive kit.
>
> However, this doesn't mean that OSG isn't flawless and can't be improved
> upon.
>
> With modern C++ with have opportunities to do a number of things far
> more cleanly that previously possible.  This applies to the scene
> graphs just as much UI's.
>
> The future of C++ application development will be better served by
> successors to the OSG and Qt.
>
> Right now such successors are just embryonic ideas, or nuggets of
> prototypes.  For current application development which need cross
> platform widgets may be best served by Qt, same as the graphics
> application development may be bested served by the OSG.  Current
> applications will be around for many years to come so Qt and OSG will
> need to be maintained.
>
> For my own part I'm committed to maintaining the OSG.  For 3.6.x I
> moved osgQt out of the core to allow members of the OSG community who
> have the need for Qt support and the expertise to know how to maintain
> it the ability to make decisions, implementation solutions and provide
> proper maintenance for it - something I can't do personally as I don't
> have the Qt expertise, nor the time.
>
> This thread is a bit worrying as despite me handing the keys over to
> osgQt development to the community doesn't yet seem to be able to
> resolve all the problems by themselves.  Yes the source code to both
> Qt, osgQt and the OSG are all available, but unless developers step up
> things don't happen.  This suggest perhaps we need a bit more
> motivated manpower from the Qt/OSG community to help push osgQt
> forward.  So if you feel passionate about Qt then please step forward
> and help out.
>
> --
>
> As a little prod for the long term future.  With UI's and 2D rendering
> API adopting scene graph internally (by this I don't mean Qt3D) and
> more UI/2D rendering being done down on the GPU there is a possible
> convergence.  Could one have a scene graph that is general purpose
> enough to be used directly to do 2D UI's as well as 3D real-time
> graphics?  Could one implement the UI as an add on to the core scene
> graph, just a you'd made a game engine or image generator that builds
> ontop of a scene graph??
>
> So... I'm writing a new scene graph, yes I'm focused on it being used
> for 3D, but I'm aware that Vulkan does compute just as nicely as it
> does 3D, and it also works just fine for 2D too.  If you can have a
> scene graph just work as a compute graph, as well as 3D rendering
> graph then 2D rendering is also just another subset.  Could an
> enterprising engineer build a fully function UI ontop of it?  Maybe.
>
> Even if it doesn't come to pass for my VSG work, this is how I feel we
> should all be thinking about the future - we should be thinking out of
> the box, thinking about where we could get it if we strive for it,
> rather than settling for the status quo.  Yes yes the OSG and Qt are
> impressive in a number of ways, but they have but of all encompassing
> monsters that are at there peak.  Better solutions will follow on, if
> they don't the computer industry is failing to progress as it should.
>
> Robert.
> _______________________________________________
> 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/20180728/b3ac6c36/attachment.html>