Did you have an interest in OpenGL ES at one point? (Still invested?)

[m-7761]

I'm not suggesting changing any existing OpenGL code, but do you have any input on what if there were either a capture system or alternative OpenGL ES path? By capture I mean for instance instead of drawing the model/viewports some buffers were filled up with data, then multiple view ports could pull from the same pool of data. Or the data could optionally be maintained in ES buffers (dynamic update for edits.) My thinking is such a system would have to be a customizable interface, i.e. use virtual keyword. And there would then be some default implementations. I'm asking because I've been working with ANGLE (https://en.wikipedia.org/wiki/ANGLE_(software)) and my UI can run in an ANGLE context and its library exposes ES via a namespace...

I still value the classic (old school) OpenGL API because it works with iGLX and is just elegant. But I'm planning to add some effects and VR to this library. So if I could add a flexible interface an alternative way to draw models I think it could be interesting, and I'm intending to add a simple model viewer to this library, so prototyping something for MM3D could inform its design. Or link into it. (I'm adding ANGLE so I can use it in my mainline projects to hook into OpenXR. I don't want to write against OpenGL but ES is a bit more manageable and with ANGLE in theory it can then tie into lots of backends like newer D3D, Vulkan, and even Apple's crazy world where god knows what goes on.)

I just finished writing a translation layer that converts OpenGL into ES for my UI system (https://github.com/mick-p1982/mm3d) all so I didn't have to butcher the elegant OpenGL code. I'm not really planning on upgrading my MM3D project with this anytime in the near future, other than I do have this interest in developing a very simple, modular model viewer. I'm going to use it in the project I'm working on right this instant to draw some simple things like VR peripherals. I could kind of spread that work over MM3D. The UI/ANGLE library won't have any loader code. But it does manage VR effects and input/output. (It will host OpenXR too, alongside ANGLE. ANGLE is static linked so I can work on interop, and I might try to use an open implementation of OpenXR so I won't be limited to the OpenXR spec, that worries me.)

[Sorry for the long post. I didn't plan it that way but I felt some background was in order.]

[zturtleman]

I have an interest in OpenGL ES but not for Maverick currently. I'm developing an OpenGL 2+ / ES 2+ / WebGL renderer and model viewer in my Clover's Toy Box project. I'm not interested in releasing the source code at this time but I also don't want to duplicate work developing separate OpenGL code in Maverick. So I removed OpenGL ES support from my plans for Maverick (#51).

[m-7761]

My thinking is something that's very simple. Not necessarily doing any more drawing than MM3D currently does, but ES compatible and buffered somehow. I ask to be open about my intentions. I still hold onto that it's possible to merge my work here by updating the core without touching the UI (Qt) stuff. By converging on a common core IOW.