Godot-proposals: Use OpenGL 3.3 for the low-end rendering backend

[clayjohn]

_edit: see https://github.com/godotengine/godot-proposals/issues/877#issuecomment-633826826 below for updates. Make sure to read both this post and the updates before responding._

Describe the project you are working on:
The Godot engine renderer

The Problem

Describe the problem or limitation you are having in your project:

Implementing new 3D features is becoming increasingly difficult as we try to support modern workflows (e.g. HDR, PBR) while maintaining support for OpenGL 2.1/ES 2.0 devices.

We frequently have to sacrifice quality in our high-end rendering backend in order to support consistent workflows between the high-end (Vulkan) and low-end (OpenGL) backends.

Some common issues that arise:

1. Scenes look very different in GLES3 vs GLES2 because of the use of sRGB vs linear lighting
2. Many optimizations are not possible in GLES2
3. We have to rewrite many parts of core rendering code to support GLES2 devices of varying capabilities
4. Many common post processing and material effects are just not possible in GLES2
5. Common 3D engine features can't work in GLES2, so we don't support them (e.g. terrain, complex particle systems)
6. Our rendering defaults have to be compatible with GLES2 and GLES3, leading to poor quality default scenes overall

Compatibility with older Devices

Right now the GLES2 backend serves 2 purposes:

1. Compatibility with older devices that only support GLES2
2. Providing a lower-end renderer for lower-end devices and for users who value speed over modern features

When we decided to add the GLES2 backend many devices only supported GLES2. At the time, 40% of Android devices only supported GLES2. Thankfully that is no longer true.

OpenGL 2.1/ ES 2.0 only devices are becoming increasingly rare. On Android over 85% of devices now support GL ES 3.0 or higher. On iOS, every device supports ES 3.0. On Desktop the overwhelming majority of devices support GL 3.3+ (more than 99% support at least GL 3.3 according to the Steam hardware survery)

As a result of the rapid adoption of OpenGL/ES 3.x+ the main purpose served by the GLES2 renderer is as a low-end renderer to maximize speed on high and low-end devices. Many users that are choosing to use GLES2 currently are not doing so because their device doesn't support OpenGL 3.3, they are doing so because their device doesn't like the high-end features that are in the Godot GLES3 renderer.

The Solution

Describe the feature / enhancement and how it helps to overcome the problem or limitation:
I propose dropping GLES2 support for 3D. For 2D, we can still use GLES2, but when 3D features are used, we will require GLES3.

Given that the main purpose behind the OpenGL backend will be supporting low-end devices, we will write the GLES3 renderer to target low-end devices. This means it won't have the feature set that that Godot 3.2 GLES3 renderer has, but it should run even faster than the current GLES2 renderer and look much better.

This change will both increase the perceived speed and quality of the low-end renderer, but it will also make development much smoother.

What this allows us to:

1. Standardize workflow between high-end (Vulkan) and low end (OpenGL) backends. This means you can expect a more uniform look when switching between backends.
2. Implement optimizations not present in GLES2 (using instancing, texture arrays, and transform feedback)
3. Have similar lightmap workflow between backends
4. Greatly simplify our engine code which makes maintaining the engine easier
5. Extend more post-processing/materials to the OpenGL backend
6. Support more high-end features that have become standard in 3D engines (e.g. terrain, physical light units, HDR)

The one issue with this proposal is WebGL. WebGL 2.0 is not supported well yet. We will either have to work out a sort of compatibility mode for WebGL, or wait for more widespread adoption of the WebGL 2.0 API.

If we do drop 3D support for GLES2 in 4.0, it will mean that we will have to work harder to support 3.2.x for a long time. Users will still be able to make and export games using Godot 3.2.x and critical bugfixes will still be merged for 3.2.x. This seems to be a fair trade off. If the GLES2 renderer is ported to Godot 4.0, it won't have access to any of the additional features that come with 4.0.

One of the factors we considered when moving to Vulkan was the poor quality of OpenGL ES 3.0 drivers on mobile. At this point, OpenGL ES 3.0 drivers support seems to have improved substantially. Further, basic features are supported very well in the OpenGL ES 3.0 drivers. By limiting ourselves to a limited feature set (closer to GLES2) then we won't bump up against any of the features that are poorly supported by the drivers and we should be able to avoid any of the major problems we had before.

Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:
_This section is edited based on comments below_

User will be able to choose between 4 backends:

1. High-end (Vulkan)
2. Low-end/mobile (Vulkan)
3. GLES3 (more limited than current GLES3 backend, similar feature set to current GLES2 backend. Aims for maximum compatibility)
4. GLES2 (2D only to start, may support very basic 3D eventually)

If this enhancement will not be used often, can it be worked around with a few lines of script?:
No.

Is there a reason why this should be core and not an add-on in the asset library?:
Yes, this has to do with core engine functionality

[DavidHusicka]

How does adoption of Vulkan looks like on mobile devices? Iirc, the Khornos Group stated that all hardware capable of OpenGL 3 should be capable of Vulkan and it's just question of drivers. If it's the same as OpenGL 3, then porting the OpenGL 3 renderer could be just replaced with Vulkan and there would not be need for OpenGL 3.

I kinda fancy the idea of having OpenGL 2 just for 2D since it's just a compatibility option and is not really good at 3D.

Also, I'd like to notice that there is pretty big community of people using cheap secondhand Thinkpads with Linux. These laptops are capable of only OpenGL 2. This might be just a really little minority of userbase. I have no idea how many people with Thinkpads using Godot are there. If it happens, then in the editor should be icon stating "You device is not supported for rendering 3D" when user with only OpenGL 2 tries to open 3D.

[Rexxilion-ex]

What about WebGL1? Only the most current devices support WebGL2. Personally I want to make 3D games for very old computers since where I'm from a lot of people have very old computers.

If you drop it I hope you find a way to make WebGL1 work, or make the next Godot 3.2 version LTS.

[vnen]

@Rexxilion-ex

What about WebGL1? Only the most current devices support WebGL2. Personally I want to make 3D games for very old computers since where I'm from a lot of people have very old computers.

If you drop it I hope you find a way to make WebGL1 work, or make the next Godot 3.2 version LTS.

This is already noted in the proposal:

The one issue with this proposal is WebGL. WebGL 2.0 is not supported well yet. We will either have to work out a sort of compatibility mode for WebGL, or wait for more widespread adoption of the WebGL 2.0 API.

If we do drop 3D support for GLES2 in 4.0, it will mean that we will have to work harder to support 3.2.x for a long time. Users will still be able to make and export games using Godot 3.2.x and critical bugfixes will still be merged for 3.2.x. This seems to be a fair trade off. If the GLES2 renderer is ported to Godot 4.0, it won't have access to any of the additional features that come with 4.0.

[clayjohn]

@DavidHusicka

How does adoption of Vulkan looks like on mobile devices?

On newer devices it is great! We hope that the Vulkan Mobile renderer will be sufficient for most mobile devices. However, older devices definitely do not support vulkan. And there is a significant amount of mobile devices that don't support it.

Also, I'd like to notice that there is pretty big community of people using cheap secondhand Thinkpads with Linux. These laptops are capable of only OpenGL 2.

If you have more information about this, I'd love to hear it. All the hardware surveys I have found say that more than 99% of desktop computers support OpenGL 3.x+.

If there really is a significant portion of users that only have OpenGL 2.1 only devices, then we would have to consider using GLES2 instead of GLES3.

That being said, if we go this route, we will have to plan on having long term support for Godot 3.2, So those users may be better off just using Godot 3.2 anyway.

[Rexxilion-ex]

If you have more information about this, I'd love to hear it. All the hardware surveys I have found say that more than 99% of desktop computers support OpenGL 3.x+.

99? I'm not sure about that. I have a laptop from 2010 and it can't run the GLES3 renderer. Where I live most people have computers from that era without dedicated graphics. That survey probably focused on the US and European countries.

Now I feel like I'm hindering progress xD . I would love to keep using Godot but if you feel it's going to be too hard to support GLES2 then drop it.

[DavidHusicka]

Now I feel like I'm hindering progress xD . I would love to keep using Godot but if you feel it's going to be too hard to support GLES2 then drop it.

According to the post above, planned to drop is just 3D for GLES2. You can keep using Godot even after this changes but only for 2D.

If you have any more information

Here's link to the Thinkpad community on Reddit. I have no idea how many people with ThinkPads use Godot but this community engage in OSS quite a lot. I've seen many people from this community online.

[DriNeo]

One of the factors we considered when moving to Vulkan was the poor quality of OpenGL ES 3.0 drivers on mobile. At this point, OpenGL ES 3.0 drivers support seems to have improved substantially.

This is an important topic. The GLES3 situation was terrible at the Godot 3.0 release time. Even if a mobile device officially support GLES3 there was no guarantee that Godot can be launched.. Please be sure most devices really support GLES3 reliably.

[clayjohn]

@Rexxilion-ex

99? I'm not sure about that. I have a laptop from 2010 and it can't run the GLES3 renderer. Where I live most people have computers from that era without dedicated graphics. That survey probably focused on the US and European countries.

The survey is from the Steam hardware survey (linked above), the second and third most prominent locations were Russia and China. The survey is a bit biased towards people who play video games, but for our purposes that is a good thing.

I have a laptop from 2010 and it can't run the GLES3 renderer.

Is the issue that you can't run the GLES3 renderer, or that your computer doesn't support OpenGL 3.3? I would be surprised if your computer didn't support OpenGL 3.x (released in 2008). If you read the above proposal you would see the importance of distinguishing between hardware API support and support of low-end devices. Just because your computer is too low-end to support the Godot GLES3 renderer, doesn't mean that it isn't capable of running OpenGL 3.x. The intention behind this proposal is that we would write a GLES3 renderer much the same as the current GLES2 renderer, so that it would be fast enough to run on any device that supports OpenGL 3.x.

[Zireael07]

Iirc, the Khornos Group stated that all hardware capable of OpenGL 3 should be capable of Vulkan and it's just question of drivers.

I wouldn't be so sure it's actually as nice as described, given the hash some manufactures (cough Adreno cough) made of OpenGL 3 support on mobile.

[Janders1800]

Drop GLES2, I don't want Godot to turn into another openGL (In the meaning that for shake of compatibility they suffered in new features and slowly turned into a bloody mess, ergo Vulkan was born)

[reduz]

1) We are _not_ going to drop GLES2, it's not a problem to port it and maintain it.
2) One alternative could be to eventually support only _very_ basic 3D in GLES2 (objects, lights, shadows, etc) and improve support over time, though at low priority. 2D is easier to support because API did not change much since Godot 3.x.

[Madaraz1024]

why not OpenGL 4.6 last? I have a PC old 2010 Godot 3.X used GLES 3.0 TPS demo lags very much and the other engine is UE4/Unity rendering OGL 4.6 everything works fine no lags

my old video card NVIDIA GeForce GTS 450

GLES 3.0 -> OpenGL 3.3 very sad

[Zireael07]

"Low-end rendering". OpenGL 4 is DEFINITELY NOT low-end!

[Madaraz1024]

Mobile support GLES version

Vulkan only support Android 9.X Pie and higher

[lawnjelly]

2. One alternative could be to eventually support only _very_ basic 3D in GLES2 (objects, lights, shadows, etc) and improve support over time, though at low priority. 2D is easier to support because API did not change much since Godot 3.x

