Building OSG on Ubuntu 20.04 with GLCORE profile

[Hardy Family]

The GtkGLArea widget in GTK3.24 requires GLCORE profile, so the standard Ubuntu/Debian openscenegraph package will not work as it is compiled with GL2 profile.  Unfortunately, my application uses Gtk so I am now forced to get it working.  So I loaded the source package (openscenegraph 3.6.4) and tried to build it.

First, with default configuration, except added

SET(OpenGL_GL_PREFERENCE "GLVND")

to stop the warning about having multiple library choices.  This uses GL2 profile, and after building, osgviewer works fine.

Next, selected OPENGL_PROFILE "GLCORE" and also turned off all "available" except OSG_GL3_AVAILABLE.  Make clean then make again, and now osgviewer only shows an empty scene for the same test file.

Is there something else I have to do in the build?  (I'm not yet even to the point of testing with Gtk).

Interestingly, on the Raspberry Pi 4, which also runs Gtk3.24, my code is working fine with the standard distribution package, so I know it can be done.  On the Pi, OSG is version 3.2.3.

I don't mind a custom solution for this.  Normally we don't want to stray too far from standard distro, but our application is a machine controller so we supply and maintain the PC as well.

Regards,

Steve

[Hardy Family]

Anyone able to take this on?  We are willing to pay for tech support, and the product will remain open source.  Our hardware vendor is imposing this on us, but in any case would be good to get rid of our existing hack.

Basically, we want to run OSG in a Gtk GLArea widget.

Regards,

Steve

[Robert Osfield]

Hi Steve,

If you are restricting yourself to OpenGL core profile then you drop all support for the fixed function pipeline, this means everything in your scene graph has to be based on shaders.  This might be fine for your application, but given you aren't seeing anything perhaps this is the problem.  You specify nothing about your actual scene graph usage so we can only speculate.

Personally I'd think twice about using GtkGLArea if this is applying a constraint that your application isn't ready for.  The OSG itself is capable of creating a window for you, or pass in an X11 window and have osgViewer create the context for you.

If you really have to use GtkGLArea with the Core Profile constraint then you will have to port your application to work with shaders only.

As a general note, use of GtkGLArea is a real niche usage, others in the community might use it, but I'm afraid the vast majority won't have ever touched it and will not be able to provide any support/help to you.  I know I haven't.  The above is as much as I can help you with.  If you want to use niche combinations then the more likely you'll have to figure out things yourself.

Cheers,

Robert.

[Hardy Family]

Hi Robert,

Thanks for that.  So how can I tell if an OSG scene is going to use any fixed function pipeline calls?  As I mentioned, I'm not even at the point of trying to use GLArea, but just trying to build OSG with GL core profile, and seeing if the demo application (osgviewer) works.

So far, I just tried to test it using

osgviewer my-vrml-file.wrl

i.e view a VRML file.  In my ignorance, I assumed that OpenGL was just an implementation detail hidden by OSG, but obviously I have poked a sleeping bear.

Is there some debugging I can turn on to pinpoint where the problem may lie?

For our actual app, we basically load a bunch of VRML files and also add fairly simple geometry, using just the OSG API, not doing any OpenGL calls directly.

Regards,

Steve

--
You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osg-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BVdFVR7-1Nj4Oe9eg6CE-%3D__dW6UK-VVgZ2NCWURoFnGg%40mail.gmail.com.

[Robert Osfield]

On Tue, 13 Apr 2021 at 16:40, Hardy Family <hardy.woodl...@gmail.com> wrote:

Thanks for that.  So how can I tell if an OSG scene is going to use any fixed function pipeline calls?

You can tell what OpenGL state the scene graph has in it by look at the osg::StateSet attached to the nodes in the scene graph.  Writing the scene graph to .osgt is one way of manually reviewing what goes into it.

 

  As I mentioned, I'm not even at the point of trying to use GLArea, but just trying to build OSG with GL core profile, and seeing if the demo application (osgviewer) works.

So far, I just tried to test it using

osgviewer my-vrml-file.wrl

i.e view a VRML file.  In my ignorance, I assumed that OpenGL was just an implementation detail hidden by OSG, but obviously I have poked a sleeping bear.

VRML files are ancient, and all revolve around the old fixed function pipeline. To use them you have to convert the fixed function state to ones supported by shaders.  OpenGL fixed function pipeline is very different to shaders.  It's a big topic.

How much knowledge/experience of OpenGL/OSG do you have?

 

Is there some debugging I can turn on to pinpoint where the problem may lie?

There is unlikely to be one problem point if you really must render a fixed function pipeline based scene graph with shaders.  There is an osgUtil::ShaderGen utility class that can help to remap some simple fixed function scene graphs to shader based, but it doesn't provide full coverage.

 

For our actual app, we basically load a bunch of VRML files and also add fairly simple geometry, using just the OSG API, not doing any OpenGL calls directly.

The easiest way for you to get your application working is to not use OpenGl core profile.  It's that simple.  The alternative is likely to require far more learning and work on your part.

 If that means avoiding using a Windowing toolkit that doesn't support standard OpenGL then that's what you should look at.

[Hardy Family]

How much knowledge/experience of OpenGL/OSG do you have?

Nothing post 90's, really.  Think "red book".  It's a big learning curve for me. Up to 2016 I was in embedded/networking, and only in the last 5 years have been developing a PC app.

Again, I apologize for my ignorance e.g. I assumed that VRML files just described geometry and lighting and did not have any particular dependency on API details.  But there you go.  I guess it was just expedient for the time.

 

For our actual app, we basically load a bunch of VRML files and also add fairly simple geometry, using just the OSG API, not doing any OpenGL calls directly.

The easiest way for you to get your application working is to not use OpenGl core profile.  It's that simple.  The alternative is likely to require far more learning and work on your part.

 If that means avoiding using a Windowing toolkit that doesn't support standard OpenGL then that's what you should look at.

With 20-20 hindsight, yes maybe I should have chosen QT etc.  There's nothing I'd like to do more than learn how to write shaders etc. - it's right up my alley since I've always worked with programming DSPs, FPGAs and microprocessors - but in the real world I have my hands full just getting things to work for customers.

As far as development effort, OSG integration is only about 5% of our app, so we're not in a position to let the tail wag the dog in spite of the fact that the nice 3d display impresses customers no end.

Admittedly this is not what I wanted to hear, but it appears I need to persist with my current hack or find a new one.

The thing I don't understand is how it just works "out of the box" on the Raspberry Pi 4, so I would think if it could be done for a small ARM based processor with OpenGL ES 3.0 support, why can't it work for a standard desktop?

Regards,

Steve

[Robert Osfield]

Hi Steve,

Thanks for the background.

The GLES codepath could be using the osgUtil::ShaderGen automatically and adjusting state setup to provide some basic mapping of fixed functions to shaders.  You don't say how you've built the OSG, or how you've done the Gtk integration so we are left guessing on lots of unknowns.  It may be possible to configure your OSG desktop build to work better, but there is a bunching of learning you'd need to do about building the OSG/Configuring things at runtime.

Far easier would be to just create a normal OpenGL context such as by using the standard osgViewer::GraphicsWindow functionality. The OSG will probably just work out of the box if you don't add all the extra contronstraints that Gtk is enforcing.  

As a sanity test just load your data with osgviewer.  If it works fine then look at just using the osgViewer to create your graphics window.  You can later start looking at how to integrate that with Gtk.

Robert.

  

[Hardy Family]

First thing I will try is to get to the underlying XID (say, of a Canvas widget) and go from there.  Also, the ShaderGen looks interesting; maybe I can go back to basics enough to get that working.

You can see a promo for our application here.  There is a video that loads on that page to show it in action.

https://www.motuscnc.com

I didn't give a lot of detail on how we build things because it's quite complex and I didn't want to be overwhelming.  The app is written mostly in Python2.7 and calls the Python binding for Gtk3 to handle the GUI.  We also have bindings to our own C++ libraries.  One of those is a wrapper layer I developed for OSG.  It takes a cafeteria approach i.e. I just add functionality as needed.  The binding is done with boost.python.  We have a subclass of osg::Viewer, and some subclasses of osg::Geode to handle a video stream from USB and/or Ethernet cameras.

Regarding OSG itself, we are relying on the standard package from Canonical and/or Debian, so it's already all boxed up for convenience.  For my recent experiments I got the package source, reconfigured and built from scratch.  Not sure if you're familiar with the Debian way, but it's as simple as apt-get build-deps, apt-get source openscenegraph, cmake-gui, make, make install.

Regards,

Steve

--
You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to osg-users+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/CAFN7Y%2BX4RPHMBFvLEVi2aeB29xOHusPk6c%3DZV0N%2Bxr2Cc9YE9A%40mail.gmail.com.