I improved the implementation of materials and textures with Vulkan. Now every material is translated into a GLSL shader that is converted into SPIRV code with shaderc library. The shader is generated along the graphics pipeline to match the material settings. For now materials are very simple and used to draw an image texture with alpha blending or a filled color.
As you can see from the video, now the gui has normal appearence instead of rainbow rectangles of before. The next step is to support path rendering and font rendering, for drawing the text. In the future, the same materials system will be used to draw 3D content too.
I am happy to announce that Vulkan library has finally been integrated into my framework. For the moment nothing complicated, I limited myself to implement a specialization of the Graphics Context that draws simple colored rectangles instead of the images drawn by Cairo library. It's possible to invoke drawing commands with the same degree of complexity and practically identical management of textures, materials and uniforms, at programming interface level.
Each rectangle is associated with a transformation matrix, which is translated into a uniform buffer. It's also possible to rationalize the rendering into multiple layers, allowing the reuse of command buffers with a minimum programming effort.
As you can see from the above image, the 2D GUI based on the graphics context worked quite well. It's possible to drag the windows and see them move on the screen at a high framerate, which is the main purpose for which it's worth bothering the Vulkan libraries.
For the moment there is an implementation of textures and materials, but I have not yet finished the rendering part at shader level. The difficulty lies in the fact that the framework must resolve the material nodes to extract the proper GLSL shader to be converted into SPIRV, create a suitable graphics pipeline and set it before rendering. The next step is to finish this part and make the 2D GUI identical to Cairo version.
Then I can proceed implementing 3D functionality, with a full material management. The main goal is to implement an importer with assimp library and load 3D models. Then I will proceed refining the 3D functionality with a sophiticated engine optimized for modern real-time computer graphics.
I had to decide the graphics library for the 3D rendering part of my framework, and I decided to adopt Vulkan for a series of reasons. First of all, after years of experience with OpenGL library, I decided that the trend of adding extensions is not good for the maintenance of the software. You may say that there are many wrappers around and you don't have to care about the underlying library, but it's not a good practice at all.
You are going to add an external dependency on your software, you don't have control over it and as a programmer, you are not going to learn anything (apart the wrapper itself). I programmed several OpenGL applications without using any wrapper and it's the best thing to do. In this way, you learn how the library works and all the issues related to that. One of the worst is the huge quantity of extensions. If you are lucky, the OpenGL version that you are targetting already has all the extensions that you need to use, so you don't need to check them one by one for the functionality that you are supporting, but just the OpenGL version. However, the target version always depends on what you need to do. If you want to support OpenGL 4.5, you need to know if all the GPUs that you want to support have that particular version of OpenGL. One day you could find that OpenGL 4.5 is not supported on a particular hardware and that your engine is not so good from a scalability point of view. Falling back to older OpenGL versions may require an entire refactor of the engine, that is not so nice if you had to release for tomorrow. On the contrary, if you need to support older versions of OpenGL from 3.0 onward, you will experiment on your person how hellish could be to deal with the outstanding amount of extensions that the library has just to support the most basic things. And anyway, this is not even the main problem. Even if you drop the past, you cannot prevent the GPUs vendors and the Khronos group from releasing extensions in the future that will be required to have decent performance on modern hardware, because the entire OpenGL architecture is obsolete. Continue reading →
I cookie permettono il funzionamento di alcuni servizi di questo sito internet. Utilizzando questi servizi, accetti l'utilizzo dei cookie da parte nostra.AccettaLeggi i dettagli