Future rendering topic

[sturnclaw]

Regarding BGFX vs Forge, there are some pros and cons.

BGFX Pros:
- Supports OpenGL.
- Has a large userbase with many opensource implementations we can reference for our own use.
- Bring-your-own-engine style means it's fairly simple to drop it in place of our current OpenGL renderer.
BGFX Cons:
- No tagged releases. If something's broken in the library, you've got to play russian roulette to find another version that fixes the issue without introducing more issues.
- The build process is very complex compared to what we have - there's going to be a fair amount of work integrating into Pioneer.
- The shader abstraction isn't perfect and is terribly documented.

Now, I haven't taken a look at Forge much, but here are my impressions:

Forge Pros:
- Supports Vulkan 1.1/DX12 out of the box.
- A number of useful features are already implemented.
- Tagged releases. (need I say more?)
Forge Cons:
- No OpenGL support.
- (probably) Not as easy as BGFX to implement.
- No unified shader abstraction.
- Probably some other cons I'm missing.

Honestly, I'd almost rather just implement a new Vulkan render backend copied from BGFX or Forge, as we have pretty much everything else in place already. Nothing in BGFX or Forge is particularly useful to us, or something that we don't already have.

Given the pros and cons here, I'm leaning towards BGFX over any other implementations, unless there's a lightweight library we haven't found that satisfies our requirements.

[FluffyFreak]

Throwing Sokol (https://github.com/floooh/sokol) into the ring as well.
Single header file implementation, GL/Metal/DX11, imgui usage and integration.

[sturnclaw]

I think I may have found something worth using. LLGL (https://github.com/LukasBanana/LLGL) is a thin C++ wrapper over DX11, OpenGL, and Vulkan, with a common, (fairly) sane API abstracting away the platform differences (and the stupendous amount of boilerplate required for Vulkan). It builds with CMake (though some trickery with ExternalProject is required) and Visual Studio.

The only real downside I can see is that you have to manually provide your own shader files for each target you wish to support. We can work around this requirement in a number of ways, so it's not that big of a deal.

Since I have apparently lost control of my faculties and am attempting to learn Vulkan without even learning OpenGL first, I'm currently evaluating the library with an eye for suitability for Pioneer. I'll let you know what I find at a later date.

[sturnclaw]

I came across this really interesting project the other day regarding renderer architecture, https://github.com/azhirnov/FrameGraph/, as well as this presentation on Frostbite's rendering. The way our current rendering architecture works is kind of a pain, as the code responsible for actually rendering the scene is scattered about between Pi.cpp, Game.cpp, Space.cpp and the renderer subsystem, none of which quite see eye to eye over things. While adopting that specific library is likely not the way to go, the idea of building the user-code-facing rendering system as an abstract graph that we can plug functionality into bears some merit. Further research in this direction is likely necessary.

Especially with the planned move to a new shading and rendering subsystem (Vulkan, forward+ PBR, etc.) I'd like to take the time now to discuss and plan out what the architecture will look like at the end of the move, with an eye to usability, maintainability, and most importantly reusability.

Implementing the sector and system views to a similar graphical standard as the WorldView should not require making a copy of the scene rendering code, and ideally we should be able to share graphical effects like the stellar background, low-LOD planetary rendering, and large structures between all three systems (where applicable) with only a few lines difference in invocation