Pioneer dev forum

So I'm going to list a bunch of Vulkan rendering tutorials here and then talk about what's on my mind.

Vulkan
https://vulkan-tutorial.com/
https://gist.github.com/graphitemaster/ ... 379af840d4
http://av.dfki.de/~jhenriques/developme ... torial_014
https://renderdoc.org/vulkan-in-30-minutes.html
http://ahcox.com/vulkan/

OpenGL es 2.0
http://blog.db-in.com/all-about-opengl-es-2-x-part-1/
http://elinux.org/Raspberry_Pi_VideoCore_APIs
http://stackoverflow.com/questions/2845 ... -with-sdl2

Also to discuss OpenGL 4.x and loading OpenGL extensions.

Do you have a specific aim in mind with Vulkan? Like new shading, BPR (not NPR, as I first said), etc? Or it's more about performance?
Asking, so I can prepare in advance to support your work from the asset side if needed. :)
And I already started to play with PBR stuff, to have a clue about more recent things:

@nozmajner that looks like PBR(PBR implementation) rather than NPR, and it looks good too! :)

I ran out of brain power for writing anything on this last night but here goes:

Instead of continuing the older "OpenGL 3.x Renderer" thread I decided to open this one to discuss where we could actually go next.

There are powerful ARM based platforms available now that mean we might want to support OpenGL ES 2 / 3.
Vulkan is availabled on the desktop for Windows and Linux (and future ARM boards).
Metal is OSXes Vulkan style API.
Of course there's been developments with OpenGL 4.5 out now.

So there's at least 4 backends there which are no longer so cross-platform.
They're also not as widely supported which is why we're stuck at OpenGL 3.1 currently.

We can certainly do an awful lot with GL3.1, including support PBR as in the image @nozmajner posted above, but it's clearly the older way of doing rendering and so we miss out on the performance improvements, and features, of the newer API's.

One way of dealing with this complexity is to hide it away behind a 3rd party rendering library like BGFX (hello @bkaradzic!) which we've discussed a lot, now it really just needs one of us (probably me) to sit down and get hacking to implement it.

It's 95% likely that this is the route we'll head down, but it is a massive task with Pioneer.
Despite all the effort I've put into splitting the renderer from the rest of the codebase there would be as much work again to separate our renderer from our texture management, shader + effect handling.

There's also some complications because BGFX doesn't do shader compilation at runtime as far as I can tell.
I believe that it uses it's ShaderC program to compile everything beforehand(?) and this would be a problem with our shader being dynamically compiled to allow for graphics options and in future for the shaders generated from JSON files for the terrain generation.

That's not to count it out, all those problems can be worked around, it's just a bit more work.

The reason for BGFX of course is that it gives us the possibility of supporting OpenGL3.1 / GLES2.0 / Vulkan(eventually) & Metal with the same C++ code.
It's cross-platform, I've even run some of it's demos on my Raspberry-Pi 3.

This is all about the technical or backend side of things of course and making sure that Pioneer can run on the maximum number of platforms whilst embracing newer rendering technologies.

I've got a little SDL2 + BGFX test thingey where I'll work on this, just to understand the shaderc, texturec and other associated bits.
It's at https://github.com/fluffyfreak/noisebgfx for anyone following along. As I post this it currently does nothing but open a window, clear the colour to grey and display some text.

Really good PBR explanation

Also there are alternatives to BGFX, "The Forge" for example -> https://github.com/ConfettiFX/The-Forge

EDIT:This and below posts are a moderator-merge from post: "Code inspiration and rendering resource", as I think it's better to discuss here.

Also there are alternatives to BGFX, "The Forge" for example -> https://github.com/ConfettiFX/The-Forge

BGFX seems to have larger userbase, but this looks very impressive to, with IMGU support and such. Is there a reason / usage case that's driving the development of this project?