Which opengl version to use?

[Linus]

Since I started working on a general particle system for the engine, I have to deal with a lot more (raw) OpenGL stuff than before. At the moment there are no guidelines on what versions of openGL to use.
Judging by the LWJGL imports, it seems that we are currently mixing version 1.1, v1.5, v2.0 and v4.3 (although the last one is only used in debug mode).

I am by no means an expert on OpenGL, but wouldn't it be best to stick to one version? The mixing of different versions is really confusing, especially in the case of shaders (different versions allow different keywords etc).
The rendering stuff would probably be more robust, if we could stick a version tag on each glsl source, so the compiler can warn about incorrect/deprecated usage.

Updating the existing code to use one specification is probably a bit too much work to do in one go. However if we can decide on which version to use and document it somewhere, than at least all future OpenGL code is using the same version.

If we are going to decide on what version to use than I would vote for version 3.3. Reasons being:

1. that more than 95% of all steam users have hardware supporting openGL3.x (== DirectX 10.x). (edit: unity survey)
2. OpenGL4.x only enables new hardware features and does not really change the API.
3. OpenGL versions before 3.0 have a lot of stuff that is now deprecated and that probably has its reasons.

Thoughts?

edit2: The GLSL shader class prepends all shader with "#version 120", which would mean that the engine expects OpenGL2.1. I only noticed that because adding a version tag to a shader file resulted in a crash...

Knowing this, I would actually just prefer to continue using openGL2.1 and document this somewhere (wiki?).

 

[Cervator]

@manu3d has been talking about similar topics, and maybe we can even conditionally enable newer stuff in some rare cases or use a newer version normally but fail back gracefully auto-disabling some features on older hardware. Going on my weak memory here though, he can probably get more exact!

@Immortius is sure to have good feedback there too

We might also double check the preferences of LibGDX for any future potential as well.

 

[Immortius]

The trade off has always been between compatibility and performance/capability. While 95% is good, it does mean 1 in 20 PCs in the core gaming user base wouldn't support it.

My suggestion is we stick with 2.1 (the Compatibility profile - I don't know if that can be formalised?) for now, and down the track we add separate implementation specific for 3.3 (Core profile). For shaders this will require some particular attention, perhaps along the lines of allowing fallback shaders to be specified (see: Unity's approach to shaders).

 

[manu3d]

Sorry everybody for the late reply. It has been a couple of though weeks at home. I should progressively get back on track. I hope!

Regarding this thread: first of all thank you @Linus for finding where the #version 120 statement is added to the shaders. I haven't really looked that deeply into shaders and their management yet but for the little I saw, I was puzzled by the absence of that line. It now appears that I was probably on the right track in this thread thinking that there was a shader version issue, I just hadn't connected all the dots.

Second, I would LOVE to switch to a later version of OpenGL, i.e. 3.3. Somewhere from 3.x onward, it seems to me, opengl programming just became a much smoother, less idiosyncratic affair.

The problem is, it's a lot of work because of the extent of the existing rendering codebase. And rewriting the renderer is not quite my goal. All the refactoring I've done so far is incidental to my studying the current renderer and tiding things up when they seemed a bit too convoluted. What could be a feasible thing in the medium term is to refactor things to allow for other renderers to be plugged in, eventually leading to parallel lines of development and a more modern renderer.

In the very short term, I'll make a quick change to LwjglGraphics.checkOpenGL() so that it also checks for OpenGL 2.1 capability. This will at least resolve the recent issue #1616 and further limit the number of mishandled incompatibilities.

 

[Skaldarnar]

Yesterday someone with a Raspberry Pi popped up on IRC and reported a problem. I don't recall the details (and use another PC so cannot access the log files) but I think there was something about OpenGL for embedded systems - @Immortius would probably know more about it. Not that it should have a high influence on this discussion but I just wanted to leave a note for reference

 

[manu3d]

I think at some point we should open a development branch to support monochromatic LCD screens on microwave ovens and fridges. Also, I'm thinking about developing a 1 by 1 pixel renderer to play Terasology on single dimmable lights. Once we nail these two somewhat constraining environments, dealing with something as powerful as a Raspberry Pi should be a breeze!

 

[Immortius]

With regards to the Raspberry Pi, it only supports OpenGL ES. My understanding is LWJGL does not have any support for OpenGL ES at this time, although it is in the works with LWJGL 3.

 

[Linus]

I started a wiki-page to document all kinds of rendering related stuff, including the OpenGL version.

 

[manu3d]

Thanks Linus! I've been roving through the rendering code for months now (and especially in the last two/three weeks) and I had no idea what the client-side of it looked like. It's nice to see an example about it.

To take the chance to give everybody an update, the WorldRenderer and its alter-ego the RenderingProcess is currently undergoing through some serious refactoring. The LwjglRenderingProcess class in particular is, from my perspective, three classes into one, each dealing with a single, conceptually simple task: buffers management, opengl state management and post processing. There's limited overlapping between them and I eventually managed to untangle them. Now that the dust from that work is settling, I also saw the scope for the WorldRenderer to have some of its functionality to be moved in a separate class but I have to further evaluate that. In short, I am days (hours?) away from having a destination commit. As the changes are substantial, are in parts of the code most are very unfamiliar with and given the available manpower for review, to get there in one PR is unrealistic. So, the endpoint (minus the feedback) will be available as a branch for anybody to see and comment on, but I will submit instead smaller PRs to get us there in more manageable steps.

Once we are there I intend to add quite a bit of javadocs to the classes involved and that would also be a good time to add some useful information on the wiki about the (graphic-)server-side of the renderer.

 

[manu3d]

Just wanted to mention the refactoring I mentioned above has begun with PR #1668. I decided last minutes to add javadocs and comments to the new code, which is why it took a few more days than I thought. The endpoint I was also referring to is available in this branch, to get an overview of where I'm heading.