Pioneer dev forum

So, I've been quiet about the threads I'm working on recently due to a number of reasons that have all led me to the same conclusion: We need a newer version of OpenGL, preferably 3.0 or newer.

I'll recap the reasons:

• Our numerous shader problems - things that work on nVidia, don't on ATI/Intel and other legal syntax can't be garuanteed between proprietary drivers and open source on Linux.
• Terrain Texturing - I have a test branch of this but it's going nowhere until I rewrite the terrain generation, even then using a texture atlas causes numerous mipmapping issue and without GL 3+ I can't use texture arrays.
• Terrain Generation - I have another branch with this partially working, but again driver/OS compatibility issue have nerfed it.

Most if, not all, of these can be solved/mitigated by switching to a version of OpenGL 3.x or newer ... so I wrote one.
It's currently running on a heavily cut down fork of Pioneer using the OpenGL 3.2 Core profile (3.2 version, Core just means it's stripped of any compatibility stuff).

It's basically the same underlying renderer with the incompatible part removed, so no more bare triangle/line/point drawing.
Instead that will all be handled by additions to the Drawables namespace which wrap the data and manage the calls to buffer creation/initialisation/drawing.

This impacts a massive amount of code, requiring a lot of rewriting and time so this is simply notice that it will be happening over the next 6 months!

I'll be doing this work in this order probably, it will mean a lot of background changes throughout the code:

• New Drawables for primitive types: triangles, lines, points, billboards, etc.
• Changes to font, GUI and UI to use the above.
• Changing the rest of codebase to use new Drawables objects.
• Deprecating (removing) the old OpenGL 2.1 style methods.
• The new renderer actually goes in set to require either OpenGL 3.1 or 3.3 depending on compatibility (I vote for GL 3.3).

Other options I considered were just not bothering... really. I figured we could just ignore this stuff, drop the complex terrain texturing and do something simpler, not bother with GPU terrain generation etc.
I also thought about dropping our renderer entirely and replacing it with something like BGFX which ultimately might be something we could do. However, doing that without all of the other changes required for this 3.x transition would be painful. Therefore if we ever do it then *that* transition would benefit from this one.

I imagine that this will cut-off some low-end GPU users. I'm thinking specifically of older integrated Intel GPU's that suck arse and don't support anything better than OpenGL 2.1, we'll have to see who that affects.

As I said, this is already mostly up and running in a cut-down fork of Pioneer, it's missing some of the functionality and not everything is ported over due to the fork having no GUI(!) etc. There will be a lot of differences between that version and what goes into Pioneer but with such a long term plan/project I've decided to put up info about it.

Andy

I imagine that this will cut-off some low-end GPU users.

Oh-oh. I think that's me. So will this be heavier/more taxing on the hardware? Or is it just a question of the hardware supporting OpenGL 3? (I don't know if I just asked two questions once, or one question twice)

Well, even if I'm cut off from running pioneer on my laptop (Intel 950), I'm glad to see you putting so much time and effort into this.

Doh! Yeah that's going to cut you off!
Looks like it only just supports OpenGL 2.1 thanks to extensions and probably doing some work CPU side to enable it too.
Victim number 1 has been found ;)

I'm not keen in keeping around the current renderer as maintaining two of them is going to be more work, but there's a good solid 6 months of dev' work between now and the final changover I'd bet so things can change in that time.

No worries. I'm never in the graphics code, so if I need to run pioneer to test something (usually just lua-script) I can probably use an older version. Plus I have another computer where I do more serious pioneer related tests.

Hi,

Noticed this bgfx link in github analytics, and thought I might be able to provide some help.

I also thought about dropping our renderer entirely and replacing it with something like BGFX which ultimately might be something we could do. However, doing that without all of the other changes required for this 3.x transition would be painful.

Porting from GL2 straight to bgfx might not be as painful as it might look at first. I looked in some of your renderer code and it seem some stuff could be straight forward. First, bgfx shaders are GLSL 1.20 compatible, so moving that to bgfx will be easy. I did ports of some GL2 only code to bgfx and you can use that code to get ideas how to make it work with bgfx.

The most fresh example is NanoVG port to bgfx:
https://github.com/bkaradzic/bgfx/blob/ ... g_bgfx.cpp

vs GL2:
https://github.com/memononen/nanovg/blo ... novg_gl2.h

Other one is imgui:
https://github.com/bkaradzic/bgfx/blob/ ... /imgui.cpp

vs GL2:
https://github.com/AdrienHerubel/imgui/ ... derGL2.cpp

Probably the fastest way to get bgfx into is to comment all GL calls, and then add bgfx initialization, and port functions like:
DrawLines, DrawLines2D, DrawPoints, DrawTriangles, DrawPointSprites to bgfx:
https://github.com/pioneerspacesim/pion ... 2.cpp#L341

Since they don't hold state, and everything is set right there, which is similar to bgfx way of doing things.

Anyhow, if you need more info I'll be glad to provide some guidance thru process. :)

Branimir

Hi Branimir!

Thanks for the info/advice I'll take a look at bgfx as a direct replacement then.
It might make some things a lot easier if I don't have to replace/rewrite all of the intermediary methods with drawable classes.

Andy

Initial WIP - PR is up now

@impaktor, so this is going to nobble your laptop due to that IronLake Intel HD GPU. Purely because no-one has bothered to implement the OpenGL 3.x support in the drivers, even though they're probably capable of supporting most of the features.

Bummer. We'll, as I said, don't let that stop you from merging once you feel the need. I was already quite reluctant to compile pioneer on that machine since it takes quite long.

This is about ready for merging with one exception... Line Rendering can only have a thickness of 1.0

Now this could be fixed by writing a new line shader and doing some smart things, but I've already done a tonne of smart things and I think I've used up my yearly quota ;)

i.e: I can't work it out right now.

I would like to therefore merge it with this restriction and move on, possibly to fix it in the future, or for someone else to fix it in the future... obviously I'd be ecstatic if it was the latter.