Any OPENGL wizards?

One of these days I want to make a new control box using a Raspberry Pi4 as the controller. I already know it has the horsepower but the GPU runs on OPENGL ES3.2. I tried porting the gcode_graphics widget to Pi3d and made some progress drawing lines and shapes etc. but I can see it will end up being a huge project and I'm not even sure how well Pi3d is supported. I have also successfully got it to run VTK but for some reason it uses all available CPU cycles and would make the pi run hot. I don't really care for the vtk graphics anyway. The only other option I see is porting to OPENGLES but this could be a major undertaking too. Advice and comments from anyone familiar with opengl is appreciated. Thanks.
Jim

Hi Jim,

I'm no opengl wizard, but I had the same problem some time ago.
When I started to add graphic path output to my java app, I didn't want to bother with opengl. So I searched for alternatives.
There where plenty aborted projects, that tried to bring opengl to java. I didn't found any active project on that goal.
Then I discovered jmonkey by accident. It is a platform for game development. Well, I didn't want to create a game, but their hardware abstraction sounded very attractive to me.

So I did some quick tests, that showed, that that project is very fast and usable for painting cnc paths. I had to create some core-classes and implement a different "camera" (in gaming sense), but after few days my gremlin counterpart was working as desired.

May be you find similar projects, when searching for linux game engines

cheers Reinhard

Hello! Raspberry Pi4 will be something. I would like to draw your attention to the processor load in different interfaces. VTK on embedded graphics does not start. Computer with core i3-530. File 5 MB.

I surfed the internet a bit and came across uGFX and LittlevGL, both of which can handle framebuffers. They look beautiful, eat very little. www.murga-linux.com/puppy/viewtopic.php?...84833683ad8eba52c586 Here's another docs.lvgl.io/v6/en/html/porting/display.html

I dont think there is a proper GPU driver just yet, so its capable of gles3.2, but it only recently got the 3.1 driver, mine says its still at gles3.0. the 3.2 driver is still only half way done. I would like to know if other SBC linuxcnc users tinker/orangepi/etc, have the graphics working on qtvcp also, just to see if its a rpi4 issue or an embedded systems one. I wouldnt go so far to rewrite the whole thing, it looks like QGLwidget is obsolete ( doc.qt.io/qt-5/qglwidget.html i think its this ), and its replacement ( doc.qt.io/qt-5/qopenglwidget.html#details ) seems to address the issues we are having with cross platform stuff, i think

the other thing ive been working on, is this, but im stuck between the 2 pi errors . it looks like it can be installed on pi4,
github.com/ptitSeb/gl4es
github.com/ptitSeb/GLU
easiest option, embedded glade tab with gremlin, already works with qtaxis

qtvismach got me in to mood to fight this again. what ive got so far is, that qt5 graphics should work on the rpi4.

-rpi4 can handle openGL 3.3, the whole thing between opengl and opengles on the rpi4 has to do with the GPU and its drivers, which are now openGLES 3.1 compliant. when not using the rpi4 specific GPU drivers, the software graphics drivers(the mesa lib i think) are capable of doing openGL 3.3, so this shouldnt be the issue

-qt5 graphics sends errors on things that the other gui do not (glgenlist for example), so thats not the issue,
but even if you remove glgenlist, it just goes through every gl/glu thing not defined in opengles

so that eventually led me to these 2 bug reports
bugs.debian.org/cgi-bin/bugreport.cgi?bug=895499
this 2d robot simulation program has almost identical issue we do. an existing software wont run cross platform, with a similar error on glgenlist

The root cause is that on armel/armhf (and arm64 in Ubuntu)
Qt5 is compiled with OpenGL ES instead of OpenGL.
enki-aseba should be fixed to build and work with OpenGL ES,
but if this is not easily possible please
- change the build dependency from libqt5opengl5-dev
to libqt5opengl5-desktop-dev, and
- file a removal bug for the old armel+armhf binaries
of enki-aseba and aseba against ftp.debian.org

which led me to the split between libqt5opengl5-dev and libqt5opengl5-desktop-dev,

bugs.debian.org/cgi-bin/bugreport.cgi?bug=881943

Different from other architectures, on armel and armhf
Qt in Debian is configured to use OpenGL ES instead
of full OpenGL.

Some OpenGL-related functionality in Qt is not available
with OpenGL ES, and Qt also offers direct access to OpenGL.

This causes some packages to not build with libqt5opengl5-dev
on armel and armhf, and while making them build would obviously
be the best solution that is not feasible in cases where
upstream does not provide any way to disable this kind of
OpenGL usage or has alternative OpenGL ES codepaths.

A package that does FTBFS on armel+armhf buildds after every
upload is not ideal - it wastes buildd resources and makes
it harder to find bugs between the expected FTBFS.

so, qt5 is configuring to build for openGL ES because we are running ARM ,
but the qt5 graphics, uses QGLwidget, which seems like a hard openGL widget, and not the cross platform QOpenGLwidget.
I think what needs to happen, is a custom configuration of qt5 for linuxcnc rpi4. still dont know all the details yet, or weather or not i need to totally rebuild qt5 or what, but here is the CFLAG we need to change/add probably not the only thing we need to configure but thats the big one i think.

i think this should load the libqt5opengl5-desktop-dev(which uses full opengl instead of libqt5opengl5-dev ( which forces arm to use opengles)

github.com/koendv/qt5-opengl-raspberrypi
here is what ive got so far for references, but most people are trying to do this to run qt in a non windowed environment so my results are getting diluted . its essentially what cmorley has said every time it comes up "qt5 graphics is based off previous code" "probably calling the wrong library" something to that tune

Does any of this sound plausible?
If anyone else would like to try and test this out over the holidays, that would be helpful.

cmorley - if lack of rpi4 is the only thing holding you back, that is one problem i can solve (with the help of canakit). If you arent interested, I completely understand.