Just to mention that as supporting older hardware is much more my interest than I suspect @clayjohn or @reduz :grin:, I'd be prepared to get this working (with some minimal support from the IDE regarding materials). :+1:

[arusenpai]

"Low-end rendering". OpenGL 4 is DEFINITELY NOT low-end!

To me, GL 3.0 is the optimal "low-end" spot for years to come.

[Madaraz1024]

need GLES 3.X for mobile 3D, GLES 2 is suitable for 2D games

[Galomortal47]

no please now, i use GLES 2 daily for mobile games and low end pc games, it works well on browsers which GLES3 doesn't, GLES 3 is useless because it neither has the backward compatibility or light weight of GLES 2 and neither the high end graphical fidelity of VULKAN

[DavidHusicka]

Vulkan only support Android 9.X Pie and higher

Not true, Vulkan 1.1 is Android 9 and higher and Vulkan 1.0 is Android 6 and higher iirc

[Galomortal47]

Now I feel like I'm hindering progress xD . I would love to keep using Godot but if you feel it's going to be too hard to support GLES2 then drop it.

According to the post above, planned to drop is just 3D for GLES2. You can keep using Godot even after this changes but only for 2D.

If you have any more information

Here's link to the Thinkpad community on Reddit. I have no idea how many people with ThinkPads use Godot but this community engage in OSS quite a lot. I've seen many people from this community online.

i still use 3D features of GLES 2, to make 2.5 D game

[Rexxilion-ex]

Is the issue that you can't run the GLES3 renderer, or that your computer doesn't support OpenGL 3.3? I would be surprised if your computer didn't support OpenGL 3.x (released in 2008). If you read the above proposal you would see the importance of distinguishing between hardware API support and support of low-end devices. Just because your computer is too low-end to support the Godot GLES3 renderer, doesn't mean that it isn't capable of running OpenGL 3.x. The intention behind this proposal is that we would write a GLES3 renderer much the same as the current GLES2 renderer, so that it would be fast enough to run on any device that supports OpenGL 3.x.

It has an Intel GMA HD (form an intel i5-520M), it supports DirectX 10 and OpenGL 2.1. There are a lot of 2010 laptops without dedicated graphics, so none of them can run GLES3 Godot games.

[Galomortal47]

there are many student computers out there in universities and courses, where the computers are old dual core celerons who only support gles 2, if godot drops support for gles 2 i won't be able to teach about godot on those places anymore (i had made lecture about introduction to godot before), and would have to go back to construct or multimedia fusion

[dsnopek]

I think Godot 4 having wide support for HTML5 should be a high priority. My biggest challenge is always getting people to play my stupid little games so I can get feedback and grow as a game designer. My solution to that is that I mostly target HTML5, because folks are way more inclined to follow a link and play, than to download a build.

In my experience, GLES3 only seems to work on Chrome, but GLES2 works on almost every browser. I'm fine with my games having lower quality graphics, if we just say "OK, GLES2 is supported, but it looks pretty bad." But I'm not OK with saying "GLES2 is for 2D only" because I like to make little 3D games too!

Of course, we can hope that browser support for GLES3 / WebGL 2 will improve over time, but I can't imagine it getting dramatically better on the current timeline for Godot 4...

[clayjohn]

Update

I have updated the proposal to reflect @reduz's comment and to clarify that GLES2 is not going to be dropped. GLES2 will be 2D-only to start. Instead of automatically switching between a GLES2 and GLES3 context, I have updated the post to reflect that they will be two distinct backends, with GLES2 only supporting 2D to start.

Further Questions

I'm hearing a lot of support for maintaining a GLES2 backend. What I would appreciate more clarity on is whether users who are using GLES2 to target HTML and ultra-low-end platforms are shipping 3D games?

[Schroedi]

What I would appreciate more clarity on is whether users who are using GLES2 to target HTML and ultra-low-end platforms are shipping 3D games?

Especially for game jams, HTML is crucial. Not many people want to download a game to rate it. Our team uses Godot to build 3D HTML games, particularly because it's fast HTML export. The turnaround speed is a significant advantage over other game engines I worked with (Unity and Unreal).

[dsnopek]

What I would appreciate more clarity on is whether users who are using GLES2 to target HTML and ultra-low-end platforms are shipping 3D games?

Maybe not "shipping" 3D games, but definitely creating and sharing and collaborating on 3D games targeting HTML5!

[phantomdesvin]

Go for it. GLES 3 is going to be supported by almost every device, and also that minority that want to play a game on an old device is going to look for a 2D game most of the time, that will be supported on GLES 2. When I had an old movile I wasn't looking for the next 3D battle royale on the playstore to be able to play it at 2 frames per second.
Also honestly I trust you guys more than myself.

[vagrantG]

I'd lean over the option of an all around but simplified GLES 2 support because a mixed solution (GL 3.x for something, GLES 2 for the rest) not only is a desktop only solution (doesn't export to WebGL if you do 3D, no support 3D for old mobile devices) but seems quite more work than thinking about a system that disable features from the rendering device used. Plus not sure about how buggy is GL 3.x on older integrated GPUs and if it's like GLES 3 that seems to work slower compared to GLES 2 on some hardware.

Still i don't know how good is supporting something that is a bit out of place in a newer design of the renderer, dodging/downgrading many features (from a programming standpoint inside the engine to the game developer one that will need to use an editor with many things disabled, performance issues and things to consider to make it work like lighting that isn't as intented, etc). Maybe focusing on GLES3 and Vulkan as the only options for 4.x and make users use the 3.x engine if the hardware is too old would make more sense.

Not to exclude people with old hardware you could go for a full GL3.x renderer so that they can work "on par" feature wise and then export to WebGL 2, GLES 3 on mobile, etc. No more GLES 2 or WebGL but a least they can work on things with the lastest version of the engine. But if with GL3.x you still need to cripple too many things i don't think it does make much sense to do it.

Another idea is having an unofficial GLES 2 renderer and make it so that it can be an external library to load instead of having to build the entire engine to use it. The community that is interested in continuing that support could contribute, implementing only the features that they want to use without the editor/engine having to cripple itself officially to mantain back compatibility with default values, etc. Maybe only a basic filtering of unsupported things commanded by the renderer could be done officially or default values read from the renderer classes?

[avencherus]

99? I'm not sure about that. I have a laptop from 2010 and it can't run the GLES3 renderer. Where I live most people have computers from that era without dedicated graphics. That survey probably focused on the US and European countries.

I would echo this sentiment.

These surveys are not of any reassurance, when one sends their game to a friend, and they tell you it doesn't run. And the reason ends up being because their laptop or older machine doesn't support X version of OpenGL or even that they're on a 32-bit system.

I also recall not being able to run any of the Godot web games that came out of the 3.0 era, because of web gl2 complaints on my machines. Still happens occasionally.

[Mautar55]

I reeeeally support this! Mostly because my laptop only supports OpenGL4 and my pc OpenGL3. (mine and most people I know). Godot is one of the last engines supporting old gen hardware. (At least last one with a stable development and a wide range of features).

[Madaraz1024]

@clayjohn https://apkpure.com/3drating-for-opengl-es-2-0/com.antutu.ABenchMark.GL2 gles 2 3D is good but FPS depends on mobile

download game and test mobile FPS for GlesES2 :)

[Rexxilion-ex]

https://apkpure.com/3drating-for-opengl-es-2-0/com.antutu.ABenchMark.GL2 gles 2 3D is good but FPS depends on mobile

download game and test mobile FPS for GlesES2 :)

That's basically the amount of quality I'll aim for, GameCube and PS2 era graphics, so most people with a computer can play them (and also for nostalgia purposes).

It should also be noted that those Steam surveys don't count people with old PCs that only game in consoles, I'm sure they'd be willing to try a PC game if they only could find one that ran well on their PCs. I have friends with current-gen consoles but still have crappy PCs they only use for homework or to play the occasional League of Legends match.

[mhilbrunner]

OpenGL 2.1/ ES 2.0 only devices are becoming increasingly rare. On Android over 85% of devices now support GL ES 3.0 or higher

Godot 3.0 came out 2.5 years ago in January 2018.

Back then, we already moved to GL ES 3.0 - so the marketshare wasn't deemed (enough of) a problem at first, even then.

But we quickly discovered that while tons of devices report to support GL ES 3.0, the reality is more complicated - tons of devices are buggy, have bad performance or are plain broken with GL ES 3.0.

If we again move to GL ES 3.0, we should try to gauge whether this time the support is really there, not just in "is supported" statistics, but how stable and usable that support is on actual devices.

The other risk to me is at the very end of the post: worst case, we now have 4 backends to support instead of 2.

That could also cost us in terms of testing, having to implement features 4 times at worst, and issues only cropping up in combination with only certain backends.

Sure, thats an issue now too, but I worry if we double our test matrix by having 4 instead of 2 backends, there will be a lot more of that.

[Note that I'm not for or argainst, and think this proposal is well-written. :) I have no opinion yet, but these are the two immediate risks that came to mind. I agree the current situation needs improvement, and this could be a way to do that.]

[Janders1800]

4 backends is going to be a hell to maintain, and a hell to new contributors to get into.

[dsnopek]

I did very minimal research about this, but I did find a WebGL 2 polyfill which attempts to allow you to write code for WebGL 2 while actually using WebGL 1 under the hood for maximum compatibility:

https://openbase.io/js/@luma.gl/webgl2-polyfill

I wonder if something like that could be used to allow the GLES3 backend to run on WebGL 1 in the HTML5 export?

[Akira1San]

Vulkan + gles 2 + extensions is enough to make 3.2 users switch to 4 even with older hardware. Since Vulkan is the future even some mobile games are using Vulkan.

[2plus2makes5]

The way i see this:

1)those who want to work with GLES 2.0 are aiming to old hardware, so they realistically can't expect newer effects and tecniques.

2)Exactly like now people can still use Godot 2.1(.5?) when Godot 4.0 will be released those who want to use GLES 2.0 can keep using Godot 3.2.

3)When Godot 4.0 will be released those statistics for GLES 2.0 will be even lower.

So i think that Vulkan + GLES 3.0 could be the right way to go for Godot 4.0.

[ghost]

tl:dr: vulkan technically runs on opengl 3.1 devices, so opengl 3.3 would just be redundant, and if anything, it would be worse off in a lot of ways? vulkan already does the job for opengl 3 and above, opengl 2 might be needed for older hardware, as they don't have support for some weird math operations vulkan needs to do?

---

