What is the status of the OpenGL context in the BGE ?

Last time I checked with a 2.5x branch of Blender, the BGE was basically useless in creating games because of old and deprecated context used for the drawing calls and the OpenGL rendering; I would like to know if there are plans to update the BGE to a modern programmable pipeline to support OpenGL 3.x and newer, and OpenGL ES 2.x and newer. I have also noticed that the BGE is basically the same since the 2.xx branch with minor changes.

What is the roadmap for the BGE ?

You’ve clearly done your homework on OpenGL and OpenGL ES, but I would also like to know what core functionality is available in OpenGL 3 or 4 that’s not available in OpenGL 2 with the use of extensions. Is it just a speed issue, or is it that OpenGL 3 or 4 actually adds something weighty? I know that tesselation and geometry shaders were added in at some point after OpenGL 2.

the answer is simple, the problem it’s not the number of the OpenGL context that we consider, the programmable pipeline introduced with OpenGL 3.x is the only real way of producing something with OpenGL in bot OpenGL and OpenGL ES, supporting the old fixed pipeline is like supporting a bunch of highly deprecated functions that may or may not work, in the documentation for OpenGL 4 there are a lot of this functions that were deprecated during the OpenGL 3.x era that are completely removed from the official reference.

none of this is really true, also you can’t compare the way of doing things with a fixed pipeline with a programmable pipeline, they are 2 totally different approach.

All the major brands that are manufacturing GPUs for the desktop offer support for OpenGL ES 2 with their drivers on desktop OSs such as Windows or Linux, there are also big plans for the OpenGL ES future on desktop for Wayland. There is also the mesa library under Linux in case your GPU is not that good enough.

I’m not thinking in terms of shaders, I don’t care, I’m thinking about making things work, there is no point about producing something with the BGE as it is now, unless you want troubles with your customers or doing something with like 10 years back in terms of technology, so I was asking for the roadmap about this.

Also you can adopt the programmable pipeline in both OpenGL 3.x and newer and in OpenGL ES 2.x and newer, so it’s even better.

I might be horribly wrong on this, since I have never directly worked with shaders myself. If so, please correct me.
But…

What is the point of exposing advanced low-level rendering functions to Python scripts?

Complex 3D scenes should be defined in your .blend and loaded by the BGE at startup, why should they be rendered from Python?
Sure, Python is great for rendering HUDs and other simple dynamic stuff that you can’t describe with matrices and animations. But for HUDs, you don’t need performance: a fixed-function pipeline (no matter how poorly emulated) should be good enough.

Right?

Hi Sinan,

OK, now you got me confused :slight_smile:

I thought that you wrote shaders in GLSL, and then invoked shader.setSource() from Python. I can’t see what this has to do with the Python bgl module and which OpenGL version it supports.

But what you are saying is: you can write shaders directly in Python nowadays? :open_mouth:

Thanks for clarifying that, Sinan.
One more thing, the shader code is sent directly to the driver, right? So which OpenGL/GLSL version Blender uses is then moot, only the end user’s video driver matters?

That makes sense. So the (only?!) reason to support higher OpenGL versions is to create a OpenGL context supporting higher versions of GLSL in the shader pipeline.
Considering what shader wizards like martinsh can already do with the current BGE, I don’t see why the OP’s criticism would be justified.

New upbge uses modern -GL and will soon have vulkan as an option. (when master does)