Roadmap Native Graphics Backend (Vulkan, DirectX11, DirectX12, Metal)

[pollend]

Motivation

There are not a lot of good options in regards to rendering frameworks. for LWJGL there is either OpenGL or BGFX.

I've used bgfx for this project (https://github.com/OSS-Cosmic/AmnesiaTheDarkDescent/tree/feat/bgfx). bgfx is decent there is quite a bit of overhead since commands are recorded and played out on a render thread. basically you are limited to two command buffers for vulkan and the action of replaying and forwarding state is quite a bit of overhead. It's also very opinionated, so how things function from a graphical point of view can be very hard to trace, basically its a black box. some things are not straightforward and require peering into the API to understand functionality.

Proposal

one thought to to is move all the asset management and rendering logic to a native binary. I've been using this rendering abstraction wonder if it would be applicable to our needs: https://github.com/ConfettiFX/The-Forge the other option is NVRHI (https://developer.nvidia.com/blog/writing-portable-rendering-code-with-nvrhi/)

how I imagine how this would world would involve a call into this abstraction with a handle we can store for a entity and have a native API to call back in and update some state maaybe. you can have a uniform API to bind in some custom shading state but we can start simple and not have it configurable to start with and figure that out when it happens. :?.

this is used for a lot of upcoming games so retrofitting it on terasology doesn't seem such a horrible idea. It's fairly modular so we don't necessarily need to adopt everything :?

we do end up dropping support for OpenGL but I don't see a lot of current/new engines supporting opengl going forward. Unity, Unreal Engine etc ... OpenGL takes a lot of effort to support if you still want to do that. DirectX11,12, Vulkan, and metal are pretty similar. OpenGL is the odd one out ...

[pollend]

@DarkWeird pointed this library out: https://kgpu.github.io/kgpu/structure/jnrgen.html

[pollend]

if we want to go the rust route this is also an option it has a lot of design principles from the forge: https://github.com/aclysma/rafx

[jdrueckert]

if we want to go the rust route this is also an option it has a lot of design principles from the forge: aclysma/rafx

When looking for potential libs to use, please have a look at the respective repo's activity and contributor base. For instance, while the one you mentioned seems relatively active (last commit three weeks ago), but if you look at the commit history, you'll see that for the past 2 years, the commit come from only one person. What if that person decides to stop working on or supporting this lib?

So please @pollend : look for alternatives that are active, have a bigger contributor base and are ideally commonly used in similar projects or at least somewhat widely used. We decided to not act as a tech playground anymore, so we shouldn't be front-runners for relatively new projects but instead build on more stable, established, and ideally well-documented solutions - especially in an area of our codebase that is very central, complicated, and has very few experts.