Support rendering using OpenGL ES 2

[zturtleman]

Currently OpenGL 1.1 is used for rendering models. Changing to OpenGL ES 2 will allow for better compatibility on GNU/Linux ARM mobile/low-end devices and Windows using DirectX via ANGLE library or LLVMpipe software renderer. (Currently Windows has black OpenGL widgets if ANGLE or software is preferred thanks to Qt blacklisting the driver and not initializing OpenGL.) Qt 5 includes the ANGLE and LLVMpipe DLLs and can handle when to use them with QOpenGLFunctions class.

There is also potential for OpenGL ES 2 -> Vulkan -> Metal for macOS (as OpenGL is deprecated on macOS 10.15). OpenGL ES 2 is probably needed to support PBR rendering if glTF 2.0 is going to be supported in the future. (This issue not about solving these though.)

The rendering code is in various files in libmm3d. It would be nice to centralize it so multiple different rendering backends could exist; possibly outside of libmm3d.

I'll probably look how to integrate Qt 3D and/or the OpenGL ES 2 renderer I'm developing for my proprietary Clover's Toy Box project.

[m-7761]

I don't know why on earth modeling software should work on mobile devices??? But anyway, there is a project called GLOVE that may be helpful. Doing ES on desktops historically makes no sense, since vendors don't support it. I am personally interested in ES 2 myself, since I think it's the best version of OpenGL, and desktop OpenGL is a basket case. But it's only portable in the sense you can copy/paste the code. The benefit of ES 2 is it's like a rewrite of OpenGL without any legacy baggage. I think you can get similar functionality if you choose a recent profile when creating your "context," but I've never done that (I work much more with Direct3D) before. I don't know what the trade-offs are, and I'd personally prefer to just use ES 2 if possible than do a lot of research into where OpenGL is today.

I think ES 2 is a solid API with long tails, like Direct3D 9 is. But I don't know how you use it on Windows, so I'm curious to see what you can figure out.

[zturtleman]

For ARM mobile/low-end devices I mainly refer to using a Raspberry Pi or smartphone (Ubuntu Touch, Librem 5) connected to a monitor and running a full desktop. I'm not intending to pursue using a 5" touch screen for model editing.

I actually meant switch from fixed function OpenGL to OpenGL ES 2.0 compatible. OpenGL 2.0 should also be supported. My Clover's Toy Box renderer supports GL2 and ES2 and nine OpenGL extensions from GL3/4 and ES3 (apparently I like OpenGL research :smile:). GL2+ and ES2+ are both supported by QOpenGLFunctions class. I don't know what Qt 3D supports though.

OpenGL ES 2.0 context works fine on x86_64 Windows and Linux, with the proprietary Nvidia driver at least. It's best to support desktop OpenGL, yes. I haven't worked with Direct3D.

[m-7761]

Is your Toy Box open source? https://clover.moe/toybox/ How do you accomplish though things?

OpenGL is a little easier to use on Linux. Like on Windows everything after the first year of OpenGL is an extension that must be dynamically loaded. It's years and years of cruft on top of cruft that's never been swept away for good once. Like if vendors just shipped ES 2 drivers for desktops that would have been an opportunity to transition over to a modern alternative. Direct3D rewrites its API for every iteration. OpenGL has never done that, and that's part of the problem. That and its API that is limited to a tiny subset of C with no use of struct and dynamically loading a hundred extensions (out of a thousand) that each have their own corresponding white-paper not in the documentation, some really obscure for GLX/mesa, make it a slog to work with.

So like, having to use ANGLE or something like that is just more of the same in this long tortured history of murkiness and misery.

[zturtleman]

The rewritten modern "OpenGL" API you're asking for is Vulkan — using C with struct or even a C++ vulkan.hpp interface. There is still support for extensions that are dynamically loaded though. The main issue is older hardware does not have Vulkan support.

In ioquake3 (GPL open source) and Clover's Toy Box (proprietary) I use OpenGL the same on Windows and Linux. (SDL or Qt can handle the differences in the OpenGL context setup.) I load all OpenGL functions dynamically. Nothing forces you to use the "years and years of craft". It's your choice to support older OpenGL versions or show an error message.

OpenGL ES 2 being supported natively on Windows would be convenient. Though it's missing so much from OpenGL ES 3 and desktop OpenGL that high performance game engines wouldn't use it anyway. It doesn't seem like the old OpenGL API should be an issue. It's not in the official OpenGL 3 and 4 documentation. There are modern OpenGL 3 tutorials at https://learnopengl.com/ and http://www.opengl-tutorial.org/. If you don't want to manage OpenGL extensions yourself there is the GLEW library (I do it myself because it's fun, I guess). (Qt also does some extension handling with QOpenGLFunctions class.)

OpenGL backward compatibility and extensions can be beneficial though. It allows my integrated Intel graphics that can only fully support OpenGL 2.1 (and presumably Direct3D 9) to use some extensions that were added to OpenGL 3 and 4. Including persistent mapped buffer (OpenGL 4.4, GDC2014 video) which is similar to the Direct3D 11 feature D3D11_MAP_WRITE_NO_OVERWRITE (slide 51 of GDC2012 Efficient Buffer Management).

I assume I would need entirely separate Direct3D 9 and 11 backends to support my integrated Intel graphics and persistent mapped buffer equivalent. I would be unable to test/develop the Direct3D 11 backend on this system. This seems inconvenient to me. (Though I guess one could argument "it's simpler to program, just get better hardware!") Granted I'll end up with similar situation of two backends for different APIs if I add a Vulkan backend (which isn't supported for my integrated Intel graphics) along side OpenGL [ES] to Clover's Toy Box.

[m-7761]

The main issue is older hardware does not have Vulkan support.

Nor do some platforms. And it's also hard to directly write code against. And it's also relatively new. And there is a lot of competition. So it's why something like the GLOVE project that wraps Vulkan in ES is I think a better strategy for developers that aren't backed by large institutions, or writing layers. The reason ES isn't on desktop is sheer laziness and lack of funds/support. It's a problem many Khronos initiatives face. It splinters the landscape into incompatible platforms. So you can have both. And you should have both.

Noncommercial software development is initiatives done by people without money for people without money that does not depend on continued flows of money to sustain itself.

It's your choice to support older OpenGL versions or show an error message.

That's my criticism yes. It's a ridiculous way to work.

OpenGL ES 3 and desktop OpenGL that high performance game engines wouldn't use it anyway.

And that's why it doesn't exist, because only money drives these things. Having a competent API for noncommercial software that doesn't make its home in that psychopath world isn't an option because no is going to pay for it.

My workstation is integrate Intel, Iris Pro, but I think it has pretty recent version of OpenGL. I've written a lot of OpenGL software in my day without spending days investigating things I know I could, but prefer to spend that time doing more productive things. I think OpenGL is mismanaged. Yes. The best arguments against is mismanagement is to point out how mismanaged it is. That's not an argument. I think having portable ES on desktop, however implemented, would be a positive step for noncommercial code like ours. It would be like Direct3D 9, but using OpenGL instead of a Microsoft exclusive technology. The next best thing is middleware that wraps around OpenGL completely so it doesn't have to be used at all. But I've never had cause to investigate that. I started to develop something like that for personal use long ago.

Long story short, is noncommercial software can gain quality by being subtractive instead of additive. Enabling efficient computation isn't often a bottleneck or worth consideration. And even today very often interpreted code is championed even though it runs 5 to 10 times slower, meaning that it's software for rich people who can afford 5/10 times more computationally intensive machinery. So like, the line between Direct3D 9 and Direct3D 12 or whatever, is not significant. What it comes down to what is the better API. Especially if you can only target one or two APIs. Vulkan isn't that. So I think ES probably is the best candidate for the cross-platform world. The GLOVE project writes ES on top of Vulkan, but it's not implemented for Windows desktop yet. That's a better way to use Vulkan. ES has documentation that isn't spread all over years of extensions. OpenGL is like if Direct3D was still Direct3D 2 today. It's admirable to have to have that level of commitment to back-compatibility, but at some point you have to cut the cord and start over, or its just laziness. ES was moments when the cord was cut. That desktops never got to see the full benefit of that exercise. All I'm saying is that's lamentable. And it will be interesting to see if desktops ever do evolve to a better situation.

[zturtleman]

After re-evaluation of what I want of this project this is no longer on the roadmap.

[m-7761]

FWIW I'm going to start using ANGLE for compatibility with VR peripherals, so when I do switch the rendering code over I will use ANGLE and I don't know about Qt's needs. I don't know if ANGLE code looks just like OpenGL ES via OpenGL but I've looked around and there's literally no alternatives. Frankly that GLOVE project seems to be doing exactly what ANGLE is doing limited just to Vulkan, I'm not sure.

Anyway, I will be familiar with ANGLE before too long. It seems like the right choice for moving away from OpenGL 1.x but I think it will be necessary to support both modes to continue to enable IGLX which I use every time I use Linux on Windows. Short of programming a replacement for it I see no alternative.