it would be nice to have it be all vulkan but apparently older graphics cards don't have support for... some stuff i don't really understand much about (something about, older graphic cards, not supporting some kind of, weird math, i don't know)

so uh, from what i read, it would technically be impossible to use opengl 3.3, as anyone else on the lower end would be shafted away, plus it would also be redundant anyway, as vulkan supports opengl 3.1 anyway, so it wouldn't really help anybody

i'm pretty ignorant on the topic anyway, so don't mind me too much

anyway if that's the case then this whole discussion is pointless, since opengl 2 needs to stay for older hardware, and if not, then that's the end of it from what i understood

sorry i haven't read the other replies, i just wanted to figure things out by myself, even if i turn out to be horribly wrong

if it was up to me i would just keep things simple and i would have the whole thing be vulkan only, i mean it's not like old versions of the engine would suddenly vanish away, but i'm lazy, i'll always go by the path of least resistance if i can save some time

[clayjohn]

@RaTcHeT302 you are confusing OpenGl _ES_ with OpenGl for desktop. Vulkan runs on OpenGL ES 3.1 devices which correspond to OpenGL 4.5 devices. The proposal is for using OpenGL 3.3 on desktop and OpenGL ES 3.0 on mobile. As stated in the proposal, the vast majority of desktop devices support at least OpenGl 3.3, while most mobile devices support at least OpenGl ES 3.0

[Galomortal47]

no, i need GLES2 3D, seriously you guys won't be able to compete with
unreal or unity on terms of graphics, you are sacrificing backwards
compatibility for the cult of graphics, if that happen i will have to
switch to another engine

i moved from unity to godot 3.1 exactly because of GLES 2 support, that
feature was the only reason i moved from unity to godot, i don't even
believe there is being a discussion on the importance of GLES 2 both 2D and
3D support, back 2018 it was already evident that dropping gles2 was a
terrible idea, and the same mistake will be maken again

we only need two vulkan and gles 2

no, those who want gles 2, will switch back to unity, seriously people
won't use old unmaintained software for long

I'm hearing a lot of support for maintaining a GLES2 backend. What I would appreciate more clarity on is whether users who are using GLES2 to target HTML and ultra-low-end platforms are shipping 3D games?

yes i do use GLES 2 to make simple 3D games, not every game is trying to have ultra realistic next gen graphics, some don't need all the fancy new tech because it uses a good art direction instead of just dropping in mega shaders and 8k textures that need a 2000 dollar pc to run

if you want top tier graphics godot isn't even the best option, godot is widely used by indie devs who want backwards compatibility, light weight and good usability

1. We are _not_ going to drop GLES2, it's not a problem to port it and maintain it.

2. One alternative could be to eventually support only _very_ basic 3D in GLES2 (objects, lights, shadows, etc) and improve support over time, though at low priority. 2D is easier to support because API did not change much since Godot 3.x.

i like to be able to instance 3D objects and render them as sprites using a viewport, it helps a lot in 2.5 D game development

[MickeMakaron]

Regarding WebGL2 support. All major browsers except Safari support it. There haven't been any public signals from the Safari devs for years about any upcoming support. Thus it seems unlikely Safari will ever support WebGL2.

However, they do seem to put a lot of effort in WebGPU, as do the other browser vendors. It's looking likely that WebGPU will have more support across browsers than WebGL2.

Firefox devs are hoping to come up with an MVP implementation by the end of 2020. Godot 4 seems to be slated for 2021? Development of a WebGPU renderer in Godot is possible today (#23764).

I know WebGPU is still unfinished, and it may be too much of uncertainty for planning it into Godot 4.

However, I want to point out that WebGL2 support is unlikely to improve, and WebGPU's support is likely to surpass WebGL2's. Thus WebGPU would make both WebGL and WebGL2 uninteresting for the web platform.

[akien-mga]

@Galomortal47 Please try to keep your answers in a single post instead of 6 posts in a row. This thread is difficult enough to follow without spreading feedback over multiple posts all amounting to the same "you're wrong to drop GLES2 for 3D". I'll edit your posts to merge them all into one.

Edit: I understand now that the 6 posts were all email replies to specific earlier posts, but it didn't come out clearly on GitHub as everything ends up in the main thread. Whenever you want to reply to something which is not the last comment, it's advised to use the web interface and use the quote function to properly show what you're replying to.

[KoBeWi]

people won't use old unmaintained software for long

But Godot 3.2 will still be maintained for a long time (even 2.1 is getting updates) and it will keep GLES2. There's no obligation to upgrade to Godot 4.0 if you don't want to. And by the time 3.2 loses support, GLES2 will be even more irrelevant than now.

[Rexxilion-ex]

If you end up ditching 3D GLES2, is there a way to make it an add-on for the community to support? I know you mentioned GLES3 can't be an add-on, but is this also the case for GLES2?

And if that can't be done I hope you can at least back-port some of the most useful features in 4.x versions to 3.2, I know you guys have already added some 4.0 features to 3.2 and that's awesome.

[clayjohn]

@Rexxilion-ex Godot itself is there for the community to support.

If we use GLES2 in 4.0 it won't receive any of the new 4.0 features (that are graphics related). Things that make sense to backport may get backported to 3.2 if we end up dropping GLES2 (this is what we mean by long term support in the proposal)

[Rexxilion-ex]

@clayjohn

If we use GLES2 in 4.0 it won't receive any of the new 4.0 features (that are graphics related).

I know GLES2 won't be able to support the newer features, I'm fine with that, but can you make GLES2 a separate library/add-on or does it have to be tightly integrated with the engine? I was wondering if you could just leave the 3D GLES2 code there without worrying about adapting new features to it, I don't know how much of a pain that would be.

Things that make sense to backport may get backported to 3.2 if we end up dropping GLES2 (this is what we mean by long term support in the proposal)

Oh! Good to know, I thought with LTS you only meant bugfixes. There are some performance features I wish to get like static typing so games run a little smoother on my laptop.

[Mautar55]

The way i see this:

1)those who want to work with GLES 2.0 are aiming to old hardware, so they realistically can't expect newer effects and tecniques.

2)Exactly like now people can still use Godot 2.1(.5?) when Godot 4.0 will be released those who want to use GLES 2.0 can keep using Godot 3.2.

3)When Godot 4.0 will be released those statistics for GLES 2.0 will be even lower.

So i think that Vulkan + GLES 3.0 could be the right way to go for Godot 4.0.

Godot 4 comes with a HUGE ammount of features that make worth he task of porting the project from v3 to v4. Isn't just for the graphics but the LoD, Oclussion Culling, the Pathfinding Server...

[clayjohn]

@Rexxilion-ex the rendering backends cannot be supplied as plugins. They have to be integrated into core.

That is part of the reason we would like to focus on GLES3, because then our core rendering code can avoid having gross hacks in order to support GLES2.

[KoBeWi]

the rendering backends cannot be supplied as plugins. They have to be integrated into core.

Wasn't that what RenderingDevice was made for?

[clayjohn]

@KoBeWi kind of. Only Vulkan-style APIs will work with the RenderingServer.

The idea is that we could add a metal backend, or others can provide a PS4 backend (or any of the other console APIs).

But GLES2 is way too old to work with the RenderingServer API design.

[Galomortal47]

@Galomortal47 Please try to keep your answers in a single post instead of 6 posts in a row. This thread is difficult enough to follow without spreading feedback over multiple posts all amounting to the same "you're wrong to drop GLES2 for 3D". I'll edit your posts to merge them all into one.

_Edit:_ I understand now that the 6 posts were all email replies to specific earlier posts, but it didn't come out clearly on GitHub as everything ends up in the main thread. Whenever you want to reply to something which is not the last comment, it's advised to use the web interface and use the quote function to properly show what you're replying to.

my bad, i was trying to use the email reply function, but its horrible, now i will use the web interface so i won't spam stuff here, sorry man

@Rexxilion-ex Godot itself is there for the community to support.

If we use GLES2 in 4.0 it won't receive any of the new 4.0 features (that are graphics related). Things that make sense to backport may get backported to 3.2 if we end up dropping GLES2 (this is what we mean by long term support in the proposal)

i'm ok not having new features on the old 3D render, like i just want to be able to render 3D models on gles 2 so i can use a viewport to render as 2D sprites, they are essential to make good looking 2D games

people won't use old unmaintained software for long

But Godot 3.2 will still be maintained for a long time (even 2.1 is getting updates) and it will keep GLES2. There's no obligation to upgrade to Godot 4.0 if you don't want to. And by the time 3.2 loses support, GLES2 will be even more irrelevant than now.

people trough the same thing back from 2.1 to 3.0, they where wrong, and had compatibility issues with cellphones, old pcs and web, i had those issues, i couldn't lecture godot to students, and i couldn't show off my games on my mobile phone, gles 2 was implement on 3.1 to compensate the lack of compatibility from gles 3, removing it again would be committing the same error twice, it was one year of work just implementing this thing, and now is being discussed if it should be thrown away, literally wasting one year of work

for two years i only lurked the development of godot engine, and never worried about vocalizing myself, but now i'm worried

[clayjohn]

Feedback

First of all, thank you everyone for providing feedback! I have read every comment, even if I didn't respond directly to you. Hearing so many different thoughts is incredibly helpful for us deciding what to do.

Main concerns

WebGL

I am hearing that a lot of people need strong web support, even for 3D games. Especially for people who are participating in game jams and who want to make simple, but widely shareable games. You don't want to be stuck in 3.2. I hear you and I know you want to take advantage of other new things coming to 4.0 like typed GDScript.

WebGL2 is kind of a wild card for us. We hope that safari will support it in the near future, but we can't count on them supporting it. We hope WebGPU will supersede WebGL2 by the time Vulkan released, but we can't be certain that it will. So it makes sense for us to maintain some sort of support for WebGL as best we can. Regardless of what we end up doing, we will be investigating ways to support Web as best as possible.

Driver support

A few people have mentioned poor driver support (likely thinking of this article), I would like to take a moment to address why we don't think it is will be an issue.

As explained in the post above, the vast majority of devices support OpenGL 3.3 / ES 3.0. By the time 4.0 releases we expect that the number will be even more overwhelming. Supporting an API is different then supporting it _well_. As we saw with the current GLES3 renderer, many devices had issues due to bad drivers.

The current GLES3 renderer was mean to be a high-end renderer. We had hoped to provide something with all the fancy bells and whistles users expect out of a modern renderer. However, we found that when we pushed OpenGL 3.3 to the max, the drivers pushed back. Many devices (especially mobile) advertised support for GLES3, but actually only supported the core well. The more advanced features were buggy.

We are confident that by sticking to core features and implementing a simple renderer design (much like the current GLES2 renderer), we can avoid any driver headaches and actually optimize the renderer beyond the current GLES2 renderer. That being said, it will be similarly limited to the current GLES2 renderer in some ways.

Old hardware

We have heard support from a few people that they are still using 10+ year old devices which do not support OpenGL 3.3. Many of those devices _do_ support OpenGL 3.3, they just don't support Godot's "high-end" GLES3 renderer. By implementing a much simpler renderer, we hope to extend support to all devices that support OpenGL 3.3/ ES 3.0. This means many people who cannot currently run the GLES3 renderer in Godot 3.2 will be able to run the GLES3 renderer in Godot 4.0.

Keep in mind, a GLES2 port in 4.0 will not have the advanced graphics features that the Vulkan backend will. In GLES2 there won't be occlusion culling, real-time GI, or GPU particles.

Proposed Update

Based on the feedback and some discussions with other contributors, I propose the following changes (the post above will be edited to reflect this as well).

Backends

I propose that we have 4 backends:

1. GLES2/Vintage
2. GLES3/Compatibility (3D based off of the current GLES2 renderer design)
3. Vulkan-Mobile
4. Vulkan-High-End

GLES2/Vintage

The GLES2 renderer will start as a direct port of the current GLES2 2D renderer. It is currently optimized for low-end devices. Especially now with the work @lawnjelly has put in implementing batching.

