-
Notifications
You must be signed in to change notification settings - Fork 4
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
Vulkan support? #10
Comments
Sure! All we need to figure out is how to integrate both renderers (meaning how does it decide which renderer to use.) Another thought is whether you choose what to render with at compile or runtime. Runtime would choose the best renderer for the system at the cost of slightly slower performance as it has to run virtual callbacks. I wanted to have a virtual Renderer class that every Window has and then you have GLRenderer, VulkanRenderer, DirectXRenderer, etc. so if you want me to implement that I can |
I would like to be able to choose the renderer at runtime. If you could implement a GLRenderer and a blank VulkanRenderer that would be really helpful. I am currently working on an opengl/vulkan game engine for the upcoming ludum dare: https://github.com/sharhar/LDEnginev3. It is written using Java and the LWJGL library, but I think that it could be a good reference point for how to implement a two API rendering system. |
You can also look at my vulkan implementation of a voxel engine (inspired by minecraft) that uses vulkan to do all rendering. This project it written in C++ and uses GLFW: https://github.com/sharhar/VKraft. |
I am currently working on a vulkan engine that will reduce boilerplate code. Link: https://github.com/sharhar/VKL It's written in C, so it should be compatible with the engine. I'll help you implement it when I finish implementing basic features. |
I am also rewriting a large portion of the Rendering system to accommodate multiple Renderer types. There are a couple of problems I need to work out but I'll reopen this issue when it is ready. |
@sharhar there is now support for adding custom renderers such as a vulkan implementation. all you need to do is to extend the GraphicsContext and it's methods. Its a bit of work as you also need to extend the ModelImpl, TextureImpl, PainterImpl, and Renderer classes to get everything to work together. |
I can create a blank implementation and header file for you. Also I forgot to mention that it does choose the renderer at runtime with hints passed from client. Look specifically at Graphics/Window.cpp Window::create() function to see how it determines which renderer to use. Currently it only has 1 renderer - OpenGL 3.3 |
I'm currently working on a vulkan and metal library that allows you to you the modern rendering APIs in one unified API |
I'll start working on an implementation of it when the library is developed enough for use |
This is something that Nvidia has been working on to unify the apis. It's pretty buggy though |
Regal is for all rendering API's. The API that I am working on (called razter) is meant specifically for the modern rendering APIs with command buffers and direct memory control. Currently, the API is just barely enough to implement all the features that you want for the engine. Once it has more features, I will add it as a rendering backend. Here is the link to the GitHub project: https://github.com/sharhar/razter Also, if you could add more demos of the engine, they would be helpful in testing everything out. |
I'm planning on adding more demos as I finish writing more basic features. Expect them soon |
I have been teaching myself vulkan for a while now, and I think that I would be able to implement a vulkan back-end to the engine. Should I try to do it, or is OpenGL good enough? (I do not think that there will be a significant performance increase, it will just be cool to have)
The text was updated successfully, but these errors were encountered: