Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Vulkan and the future of Magnum #91
As the news about the OpenGL successor are starting to appear, I'm considering what to do next. I deliberately didn't implement any new GL-related functionality lately, partly because I'm putting all available resources into finally finishing #44 and partly because I didn't want to accidentally create APIs that would be incompatible with the approaches found in glNext, now called Vulkan.
Magnum is not just an OpenGL wrapper, it has also math library, some ugly scenegraph implementation, data import framework etc. These things are not dependent on the underlying graphics API and thus the following decisions should not influence them (besides the effort to make stuff more data-oriented).
So, these are the possible next steps:
In any case, the GL API is deemed to be removed at some point in the future, staying with Vulkan backend only.
Switch to bgfx, and focus on these:
You'll have more time to make that "ugly scenegraph implementation" pretty, and it will work everywhere... :)
If the first goal was to make an OpenGL wrapper + math library (like an OpenGL quickstarter for c++), I think that the next step would be to define the next goal.
I haven't used Magnum nearly at all, but have been looking at it with great interest lately. I was hoping to move to Magnum from Irrlicht (easy to use "high-performance" graphics engine, supports many APIs but originally designed around D3D9), which I was using with OpenGL. Because of Irrlichts support for very old OpenGL versions and D3D9 oriented design, Magnum sounds like a charm, being GL only and completely unsupportive of versions which couldn't run a distortion shader (and therefore I don't care about). Also, bye undocumented euler rotations, hello quaternions! :D And C++11!
For me seems like the most flexible option. When the time comes, dropping the GL support is super simple with this and also, this would not hold down the Vulkan API, since no compromises would have to be made. And after all, since "Vulkan only" seems to be the end goal for the (distant) future, compromises don't really seem like an option.
Magnum strengths as I see them:
If you were going for a [partial?] rewrite, things I would like to see:
I'm guessing uptake of Vulkan is not going to be overnight. We're going to be left with a lot of legacy OpenGL for a while to come yet, so let's not rush to abandon Magnum. Maybe we don't want to be implementing new OpenGL extensions for the moment, but there's other features to be worked on in Magnum?
I read this, this morning, I think at least some of it is applicable to Magnum: http://jmonkeyengine.org/301602/in-the-age-of-free-aaa-game-engines-are-we-still-relevant/
Thanks for the insightful inputs, everyone.
I did some reading, actually a lot of reading, about data-oriented design, Entity-Component systems, SIMD, Vulkan/AZDO, proper GPU feeding etc. Vulkan still has some time to be released, so this is my take on things:
What I won't do, probably:
When these are finished, I think that the lib will be ready for adopting the new Vulkan ideas and dropping the GL ways of thinking along the way. Because of WebGL it would still need to keep some sort of GL compatibility, but hopefully the GL could be wrapped in a Vulkan-compatible package.