Eventually 3D support will be added. 3D will use an extremely limited renderer design that will be optimized for low-end, mobile, and web. It will likely not allow customizable shaders or many of the fancy effects we are used to. But it will be blazing fast and will run on almost any device.

@lawnjelly initially proposed this design and will hopefully take the lead on implementing it.

GLES3/Compatibility

The GLES3 renderer will be a direct port of the current GLES3 2D renderer. The 3D renderer will be simplified and streamlined to look more like the current GLES2 renderer. This includes using multi-pass lighting instead of single-pass lighting. This will make it very fast for simple games designed to run on the widest set of hardware while still maintaining a more cohesive look with the Vulkan renderer. It will feature fewer features than the current GLES3 renderer.

Maintaining 4 Backends

I know it sounds difficult. My reaction at first was to veto this option as well. However, it is not as bad as it sounds. The two vulkan backends share the same code. reduz's new RenderingDevice API makes it very easy to support two different renderers based on the same Vulkan backend. In the words of reduz "they will share 90% of the code".

For GLES2 and GLES3, the 2D code will be more or less of a straight port. We have been doing a lot of work to improve the 2D code and it will not be lost as we transition to 4.0. The 2D renderer design is fairly close to Godot 3.x so porting and maintaining the code should not be too much of an additional burden. Further, we are committed to maintaining that same code in 3.2.x so the additional burden really is minimized.

For GLES2 and GLES3 3D we are creating a bit of extra work. However, much of the work can be saved from Godot 3.x and the fact that GLES2 and GLES3 are meant to be limited and simple means that they will also be easier to maintain.

Overall, we are comfortable taking on that additional maintenance burden to ensure we are properly supporting a wide userbase and making an engine that is fun, easy to use, and accessible.

Conclusion

Thanks for reading! Keep your feedback coming.

And a special thanks to everyone for keeping everything positive and constructive! There are differing views represented here and at the end of the day, not everyone will be happy with the final decision. But I hope everyone feels they had the chance to say their piece and be heard.

[Zireael07]

In GLES2 there won't be occlusion culling,

Why? The current GLES2 has it AFAICT, and a game without it will be dog slow (especially on mobiles/web, and both of those tend to be much slower than desktop)

[Calinou]

@Zireael07 The current GLES2 and GLES3 renderers don't support occlusion culling. Depth prepass is only feasible with GLES3 and Vulkan, so there's no depth prepass in GLES2 either. That said, nothing prevents someone from implementing a portals and rooms system in GDScript (just like LOD).

[2plus2makes5]

Maybe instead of having a single Godot version trying to make coexist different renderings that limit each other could it be better having 2(or more) different version of Godot each with their own different rendering? They would have the same non-graphical features and the same basic graphical features but the more advanced version would have exclusive advanced graphical features.

[aaronfranke]

Since I don't see it mentioned in this thread, I would like to point out two things:

1. The decisions made here don't actually affect a released version of Godot until Godot 4.0 is released. So it's not just about what the market currently supports, but also a question of what the market will look like after 4.0 is released in 2021 or 2022. So, for example, if the goal is to support devices that are 10 years old, then we should be targeting devices from 2011 or 2012, not 2010.

2. If an older API is dropped, you always have the option to simply use an older version of Godot. Godot 3.2 will continue to run for many years to come, and will likely continue to have critical fixes backported to keep it working on Android, like has already happened with Godot 2.1.

[Mautar55]

@2plus2makes5 Expect the developers to make that kind of choices as they see fit. I'm sure they will not make a decision that could harm the development. Also, duplicate the number of versions because of C# and prepare export templates for each single version in each release could complicate things.

@aaronfranke r1: If someone don't replace a device for 10 years maybe they won't replace it for the next 2 or even 4. Some people are using Godot for Raspberry Pi (ES2).
r2: Is there a spec of how much is going to be mantained? Or if new features are going to be added? I don't want to speak loose.

[Calinou]

@Mautar55 The GLES2 renderer will remain to support 2D at least, which means the Raspberry Pi can still be supported this way. (Also, the Raspberry Pi 4 supports GLES3 and has a Vulkan driver in the works.)

The 3D GLES2 renderer was already too slow on the Raspberry Pi to be usable most of the time anyway.

[2plus2makes5]

The truth is that no matter what will you decide, there will be people that won't be happy, it's the nature of changes, the will to make everyone happy usually doesn't lead to good results, sometimes you need to make things your own way, remember what Henry Ford (may or may not) have said:
"If I had asked people what they wanted, they would have said faster horses."

Honestly even with lots of common code 4 backends seems overkill to me, they mean more bugs, more time to fix them, more time for new features to be added, more testing, some people could be confused at what a backend can do and which one to use and so on, they would slow down and burden the evolution of the engine.

If you really want to have many backends at least don't start from their technology but from their use, so there's no overlap and it's cristal clear which one to use, one example could be: high end desktop, low end desktop, mobile, web.

[clayjohn]

@2plus2makes5 I really like the idea of naming based on purpose. Personally I see the backends like this:

1. Web (GLES2)
2. Low-end (GLES3)
3. High-end mobile
4. High end desktop.

[Zireael07]

Yeah, naming based on purpose would solve a lot of the possible confusion and would make it clear which backends are high-end.

[Rexxilion-ex]

@clayjohn
I appreciate that you considered leaving 3D support on GLES2, thank you! Looking forward to version 4.0 😁

[asheraryam]

I can confirm that for Raspberry PI, 3D is unusable even with GLES2. However we were able to ship a project with 2D GLES2 using an underclocked 3A+ running at potato mhz.

(Even with 2D in GLES2, it has issues with texture memory which need to be worked around with tricks)

[swarnimarun]

Alright, this is gonna be long, I dove into Graphics Programming relatively recently, and am not an expert or affiliated with any organisation or am not even the authority in Godot. (So please correct me if I am wrong somewhere)
But I am a relatively neutral party.

Just skip to the end there is a TLDR; there. (Though if you are new to Graphics Programming or a person relatively outside the technical circles I recommend you read along)

So let's first start with taking care of the misconceptions here

What is GLES?

Embedded Systems subset of OpenGL, just to be clear, it is rarely 1:1 match with OpenGL so it's hard to comply with it 100% without some needless banging your head on the wall scenarios.
So while I like the simplicity of the title I think we can make it a bit more clear what it means.

