Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
pollend opened this issue Jul 2, 2023 · 3 comments
Open
Assignees
Labels
Category: Doc Requests, Issues and Changes targeting javadoc and module documentation Status: Needs Discussion Requires help discussing a reported issue or provided PR

Comments

@pollend
Copy link
Member

pollend commented Jul 2, 2023

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 pollend added Category: Doc Requests, Issues and Changes targeting javadoc and module documentation Status: Needs Discussion Requires help discussing a reported issue or provided PR labels Jul 2, 2023
@pollend
Copy link
Member Author

pollend commented Jul 2, 2023

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

@pollend pollend changed the title Roadmap for The Forge Roadmap Native Graphics Backend (Vulkan, DirectX11, DirectX12, Metal) Jul 5, 2023
@pollend
Copy link
Member Author

pollend commented Jul 5, 2023

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
Copy link
Member

jdrueckert commented Jul 5, 2023

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Doc Requests, Issues and Changes targeting javadoc and module documentation Status: Needs Discussion Requires help discussing a reported issue or provided PR
Projects
None yet
Development

No branches or pull requests

3 participants