Dantus is right, selecting a socketed draw mode, like openGL_ES compatible mode, or vulkan or ??? Should enable/disable features and change materials and options for materials etc, in the viewport and in the game engine, this change would also open up the bge on android.
ape i dont think blender could be moved to vulkan in less than a year which would make vlukan capable hardware more than 5 years old. i would advocate learning vulkan before attempting to rewrite blender for it so even later.
that is why you socket the render, and do marginal improvements over time to vulkan render, while the vast majority still use openGL. Maybe vulkan starts with 95% of features disabled, and as they are working, turn em on. The important bit is to seperate the function so that you can add to the new system and maintain the old systems at the same time.
The problem is, how do you abstract two very different APIs (Vulkan and OpenGL) without losing the benefits of either? This is neither a small nor simple task.
Particularly, I don’t think it’s a good idea to task inexperienced GSOC students with this, because that didn’t really pan out in the past and Vulkan is even harder to use than modern OpenGL.
I believe it would be better to investigate integration of an external abstraction layer like bgfx, which is already optimized for drawcall throughput on many legacy APIs.
BeerBaron - I did not mean to hang blenders star on Vulcan, I mean to add the ability to choose a different API,
be it* a openGL_ES profile on a tablet, or say Vulcan, or ???
just to add a layer of abstraction / bindings that can easily be re-targeted.
Like switching between cycles and blender internal, but for the whole ‘Draw mode’
Gonna try it out, opengl never really worked for me so i’m happy to get something better
Just make it a Blender 3.0 project, by then it should use the latest technology available and be in par with the other software titans.