| GLES | GL(superset) | GL(inspired from) | Android Support |
|------|---------------------|----------------------------------------------|-----------------|
| 2.0 | 4.1 (don't ask why) | 2.0 (but some stuff from 3.0) | 2.2+ |
| 3.0 | 4.3 | 3.3/4.2 | 4.3+ |
| 3.1 | 4.5 | at this point both are pretty much at parity | 5.0+ |

What does supporting GLES3.0 for low-end mean?

It means, we will be able to get more performance optimizations, for the non-graphics programmers, it shall be the difference between Python and C/C++.
As for the low-end part, it means that GLES3.0 is a high-quality renderer, with much less focus on performance than on quality which will change. So, by all means, GLES3 renderer will be much faster than anything possible with GLES2(or so I hope). Again imagine RTX on/off, we are about to turn RTX off for GLES3.0.

WebGL 2 support sucks and it is dead?

Not really, it's supported as widely as required(not sure about you but I don't expect anyone to use IE 11 to play my 3D games or even 2D), the only exception being Safari.
Now some people say Safari will never add WebGL 2, honestly maybe but I don't think that's likely. Compared to adding WebGPU supporting WebGL 2 isn't much harder for first.
And secondly, https://trac.webkit.org/wiki/WebKitGoalsfor2020 lists the Goals for 2020 for WebKit which has WebGL 2 in it.
So there is good chance WebGL2 support will be there by the time 4.0 rolls over. (As I don't see 4.0 releasing in the next few months)

What if I don't care and I want GLES2 renderer anyways?

Godot 3.2.x series will be well maintained for a long while. As for if the GLES2 renderer will or will not see any improvements that would depend on if we have someone who picks it up.
Again if you want to see improvements on it you are welcome to contribute or motivate someone else to help. (everyone starts at someplace)
Still, as the opinions of the @clayjohn have swayed in favour of not removing GLES2, maybe having no 3D will have to do for a while. Though I am not quite sure about the burden being minimal part...
So, expect probable delays if someone gets busy with something else.
Please consider Godot is an Open-Source engine there is only so much the core devs can and should focus on.

Raspberry Pi 3B/B+ support?

I have an RPi, I have built Godot on it, I have tried running the Godot Editor on it, doesn't really inspire confidence in it ever being usable.
For 2D with custom optimizations for RPi memory constraints, we could probably make it run properly but I won't have many hopes for any kind of well-textured 3D scenes with playable performance.
And for Raspberry Pi 4 pls get a 2-4GB variant if you want to be able to game on it though.

NOTE: Now you can jump to tldr; if you don't want to read my ideas.

What changes do I wish for in the proposal?

Move the GLES3.0 to GLES3.1 support with backwards compatibility for GLES3.0

yeah if you didn't get the hint from above already.. :P

Why?

Compute Shaders
Most Android devices support GLES3.1 and a large majority of desktop systems.
So it makes sense to perhaps just for Compute Shaders we can have GLES3.1.

I am currently in the process of writing a proposal for the addition of GPU Compute API for Godot. (if some wants to help, I am on twitter @swarnimarun and discord Godot group with handle of steincodes)

I would have said that OpenCL would be the best alternative but, implementing and maintaining that would have to be pushed as a long-term goal whereas using Compute Shaders would be much easier(or so I believe).
And there is the issue of lack of implementations, just RPi4 not having OpenCL implementation but GLES3.1(god thank Mesa devs) is enough to push this forward(again, or so I believe).

Rewriting/Optimizing GLES2 backend if it is to be maintained for the lowest of the low-end embedded devices

Like my example with RPi3 or RPi0 before.
This one is quite self-explanatory, even if it's just the 2D it will be enough for say making retro games, simple GUI applications, Godot is a pretty nice option for embedded because of its simplicity and self-contained nature.

Because I don't think otherwise we can justify GLES2 support in the long term, which is what I expect 4.0 to be, a long term supported version.

I also have some optimization ideas for it for GLES2, but I will discuss them later, in a separate proposal.

tldr;

GLES != GL in versions
GLES3.0 support for low end means a faster GLES3.0 renderer
WebGL 2 is not dead and it will hopefully be there in WebKit by year-end.
Godot doesn't really run well on RPi3.
Please let's do GLES3.1 with backwards compatibility to GLES3.0 for Compute Shaders.
If we do GLES2, let's make it much faster for embedded and lowest of the low end systems.

It took me like 20 minutes to format this after writing, hope it was fun for everyone. :3

[swarnimarun]

Just for extra details, RPi3 has VC4CL which an OpenCL implementation, quite nice.
So maybe soon or someday RPi4 will have OpenCL implementation as well.

[swarnimarun]

@Zireael07 The current GLES2 and GLES3 renderers don't support occlusion culling. Depth prepass is only feasible with GLES3 and Vulkan, so there's no depth prepass in GLES2 either.

@Calinou I remember we have, EXT_occlusion_query_boolean for GLES2.0 can't we use it for basic culling, at least doing software based culling using it. Though I have a feeling that it's a dumb question.

Repeating myself, I dove into Graphics Programming relatively recently so sorry if my question is totally absurd.

[Lexpartizan]

I came here to resent throwing support for GLES 2.0. But I've read the arguments and I think it's the right thing to do if it simplifies and reduces the codebase. Because you always have to sacrifice something. Of course, we would like to avoid this, but we must be realistic. The fact that GLES 2.0 and GLES 3.0 can't work with the Rendering Device is bad news. I understand that a separate code base is required to support them in the engine itself.

If we talk about old computers, then even godot 2 does not support win XP, which is still found (mainly in government institutions). So I don't see a particular problem in rejecting gles 2.0. Unfortunately, there are a lot of laptops with old video cards, and this is a problem. Well, everything ends at some point. He also came to these laptops.

WebGL 1.0 is real problem. I would even prefer to drop support for gles 3.0 than gles 2.0.

If we talk about long-term support for godot 3, we would first of all like to see improvements in gdscript, JIT, etc. I'm afraid this will take a lot of effort to port.

I believe that developers should make a strong-willed decision. Because as a refusal to support Gles 2.0 in any case will cause resentment of the community. Just as limiting the functionality of the limited gles2 will also cause an equally negative reaction.In addition, many will not be aware of the compromise and will attribute this to the limitations of the engine. This could be a bad thing.

[aaronfranke]

@Lexpartizan If we talk about long-term support for godot 3, we would first of all like to see improvements in gdscript, JIT, etc. I'm afraid this will take a lot of effort to port.

Such things will never happen in 3.x. The whole point of making new versions is to add new features. If you want new features, you need to upgrade to a newer version.

Old versions of software will often get bug fixes to ensure it continues working, for the purpose of ensuring existing projects continue to work. Anything more than this is missing the point of maintaining old versions, and has the potential to break what's supposed to be a stable release. It is completely unrealistic to expect 3.x to be maintained as if it's "4.0 but without Vulkan".

[swarnimarun]

@Lexpartizan For the most part all the functionality in 2D can be more or less be achieved with GLES2.

The problem is GLES2 3D. but anyways @lawnjelly did some cool batching stuff in GLES2, which seems to be batching just rects through deferred shading... hmmm...
https://github.com/godotengine/godot/blob/9aeb9ea826cb7ae939fe25366368e42fc85b52fa/drivers/gles2/rasterizer_canvas_gles2.cpp#L588

Then there is the fact that WebGL 1 also supports a bunch of extensions, just noticed that sadly Instancing is again not supported on Safari(but it's supported on IE 11)...
I am starting to feel a bit cheated from Apple here. Can I say screw Safari?

Anyways hopefully things will change soon or someday or .... _sigh_

[Lexpartizan]

The problem is GLES2 3D. but anyways @lawnjelly did some cool batching stuff in GLES2, which seems to be batching just rects through deferred shading...

GLES3 batching now touch wood seems to be completely working, no regressions visible.

https://twitter.com/lawnjelly/status/1264820004215762946

[SIsilicon]

It's awesome to hear that you guys are considering to keep Opengl 3.0 for a little while longer. But then I read how you are also considering downgrading it. Have you thought of what features it would be stripped of compared to the current implementation?

[swarnimarun]

@Lexpartizan yep seems like GLES3 batching patch will soon be ready for a PR.
It's pretty much the same as GLES2 batching(as per his tweets literally the same code).

---

As for @SIsilicon I wrote it above an will quote it again it's NOT a Downgrade.

it means that GLES3.0 is a high-quality(fidelity) renderer, with much less focus on performance than on quality which will change. So, by all means, GLES3 renderer will be much faster than anything possible with GLES2(or so I hope). Again imagine RTX on/off.

Features that can be optimized will likely be optimized, ones that are too much of a bottleneck will be avoided or gated in settings, and so on.

The part about it being for low-end is in contrast to Vulkan renderer which will have higher end features.

If you take a look at,
https://docs.godotengine.org/en/stable/tutorials/misc/gles2_gles3_differences.html

Most things are, features you get by default with gles3, only ones that might be affected would be PBR/SpatialMaterial, GPU Particles(very likely can be optimized though I haven't seen the code), GIProbes and Lighting/PostProcessing features.

[Lexpartizan]

Common 3D engine features can't work in GLES2, so we don't support them (e.g. terrain, complex particle systems)

This is a very serious argument.

[Rexxilion-ex]

@Lexpartizan

If we talk about old computers, then even godot 2 does not support win XP, which is still found (mainly in government institutions). So I don't see a particular problem in rejecting gles 2.0. Unfortunately, there are a lot of laptops with old video cards, and this is a problem. Well, everything ends at some point. He also came to these laptops.

WebGL 1.0 is real problem. I would even prefer to drop support for gles 3.0 than gles 2.0.

If we talk about long-term support for godot 3, we would first of all like to see improvements in gdscript, JIT, etc. I'm afraid this will take a lot of effort to port.

I believe that developers should make a strong-willed decision. Because as a refusal to support Gles 2.0 in any case will cause resentment of the community. Just as limiting the functionality of the limited gles2 will also cause an equally negative reaction.In addition, many will not be aware of the compromise and will attribute this to the limitations of the engine. This could be a bad thing.

I hope they keep GLES2, and those of us who want to keep it don't care if it has limited 3D features because we are targeting old or weak devices anyways. But I do agree with you when it comes to bringing compiler (or interpreter or whatever, not an expert) improvements to 3.2, I hope that's part of the long-term support.

[Calinou]

@Rexxilion-ex I'm afraid backporting GDScript changes to 3.2 would be too much work. It will be rewritten from scratch in 4.0.

[Galomortal47]

@2plus2makes5 I really like the idea of naming based on purpose. Personally I see the backends like this:

1. Web (GLES2)

2. Low-end (GLES3)

3. High-end mobile

4. High end desktop.

would be great 4 backend, but i fell if one the devs want to cut one of them, GLES3 is the middle man that don't serve as much of a function as the other ones

Alright, this is gonna be long, I dove into Graphics Programming relatively recently, and am not an expert or affiliated with any organisation or am not even the authority in Godot. (So please correct me if I am wrong somewhere)
But I am a relatively neutral party.

Just skip to the end there is a TLDR; there. (Though if you are new to Graphics Programming or a person relatively outside the technical circles I recommend you read along)

So let's first start with taking care of the misconceptions here

What is GLES?

Embedded Systems subset of OpenGL, just to be clear, it is rarely 1:1 match with OpenGL so it's hard to comply with it 100% without some needless banging your head on the wall scenarios.
So while I like the simplicity of the title I think we can make it a bit more clear what it means.
GLES GL(superset) GL(inspired from) Android Support
2.0 4.1 (don't ask why) 2.0 (but some stuff from 3.0) 2.2+
3.0 4.3 3.3/4.2 4.3+
3.1 4.5 at this point both are pretty much at parity 5.0+

What does supporting GLES3.0 for low-end mean?

It means, we will be able to get more performance optimizations, for the non-graphics programmers, it shall be the difference between Python and C/C++.
As for the low-end part, it means that GLES3.0 is a high-quality renderer, with much less focus on performance than on quality which will change. So, by all means, GLES3 renderer will be much faster than anything possible with GLES2(or so I hope). Again imagine RTX on/off, we are about to turn RTX off for GLES3.0.

WebGL 2 support sucks and it is dead?

Not really, it's supported as widely as required(not sure about you but I don't expect anyone to use IE 11 to play my 3D games or even 2D), the only exception being Safari.
Now some people say Safari will never add WebGL 2, honestly maybe but I don't think that's likely. Compared to adding WebGPU supporting WebGL 2 isn't much harder for first.
And secondly, https://trac.webkit.org/wiki/WebKitGoalsfor2020 lists the Goals for 2020 for WebKit which has WebGL 2 in it.
So there is good chance WebGL2 support will be there by the time 4.0 rolls over. (As I don't see 4.0 releasing in the next few months)

What if I don't care and I want GLES2 renderer anyways?

Godot 3.2.x series will be well maintained for a long while. As for if the GLES2 renderer will or will not see any improvements that would depend on if we have someone who picks it up.
Again if you want to see improvements on it you are welcome to contribute or motivate someone else to help. (everyone starts at someplace)
Still, as the opinions of the @clayjohn have swayed in favour of not removing GLES2, maybe having no 3D will have to do for a while. Though I am not quite sure about the burden being minimal part...
So, expect probable delays if someone gets busy with something else.
Please consider Godot is an Open-Source engine there is only so much the core devs can and should focus on.

Raspberry Pi 3B/B+ support?

I have an RPi, I have built Godot on it, I have tried running the Godot Editor on it, doesn't really inspire confidence in it ever being usable.
For 2D with custom optimizations for RPi memory constraints, we could probably make it run properly but I won't have many hopes for any kind of well-textured 3D scenes with playable performance.
And for Raspberry Pi 4 pls get a 2-4GB variant if you want to be able to game on it though.

NOTE: Now you can jump to tldr; if you don't want to read my ideas.

What changes do I wish for in the proposal?

Move the GLES3.0 to GLES3.1 support with backwards compatibility for GLES3.0

yeah if you didn't get the hint from above already.. :P

Why?

Compute Shaders
Most Android devices support GLES3.1 and a large majority of desktop systems.
So it makes sense to perhaps just for Compute Shaders we can have GLES3.1.

I am currently in the process of writing a proposal for the addition of GPU Compute API for Godot. (if some wants to help, I am on twitter @swarnimarun and discord Godot group with handle of steincodes)

I would have said that OpenCL would be the best alternative but, implementing and maintaining that would have to be pushed as a long-term goal whereas using Compute Shaders would be much easier(or so I believe).
And there is the issue of lack of implementations, just RPi4 not having OpenCL implementation but GLES3.1(god thank Mesa devs) is enough to push this forward(again, or so I believe).

Rewriting/Optimizing GLES2 backend if it is to be maintained for the lowest of the low-end embedded devices

Like my example with RPi3 or RPi0 before.
This one is quite self-explanatory, even if it's just the 2D it will be enough for say making retro games, simple GUI applications, Godot is a pretty nice option for embedded because of its simplicity and self-contained nature.

Because I don't think otherwise we can justify GLES2 support in the long term, which is what I expect 4.0 to be, a long term supported version.

I also have some optimization ideas for it for GLES2, but I will discuss them later, in a separate proposal.

tldr;

GLES != GL in versions
GLES3.0 support for low end means a faster GLES3.0 renderer
WebGL 2 is not dead and it will hopefully be there in WebKit by year-end.
Godot doesn't really run well on RPi3.
Please let's do GLES3.1 with backwards compatibility to GLES3.0 for Compute Shaders.
If we do GLES2, let's make it much faster for embedded and lowest of the low end systems.

It took me like 20 minutes to format this after writing, hope it was fun for everyone. :3

they made the same mistake back 2018 and end up with the engine not running well on web browsers and low end devices for a entire year, you can't just expect things to change to suit the changes in the engine, as changes a lot of times are way slower than devs imagine them to be

also what the point of high end GLES 3 if vulkan is on place? GLES3 is like the middle man in between GLES2 and Vulkan and would end up not doing any particular important function

[clayjohn]

@Galomortal47 Please read the above proposal and linked update. In particular:

This change will both increase the perceived speed and quality of the low-end renderer, but it will also make development much smoother.

This allows us to:

1. Standardize workflow between high-end (Vulkan) and low end (OpenGL) backends. This means you can expect a more uniform look when switching between backends.
2. Implement optimizations not present in GLES2 (using instancing, texture arrays, and transform feedback)
3. Have similar lightmap workflow between backends
4. Greatly simplify our engine code which makes maintaining the engine easier
5. Extend more post-processing/materials to the OpenGL backend
6. Support more high-end features that have become standard in 3D engines (e.g. terrain, physical light units, HDR)

The GLES2 backend will be substantially more restricted than the current GLES2 backend. So it makes sense to have a GLES3 backend that targets maximum compatibility and a feature set equivalent to out current GLES2 backend.

Also, in the future, there is no need to quote another user's entire comment within yours. You can link to other comments if you would like to point readers to a specific comment.

[Galomortal47]

https://github.com/godotengine/godot-proposals/issues/877#issuecomment-634995755
oepngles 3 also don't support tons of stuff vulkan will support, so it end up being same difference, only more pointless, if the engine have Vulkan and gles 2 back ends, it will have an high end back-end for high end stuff, and a low end backend for maximum retro-compatibility and low end devices
if a Vulkan and GLES 3 back end is done, what is the point of the GLES 3 back end? it will neither be retro compatible like GLES 2 and will also not have all the new features Vulkan bring to the teble, its pointless and redundant

also no expect Vulkan feature on a GLES 2 back end that is there for compatibility, nor literally transitioning between the two without breaking a few rendering effects

[swarnimarun]

@Galomortal47 I understand that GLES2 is pretty much just as basic as it gets. It has pretty much 100% support on all devices and if your device somehow doesn't support it then you shouldn't even think about running games on it.

But,
It's old, the just non-fixed-function API for Embedded Systems and has no ability to support any kind of modern features.

And my comment is meant to address this issue,
https://github.com/godotengine/godot-proposals/issues/877#issuecomment-634340439

GLES2 if kept, it should become the very renderer for those lowest of the low-end devices.
Nobody is removing GLES2 (yet), and personally, if we make GLES2 capable of performing well on devices such as RPi3/RPi0 then we should very much work on it.

But saying GLES3 is useless is rather non-sensical. There is a very very large space between GLES2 and Vulkan.
GLES3 is for that. It has to be.

Only about 30-40%(maybe 50% by year-end) devices support Vulkan on mobile at most, on lower-end embedded/mobile at most 10% of them do. While GLES3.0/GLES3.1 + WebGL2 cover at least 90% market.
source: https://gist.github.com/zeux/7d3ff56568c6b02de3a87cc69899d949
Not accurate, but still as good as it can get honestly.

The difference is huge, almost 50-60%.
What about these people, why should they suffer from crappy/limited graphics of GLES2?

GLES3 is not a cure but a stopgap until we can move to Vulkan completely. Without the need to abandon all these Users(atleast 50% on mobile).

[swarnimarun]

Btw @clayjohn and @Calinou what about my GLES3.1 proposal?
Can we support it, just for compute shaders, pretty please? (Currently busy with other work and haven't had time to write the GPU Compute API proposal...)

[clayjohn]

@swarnimarun you'll have to make another proposal about that.

The purpose behind this proposal is making a backend that supports the widest possible number of devices.

GL ES 3.1 is supported on far fewer devices than ES 3.0. Additionally, devices which support 3.1, will automatically support Vulkan anyway. So users would be better off using the Vulkan backend ( which will provide access to computer shaders). So there isn't really a point.

[SIsilicon]

Btw @clayjohn and @Calinou what about my GLES3.1 proposal?
Can we support it, just for compute shaders, pretty please? (Currently busy with other work and haven't had time to write the GPU Compute API proposal...)

What about OpenCL? With a little work it can be integrated with OpenGL, and it could even be translated to Vulkan compute shaders, with some limitations.

[clayjohn]

@SIsilicon again, this is a topic for another proposal.

IMO there is no benefit to using OpenCL over using Vulkan compute. In fact, NVidia intentionally supports OpenCL poorly. So it is worse than just using Vulkan.

[swarnimarun]

@clayjohn I would agree that the topic for Compute should be discussed in another thread or proposal, but the contexts sync/match/lead to one another.

Anyways,

1. What I meant was GLES3.1 with 3.0 backwards compatibility. It's just one extra query for Compute Shaders...... :3
   Call it 3.0 externally, in media/press...

1. I will first quote,
   > Initial specifications stated that Vulkan will work on hardware that currently supports OpenGL ES 3.1 or OpenGL 4.x and up.

Which is what you are referring to BUT,

As Vulkan support requires new graphics drivers, this does not necessarily imply that every existing device that supports OpenGL ES 3.1 or OpenGL 4.x will have Vulkan drivers available.

First of all this means that older hardware will PROBABLY never get support for Vulkan. Secondly, many Android versions just didn't have support for Vulkan.

1. Secondly, OpenCL3.0 now has a provisional specification, and it finally makes it good, literally makes everything post 1.2 an extension based feature and has almost every vendor onboard with it AFAIK.
   So no OpenCL is worth supporting still alot of effort, there is also GPGPU discussions to be had about the topic.(will save it for Compute API Proposal).

2. Imagine I want a pro performance renderer, to use your words, why people use GLES2 over GLES3 now.
   Then I can just use GLES3 but with Compute Shader support it will allow for devices that allow for it to squeeze out even more performance from GPU and hence even more performance.

3. GLES3.1 is backwards compatible with GLES3.0, last I heard Vulkan is not(Is it?). So a Vulkan renderer can't exactly do what I said above.

[Madaraz1024]

I do not understand what is happening Godot performance due to rendering or other GL4.X engine (that we do not have LOD and occlusion)
GLES3 TPS Demo(Godot engine) VS GL4.X Heaven(Unigine engine) result performance window screen 1280x720 low graphics settings

TPS demo 6-17 FPS

Heaven 70-85 FPS

my old video card GeForce GTS 450 all ok performance

if Godot GLES3 replaces GL 4.6 last render backend there will be no problems
Godot editor standard render GL 4.X needs export mobile/html5 GLES2/3

this is a topic for a problem driver or video card there is no point further conviction topic, wait 4.0 Vulkan will be better but need a new video card it's sad

[aaronfranke]

By the way, is the statement "WebGL 2.0 is not supported well yet" still accurate? https://caniuse.com/#feat=webgl2 It seems to run on Firefox and Chrome as of 3 years ago, and browsers auto-update so everyone should be using the latest version. Is there some other reason why WebGL 2.0 doesn't work, like hardware support? Shouldn't it work on all devices that can run GLES 3.0?

[Zireael07]

Edge doesn't seem to support WebGL 2.0, at least on my NVIDIA MX 130/Windows combo (I'm not sure if it's the drivers or the browser's fault - WebGL 2.0 works on same card on Linux, Firefox/Chrome). I have Windows Updates off (so that they don't bork my Linux install) so no Edge updates either.

[KoBeWi]

Newest Edge runs on Chromium, so it should support WebGL 2.0 too.

[Zireael07]

I think so, but as I said, I definitely do NOT have newest Edge. I heard too many stories of Windows Update mucking with Linux installs or GRUB to risk it. So yes, most browsers auto-update, but MS Edge probably has a fair proportion of people who do not have the newest version (because Windows Updates are infamous for breaking things - CD/DVD copy protection schemes, drivers...)

[SIsilicon]

@MadaraZ You are comparing an apple to an orange. Those are two totally different demos with different graphical feature setups. One is interior and the other is exterior, meaning not a lot of fragments are being processed other than the ones in post processing.

Godot editor standard render GL 4.X needs export mobile/html5 GLES2/3

We already have that sort of export in 3.2 so 4.0 should automatically have that as well (although the GL drivers being used are still up for debate as you can see).

[Lexpartizan]

@MadaraZ , I'm afraid the performance needs to be discussed in another topic. And I'm afraid a simple transition to Vulcan won't solve this problem. We have gdscript with extremely low performance, but we love it for its convenience. And, most likely, there are problems with the nodes themselves. For example, you don't see much performance improvement if you just turn off visibility. But if you remove the node from the scene tree, the performance is much higher. So I don't expect much improvement from the implementation of occlusion culling and so on. In General, I strongly doubt that godot 4.0 will be such a breakthrough. Of course, I want to be wrong. But I'm afraid that godot's performance problems are not related to the OpenGL version.
In any case, we will find out with the release of godot 4.0.

And it's pretty hard to compare demos. You can achieve a beautiful image with high fps, with one highly detailed static mesh, where only the render works. And you need to compare it with a large number of interactive game objects with physics, scripts, and so on.

[aaronfranke]

@Zireael07 Keep in mind that Godot 4.0 very likely will be released in 2021 or 2022, so by that time perhaps Windows Update will have pushed Microsoft Edge users to the new Edge.

We have to think of what will be the case in the near future, or else we end up with posts like this one where we decided to add GLES 2 and it became mostly irrelevant within 2 years.

Also, the logic in your post seems a bit weird to me. I don't think it makes any sense to target devices where users have disabled updates on purpose.

[Galomortal47]

Only about 30-40%(maybe 50% by year-end) devices support Vulkan on mobile at most, on lower-end embedded/mobile at most 10% of them do. While GLES3.0/GLES3.1 + WebGL2 cover at least 90% market.
source: https://gist.github.com/zeux/7d3ff56568c6b02de3a87cc69899d949
Not accurate, but still as good as it can get honestly.

The difference is huge, almost 50-60%.
What about these people, why should they suffer from crappy/limited graphics of GLES2?

9%, those numbers aren't small we are talking about 200 million cellphone devices, not only that but GLES 3 won't make the cellphone hardware able to handle better graphics than it would on GLES 2, cellphones tend to have low ram, integrated graphics and low clock rate on CPUs, moving to GLES 3 woun't make the graphics better on the slightly as cellphones woun't be able to process the more recent shaders and higher detail procedural textures supported by GLES 3

I do not understand what is happening Godot performance due to rendering or other GL4.X engine (that we do not have LOD and occlusion)
GLES3 TPS Demo(Godot engine) VS GL4.X Heaven(Unigine engine) result performance window screen 1280x720 low graphics settings

TPS demo 6-17 FPS

Heaven 70-85 FPS

my old video card GeForce GTS 450 all ok performance

if Godot GLES3 replaces GL 4.6 last render backend there will be no problems
Godot editor standard render GL 4.X needs export mobile/html5 GLES2/3

this is a topic for a problem driver or video card there is no point further conviction topic, wait 4.0 Vulkan will be better but need a new video card it's sad

GTS 450 was my first vieo card, the godot third person demo is not very well optmized, also that is one of the reasons i believe GLES 3 is damn useless

And it's pretty hard to compare demos. You can achieve a beautiful image with high fps, with one highly detailed static mesh, where only the render works. And you need to compare it with a large number of interactive game objects with physics, scripts, and so on.

By the way, is the statement "WebGL 2.0 is not supported well yet" still accurate? https://caniuse.com/#feat=webgl2 It seems to run on Firefox and Chrome as of 3 years ago, and browsers auto-update so everyone should be using the latest version. Is there some other reason why WebGL 2.0 doesn't work, like hardware support? Shouldn't it work on all devices that can run GLES 3.0?

safari doesn't support it, that is 19% of web browser market

[clayjohn]

@aaronfranke apple still doesn't support WebGL 2. That is the biggest thing that is holding us back.

We are hopeful by the release of 4.0, apple will support WebGL 3. But we have to plan for the worst.

@swarnimarun again, you are missing the point of this proposal. The GLES3 renderer is not going to have the same features as the GLES3 renderer in 3.2. it's feature set will be close to that of GLES2. The reason for this is to get around the buggy mobile drivers. Adding compute shader support is going in the wrong direction. For the GLES3 renderer to work on a wider range if hardware, we need to utilize a smaller subset of OpenGL features.

AFAIK, all devices that support compute through OpenGL now advertise Vulkan support. On Android Vulkan drivers are shipped with Android 7 devices apparently.

What you are proposing is that we design our low-end renderer around supporting the tiny subset of devices that technically support ES 3.1, but haven't updated their drivers to support Vulkan. In doing so, we would cut out support for nearly half of all mobile devices.

It is much better for us to support the lowest end devices possible with GLES3.

[aaronfranke]

If we let Apple hold us back, we will forever be held back by Apple. Also, did you forget that @akien-mga was prepared to just let Mac users dual-boot Linux to run Godot?

IMO: Target Chrome and Firefox, Mac users can just install Chrome or Firefox instead of using Safari, iOS users can just download apps instead of playing web games, and everything will be fine.

[clayjohn]

@aaronfranke apple support is not up for debate right now. Open a proposal if you want to discuss dropping support for apple devices. IMO being a cross platform engine means we do our best to support all platforms.

[Galomortal47]

@MadaraZ , I'm afraid the performance needs to be discussed in another topic. And I'm afraid a simple transition to Vulcan won't solve this problem. We have gdscript with extremely low performance, but we love it for its convenience.

if you are hitting bottleneck due to low GDscript performance, you are either doing something
wrong, or just created a extremely complex game, most of the game graphic resources are generally on the graphics

you have the option to use C++, but its so non user friendly i can't imagine someone using that method, C# support also sucks, i think making C++ user friendly or better C# support are the best options to solve this kind of issue

If we let Apple hold us back, we will forever be held back by Apple. Also, did you forget that @akien-mga was prepared to just let Mac users dual-boot Linux to run Godot?

IMO: Target Chrome and Firefox, Mac users can just install Chrome or Firefox instead of using Safari, iOS users can just download apps instead of playing web games, and everything will be fine.

this would break the multi platform philosophy of godot, and considerably shrink the market reach of godot based games

[SIsilicon]

Just so you all know, I've made a poll on Reddit to see what other think about keeping GLES 3.0 for Godot 4.0. Keep in mind, that this is not meant to completely drive the decision of what to do with it.

[clayjohn]

@SIsilicon it's an interesting idea. But asking users who aren't familiar with OpenGl APIs which API we should use is not very useful.

Most users only know of GLES2 and GLES3 through Godot. So there thoughts will be GLES3 = high-end but slow and GLES2 = fast but lacks features. They won't understand that you can make a faster renderer in GLES3 that still looks better than the GLES2 one.

[SIsilicon]

Yes that is true. I just wanted to see how others view this situation. Plus I _did_ say to look at the discussion before making your vote. I've had a good amount of experience with OpenGL; even made a rendering engine with it before, but I still learnt a few things from this discussion that gives me more perspectives to look at it. Obviously though, not everyone will go here for that.
I was just testing.

[clayjohn]

@SIsilicon no worries. I'm just saying that I won't place a lot of weight on the reddit poll/thread.

Someone quoted Henry ford above "if I had asked people what they wanted, they would have said faster horses"

Always interesting to see others perspectives though. :)

[swarnimarun]

AFAIK, all devices that support compute through OpenGL now advertise Vulkan support. On Android Vulkan drivers are shipped with Android 7 devices apparently.

Nope.
The Vulkan loader is provided by Android(the run of the mill gl-loader).
Also just how will Android do that, it can't really ship with a cross-device driver implementation where almost every company seems to have their own spin on the GPU of the the SoC these days.

Coming back to the point,
While, A Vulkan driver, provided by SoC vendors such as GPU IHVs, that implements the Vulkan API.
Official android says,

Consult your SoC vendor to request driver support.

Inspires confidence.(r/sarcasm)

Androids APIs are all the same, they have a HAL which allows to discover and load the drivers.

From Android 10 Vulkan is compulsory for all devices that natively launch Android 10, support 64bit and aren't low-end/low-memory device.

Just to reaffirm, all devices that support Vulkan have a guarantee of supporting GLES3.1 on Android and most platforms(expect ofc Apple, well they have metal not vulkan so...), the opposite is not really(especially for old devices) true.

Then there is the fact that GLES3.1 was supported since Android 5 and Vulkan since Android 7.

What you are proposing is that we design our low-end renderer around supporting the tiny subset of devices that technically support ES 3.1, but haven't updated their drivers to support Vulkan. In doing so, we would cut out support for nearly half of all mobile devices.

It is much better for us to support the lowest end devices possible with GLES3.

Oh there is a big misunderstanding, I am asking to have a GPU Compute API using Compute Shaders, maybe even OpenCL in future, but to check for it at runtime.
On GLES3.1 force people to have two versions of the Compute code, one CPU based, another GPU based(if they want to use the Compute functionality). And decide if the platform supports GLES3.1 at runtime to judge which version of the source you should use.
So we only guarantee GLES3 features work, everything else needs runtime tests and can be dropped.

This will allow for squeezing out maximum performance while being on GLES3 backend from the GPU if we are lucky. Later we can just intrinsically maybe add OpenCL support, which can increase coverage.

On Vulkan we can just directly use the Compute Shaders, or maybe OpenCL or CUDA if some "very kind and helpful" person implements that, so a GPU only version is perfectly fine.

Also I am completely fine with only Compute API on Vulkan, still, it's a nice goal(Compute on GLES backend is quite a nice feature IMHO), even if we don't do it, (I have no skin in the game for supporting older hardware)

[clayjohn]

@swarnimarun I understand now. Thank you for clarifying.

You'll want to make a new proposal for this though. By default, if we add a GLES3 renderer it will be low end and will definitely not use advanced features like compute. However, having an optional compute API sounds like something that could perhaps work given the right implementation.

From the sounds of it, you are proposing a compute API that is not connected through RenderingDevice (the way Vulkan compute is).

Maybe you are considering adding a new server called ComputeServer where users could write code that would be run on the most accessible compute API (Vulkan, GLES3.1, Cuda, OpenCL, CPU. In that order).

I would love to read an in depth proposal on a compute API, but it is far beyond the scope of this proposal.

[swarnimarun]

Yep pretty much.

but it is far beyond the scope of this proposal.

Sure. is there a place for a draft proposal, I don't currently have time to finish up the proposal. Will be working on other stuff so it maybe a while before I have a complete proposal for it. But I can surely do a draft proposal sooner-ish.

[Rexxilion-ex]

@aaronfranke

By the way, is the statement "WebGL 2.0 is not supported well yet" still accurate? https://caniuse.com/#feat=webgl2 It seems to run on Firefox and Chrome as of 3 years ago, and browsers auto-update so everyone should be using the latest version. Is there some other reason why WebGL 2.0 doesn't work, like hardware support? Shouldn't it work on all devices that can run GLES 3.0?

WebGL 2.0 is supported in all major browsers, but these have a blacklist of GPU drivers that disable it due to stability issues, usually 2 to 3 year old low-end GPUs. That to me seems like a lot of computers that won't be able to run Godot games, not everyone buys a new one every year.

This was also the case with WebGL 1.0, and I had to wait like 5 years for my computer to be taken out of that blacklist and be able to play HTML games (I used to disable this block in about:config on Firefox and the games always ran fine). Now WebGL 1.0 runs on every computer, but I expect WebGL 2.0 to also have a slow adoption.

[xix-xeaon]

@clayjohn Is Godot GLES3 currently (3.2) supposed to work on Chrome and Firefox via WebGL2? It does not for me on either (minimal cube+camera scene), but various WebGL2 test pages do work on both. Looking at the HTML5 export docs it seems WebGL2 has been abandoned by Godot. That makes me sad.

Anyway, I think it's a great idea to keep maintaining a rendering backend (GLES2) which will "always work everywhere", but it sounds like it's going to be even more limited than it already is on the 3D side. It would be really bad if that's the only option for the Web.

We have to consider that the Web isn't just for small 2D games anymore, like in the days of Flash. And even for Desktop games, being able to demo the game directly in the browser is a huge selling point. Also, as others have pointed out, prototyping and game jams benefit a lot from this.

For both the GLES render backends, I totally understand the strategy from the engine developer perspective, but it seems very strange to upgrade to Godot 4 for some new features but in those cases where you can't really migrate to Vulkan, both of the render backends now have fewer features and lower graphics quality than before (although better performance and possible work on a few more devices than before).

I worry that having GLES2 and GLES3 in Godot 4 the way you've described could end up rather useless since people who need them might just stick to Godot 3.2. You'll end up with a lot of pressure to either implement all the new features in Godot 3.x or implement the old rendering backends in Godot 4.

"In game" switchable rendering backends

Lots of games have plenty of settings for the quality / performance trade-off because people have different computers and it sometimes even requires you to restart the game. This causes the same game to look differently for different players but it's still the same game. What are your thoughts on how this could be implemented in Godot with regards to the (now multiple) rendering backends?

It would be really good if you could make a game without choosing only a single rendering backend but instead release a game which supports several and the best one would be used. On chrome it could use WebGL2 but the same game will still work on Safari with WebGL1, just look a little different. If WebGPU is availible it could use that.

And of course the same thing on Desktop and Mobile. The developer could allow the player to switch to a different mode just like switching between texture resolutions. Or if the game crashes then when you start it again it will choose a safer mode.

It would of course probably require a major overhaul but it would also certainly have a lot of benefits, and it would mean the issue of which rendering backends to have and what features / requirements they'll have doesn't have to be such a contentious issue because every game will have great graphics for the majority of players but will still work for pretty much everyone.

[Zireael07]

I don't expect it to be possible to have rendering backends be switchable in game.

Mobile vs desktop vs web automatic detection might be possible, although I wouldn't pin my hopes on it.

[Calinou]

@xix-xeaon Falling back to a low-end renderer is already supported in Godot, but it's disabled by default. You can enable this in the Project Settings (search for "fallback"). You could also set the video driver depending on the platform using feature tags.

One issue is that GLES2's feature set is very different from GLES3 or Vulkan (as explained in this proposal's first post). If you make use of high-end features, your game will most likely look broken when you switch to GLES2 unless you spend a lot of time tweaking everything. If you don't use high-end features, then there's not much point in using a high-end renderer in the first place.

This shouldn't be as much of an issue if GLES3 is our new baseline renderer. Its base feature set is much closer to Vulkan; for instance, HDR can be well-supported out of the box.

[xix-xeaon]

@Calinou The fall back to GLES2 doesn't seem to be working for HTML5 for me, I suppose it falls back on unavailability - not on failure. I don't see which feature tag would be used for video driver but I suppose that could be used to export different versions of the game, and then you could say "try this other one if the main one doesn't work".

It'd be nice to control that through the game code though, but I assume the rendering backend starts up long before the game code runs. Can you see from the code what features it was exported with? So that you could select one environment instead of an other and set up lighting differently for instance.

It'd be really cool if the fallback process could be streamlined and the major differences could be configured so that you could just run it and it would be relatively decent without too much individual tweaking.

Or if you can pick up WebGL2 again, I don't mind that it doesn't work in Safari yet - that's Apples fault, that would mean you could still make proper games for the Web with GLES3. And when WebGPU finally gets done that will work a lot like the Vulkan backends.

[Calinou]

The fall back to GLES2 doesn't seem to be working for HTML5 for me, I suppose it falls back on unavailability - not on failure.

For the GLES2 case, we should probably implement a list of known GPU models where GLES3 support is known to be problematic and fall back to GLES2 automatically there. (For instance, this is a common issue on Sandy/Ivy Bridge Intel IGPs.)

Can you see from the code what features it was exported with?

Yes, using OS.has_feature("FeatureName").

[alexfreyre]

I agree with the idea that maintain GLES2 with a low priority, but usable for 2D and very simple 3D. I am targeting to RaspberryPi 3 but also could be great use a RPI zero which cost $5 and it only use GLES2.

Personally I think that will be great to have in future releases the GLES2 renderer with the new features in GDScript which vnen is making and possibly new nodes because we will be get used to work in Vulkan for high-end with Godot 4.x or 5.x and for targeting to a RPI Zero work then back to work in Godot 3.2 because of GLES2. I just like to open Godot 4.x or 5.x and just work on Vulkan or GLES2 and not to open an older version of the software with older node names and a different GDScript.

If it is difficult to maintain then just drop it.
If it is not very difficult to maintain, please don't drop it, (thinking about not to develop any new rendering feature for it, only not dropping it like a layer of compatibility)

[MightyPrinny]

I don't think supporting GLES2 is very important, but it would be good mainly for young people that can't buy their own computers, modern low end hardware don't have problems with GLES3, but parents in latin america often buy used computers for their kids and those might be old enough that they don't support GLES 3, but those GPU often don't have problems running DX11 on windows, most free games are either made with game maker or unity(at least from what I've seen on itch.io) and will run fine on their old computers if the games don't need high specs, it would be nice if free 2d games made with Godot could run on old hardware as well.

[swarnimarun]

@Zireael07 It should in theory be possible to switch backends, but I don't think we can do a realtime switch at least that wouldn't be a trivial change.
This basically means you can export a game with multiple backends and the exact backend is selected from a configuration file. It is not a new thing, many games have DX12, DX11 and Vulkan...

Auto-switching is also not impossible as we can easily do a test at runtime for API support on the device. The technical issues lie beyond them.
Such as how do features work across multiple backends, I don't expect we will ever be able to do as much as Vulkan in OpenGL even if we use GL 4.6(we are way below that)... Then there are changes to API, we can't really have the exact same API for all of them.

[clayjohn]

Update!

Apple seems to be on track for adding WebGL 2.0 support by the time 4.0 releases (https://bugs.webkit.org/show_bug.cgi?id=126404). Safari already allows WebGL 2.0 through the use of the "experimental" features flag. For some nice up to date data see, https://caniuse.com/#feat=webgl2. This means all major browsers now support WebGL 2 (or will by the time 4.0 releases).

Accordingly, we can revisit this proposal. The main barrier to dropping GLES2 support was the need for a web platform that worked well on all devices. At the time there was no indication that WebGL 2.0 would be supported on Apple in the near future. But now with Apple moving to Angle, it seems support will happen sooner than we could have anticipated.

[MickeMakaron]

@clayjohn Where did you find info that it's on track by 4.0? I'd like to read more.

[clayjohn]

@MickeMakaron There isn't much out there outside of the links that I posted above, but here is a discussion on twitter https://twitter.com/gfxprogrammer/status/1275521758389391360, here is a metal backend for Angle that is nearing completion and is being merged into the main Angle repo https://github.com/kakashidinho/metalangle.

caniuse.com also changed its scathing warning of WebGL 2.0 on Apple to a recommendation to set the experimental mode indicating that the experimental mode is getting relatively stable.

[MickeMakaron]

@clayjohn This is great news. If Safari gets WebGL 2 I don't see any real incentive to use WebGL 1 for web games since WebGL 2 offers higher performance and a richer feature set. The only thing standing in its way is Safari support.

[eon-s]

I work on some educative and preservation projects aimed at local native communities and we can only target (very) low end pc and mobile, GLES2 support is also about accessibility and I hope it continues until common low end hardware matures a bit.

[aaronfranke]

@eon-s I can find used laptops on eBay for $30 USD that have OpenGL 4.5 support. If your projects can't afford this then I don't really know what to say, I consider this to be dirt cheap. At least you can understand my perspective on why I don't see the need to continue supporting GLES2 (at least by the time 4.0 comes out, when it will be even less needed than today).

[eon-s]

@aaronfranke I can't tell the local native communities to spend the money they will use to eat for 3 weeks or more (considering tax and all) per seat to buy stuff the other side of the globe to use a program on their precarious schools, but we can just get stuck with 3.2 for a couple of years and migrate later...

[alexfreyre]

The wonder of open-source projects and linux in general is the backward
compatibility that does not discriminate against anyone. Commercial
software does not think or take into account users as a project like Godot
does, which is managed by the community.

Theater artists perform even if there is only one spectator who bought the
ticket and is sitting waiting.

If a project like Godot (which we love) does not support both the majority
and the minorities, where can you seek support? in Unity? in Stride? on
Unigine? in Unreal? or in less complete, active or attractive FOSS projects
than our engine?

Personally, in the future, if you need GLES2, it wouldn't be annoying to go
back to 3.2, but due to the big changes in GDScript, it would be like
handling two languages to work.

I insist not only people with low resources may need to use GLES2, but also
people who need to produce multimedia, 2D games or projects focused for
example on single boards computers that normally low-cost ones do not
include very powerful processors. Therefore we are talking about users in
school workshops, university projects of different kinds, research projects
in the field of design, art, electronics, entertainment ...

Couldn't it be left intact as one more module? or as an official addon?
something separate from the engine core?

Personally I use SBC (single boards computers) and I am affected if GLES2
is removed. Godot is great for being a 50mb extremely powerful swiss army knife and for
listening to our community! I know you will make the best and most sensible
decision and we support you in it.

I can mention a couple of examples of platform support that differ in how
the community feels, for example the rumor that Apple removed x86_64
support is getting a lot of complaints and users are showing a lot of
discomfort. On the other hand in Archlinux community there are no
complaints, it is healthier and happier because the community curiously supports,
arm v5, 6, 7, 8, aarch64, x86 and x86_64. So there are more opportunities for more people!

[Calinou]

@eon-s @alexfreyre I think it's very likely that GLES2 remains for 2D at least, due to high demand on old Android devices and WebGL 1.0. The real debate here is about 3D.

Either way, Godot 3.2.x will remain supported for a while after Godot 4.0 is released, so fixes and small improvements will still land in 3.2.x. After all, people are still maintaining commercial games made with Godot 2.1 as of writing (like City Game Studio) :slightly_smiling_face:

[alexfreyre]

@Calinou I don't know about software development but I think if it is done why not to keep as a module for example and keep it as it is? if is a problem to mantain inside 4.0 put it separated as a GDNative module?

While more features Godot has more thing we can do!

I don;'t see the reason to work more on GLES2 it is done and work well! If you want to optimize it ok I understand, but it is very good as it is now!

[Calinou]

@alexfreyre Renderers currently can't be added by GDNative modules. I don't know if this will be possible with Godot 4.0. Also, GDNative isn't supported yet on HTML5, so we wouldn't be able to use the GLES2 renderer there if it was moved to GDNative.

[Rexxilion-ex]

@aaronfranke I can't tell the local native communities to spend the money they will use to eat for 3 weeks or more (considering tax and all) per seat to buy stuff the other side of the globe to use a program on their precarious schools.

This is the situation for every person living in 3rd world countries (like I use to). Also you guys may be able to get decent used computers for dirt cheap but we don't have such luck. Again not every kid and their dog owns one so if you look at the used deals you either find 10 year old stuff or relatively modern stuff at almost MSRP.

[swarnimarun]

@Rexxilion-ex I am not gonna say that it's perfect but OpenGL 4.3+ devices are fairly common now, but we only need OpenGLES 3.1 for Vulkan compatibility the problem is just the drivers.

But I do agree that there is probably no harm in GLES2 backend, but I think it might be better to somehow have a way to add it without having to resort to issues with the engine, such as a sort of backend/fork meant for extreme low-end.

@eon-s You are right, but the problem is the work needed to maintain such a thing.
For, Vulkan or any sort of modern-esque graphics API to be used properly we have to move the minimum requirements above at least GLES3+.

I don't believe there is a way to abstract over both GLES2 and Vulkan with the same API while making it performant and modern without a lot of extra work.

Thus I would recommend, that we should finally think about making some form of Working Groups that will discuss proper ways to tackle such issues. And maybe work on maintaining Godot 3.2 and porting some changes from 4.0 into (say) Godot 4.0LP or something and focus on low-end platform development.
Again this is a lot of work, but better than throttling the progress of the Engine as a whole for Backwards Compatibility which itself would require a lot of rework in the first place.

[starry-abyss]

GLES 2: For 2.5D games it's would be good to have the ability to use some 3D models besides 2D assets, for example, for animated characters. As suggested, I think basic lighting support for those 3D models should be enough.

WebGL 2 and OpenGL 3 support - official support tables are one thing, but in practice the support might be worse (show black screen or spit out errors).

For example, by tables my system should have supported WebGL 2 just like that, but see here: https://github.com/godotengine/godot/issues/12416. In reality it only worked with WebGL 1, but if ANGLE was manually deactivated then it also supported WebGL 2. Seriously, I'm not going to ask the players to deactivate ANGLE in the browser to play a web game.

[Calinou]

GLES 2: For 2.5D games it's would be good to have the ability to use some 3D models besides 2D assets, for example, for animated characters. As suggested, I think basic lighting support for those 3D models should be enough.

It's still possible to render 3D models to 2D sprites with normal maps (and specular maps in 4.0) using scripts. Blender definitely supports this for instance.

[Rexxilion-ex]

GLES 2: For 2.5D games it's would be good to have the ability to use some 3D models besides 2D assets, for example, for animated characters. As suggested, I think basic lighting support for those 3D models should be enough.

Agree, I at least hope for some basic 3D functionality with GLES2. The old computers I want to target have GameCube graphics at most, so that's how my games will look.

[hubertekvall]

I haven't read the entire thread but, so I apologize if I missed something crucial.

But as I see it, the amount of low-end devices that can run GLES3 will only increase with time. In the near future GLES3 will dominate as the common denominator on low-end devices, and with that in mind, I don't see a purpose in keeping a rusty GLES2 around if we have to choose one. How old computers do people want to ship to? And how far back is reasonable to support?

"Low-end" does not have a fixed meaning but changes with the times, why should the APIs be different? Ideally there would be a way to keep the best of both worlds, but it doesn't seem reasonable to support absolutely everything with Godot.

Sure GLES2 will support the most devices, but what about people that want to support slightly older platforms but also use some of the nicer features enabled by GLES3?