Blender Development Plans
Perhaps Blender is the highest quality Open Source project. But the developers do not stop there and set ambitious goals for themselves. Next is a translation of an article in which developers share plans for how they see the future of their product.
In a previous post, we presented several technical and specific goals that we would like to achieve. Here they are:
1) Improving the performance of rendering code. We must be sure that we use the best visualization method, which maximizes the use of the GPU and features available only in new versions of OpenGL, which allow us to achieve improved performance and code;
2) Presentation of materials in the viewport based on nodes, and, accordingly, a new material visualization system in real time (for GLSL rendering);
3) The use of compositing in the viewport, which allows you to do effects such as DOF, Ambient Occlusion, HDR, bloom, flares, outline drawing;
4) Support for mobile devices (OpenGL ES ).
* Limited compositing (viewport_experiments development branch). When we say limited, we mean that compositing is not tied to display properties, it is applied to the entire contents of the frame buffer. Ideally, we want to ensure that in this mode, interface indicators, such as mesh or reinforcement, are displayed. This is not so difficult to achieve, in the end you can implement the same principle by which transparency or the X-ray system works, taking the object’s grid and bringing it to the top level of rendering.
* Some parts of our grid visualization code use Vertex Buffer Object optimally, others use but have performance problems, and some do not use it at all.
Soc_2014_viewport_fx will allow us to switch to new or mobile versions of OpenGL without fuss, as well as bring the experience of high-quality rendering that is required in modern versions of OpenGL, in which all rendering goes through Vertex Buffer Objects. It will also remove GLU dependency , as this library uses legacy OpenGL features.
In addition, it will give an impetus to such things and functions that can only be displayed by shaders. This is important if we move to the modern or mobile version of OpenGL at some point.
So this will mainly help with the 1st and 4th goals, but more work will need to be done after the merger in order to fully realize these goals.
At what point, if we want to support modern or mobile versions of OpenGL, we cannot avoid having to rewrite most of the real-time rendering code. This development branch has already partially taken care of this, so the branch must be introduced and used (in fact, merging is the very first step).
In my estimation, based on previous merger experiments, this should take about 2-3 weeks of hard work.
Yes we can. Goals such as node-based materials or copying simply require GLSL support, which is already fully implemented in the main branch, so that nothing prevents their development. Nevertheless, the sooner we introduce the Soc_2014_viewport_fx branch, the less problems we will have in the future.
Display modes become a little unpredictable when using materials limited to properties such as specular / diffuse / textured. They are also tied to the structure of polygons, which will become less significant if we use a display based on the properties of materials. Artists often adjust a different number of properties of objects and materials to visually get what they need, which is also sometimes a painful process and, of course, is not suitable for beginners. We need a tool with which artists can easily work, which can quickly visualize what they want, without the pain and fortune-telling in search of how to visualize it better.
Different workflows require different data and different display. We can define “workflows” with shader sets and display options created specifically for this workflow. For example, the desktop mode in editing mode will have basic diffuse and specular shaders with various grid display options. And, for example, the retopology mode is more suitable for a simple display of a mesh with volumetric transparency. To customize materials or texture painting, users may want a complete final picture or a version without a shader for detailed customization.
The Debug mode is designed to visually show the user problem areas in the scene. For example, calculating dependencies or the number of polygons, or even some parameters for developers.
Easy switching from one to another, easy setup or programming.
Using a workflow system, the user should see them most predictably. Each workflow may have the settings for the shaders used, but you must not let these shaders change too much. The node interface will allow you to request data from the blender, write it to your shaders, in order to present the data as the user wants.
With the capabilities that modern shaders offer, we aim to add another render to the blender using OpenGL (after Internal and Cycles), which could use all the features of modern GPUs, and given that it will be realtime, it could become an alternative existing renderings. Many components are already there, but we can go even further by optimizing the implementation of shaders, especially for real-time rendering, in return for trying to emulate existing renders.
We must be sure that the materials will look decent, so we are studying modern rendering methods, such as physically based shading (a patch from Clement Foucault, using data from Unreal Engine 4, is already practically turned on) and deferred rendering.
I must say that this also improves the preview of materials for Internal and Cycles.
In a previous post, we presented several technical and specific goals that we would like to achieve. Here they are:
1) Improving the performance of rendering code. We must be sure that we use the best visualization method, which maximizes the use of the GPU and features available only in new versions of OpenGL, which allow us to achieve improved performance and code;
2) Presentation of materials in the viewport based on nodes, and, accordingly, a new material visualization system in real time (for GLSL rendering);
3) The use of compositing in the viewport, which allows you to do effects such as DOF, Ambient Occlusion, HDR, bloom, flares, outline drawing;
4) Support for mobile devices (OpenGL ES ).
What do we have at the moment?
* Limited compositing (viewport_experiments development branch). When we say limited, we mean that compositing is not tied to display properties, it is applied to the entire contents of the frame buffer. Ideally, we want to ensure that in this mode, interface indicators, such as mesh or reinforcement, are displayed. This is not so difficult to achieve, in the end you can implement the same principle by which transparency or the X-ray system works, taking the object’s grid and bringing it to the top level of rendering.
* Some parts of our grid visualization code use Vertex Buffer Object optimally, others use but have performance problems, and some do not use it at all.
How will the soc_2014_viewport_fx development branch help us achieve our goals?
Soc_2014_viewport_fx will allow us to switch to new or mobile versions of OpenGL without fuss, as well as bring the experience of high-quality rendering that is required in modern versions of OpenGL, in which all rendering goes through Vertex Buffer Objects. It will also remove GLU dependency , as this library uses legacy OpenGL features.
In addition, it will give an impetus to such things and functions that can only be displayed by shaders. This is important if we move to the modern or mobile version of OpenGL at some point.
So this will mainly help with the 1st and 4th goals, but more work will need to be done after the merger in order to fully realize these goals.
At what point, if we want to support modern or mobile versions of OpenGL, we cannot avoid having to rewrite most of the real-time rendering code. This development branch has already partially taken care of this, so the branch must be introduced and used (in fact, merging is the very first step).
In my estimation, based on previous merger experiments, this should take about 2-3 weeks of hard work.
Can we focus on some goals today?
Yes we can. Goals such as node-based materials or copying simply require GLSL support, which is already fully implemented in the main branch, so that nothing prevents their development. Nevertheless, the sooner we introduce the Soc_2014_viewport_fx branch, the less problems we will have in the future.
Viewport, usability
Display modes
Display modes become a little unpredictable when using materials limited to properties such as specular / diffuse / textured. They are also tied to the structure of polygons, which will become less significant if we use a display based on the properties of materials. Artists often adjust a different number of properties of objects and materials to visually get what they need, which is also sometimes a painful process and, of course, is not suitable for beginners. We need a tool with which artists can easily work, which can quickly visualize what they want, without the pain and fortune-telling in search of how to visualize it better.
Operating modes (editing, sculpting, drawing, animation, game shader development)
Different workflows require different data and different display. We can define “workflows” with shader sets and display options created specifically for this workflow. For example, the desktop mode in editing mode will have basic diffuse and specular shaders with various grid display options. And, for example, the retopology mode is more suitable for a simple display of a mesh with volumetric transparency. To customize materials or texture painting, users may want a complete final picture or a version without a shader for detailed customization.
Debugging (logic, reinforcement, etc.)
The Debug mode is designed to visually show the user problem areas in the scene. For example, calculating dependencies or the number of polygons, or even some parameters for developers.
Easy switching from one to another, easy setup or programming.
Using a workflow system, the user should see them most predictably. Each workflow may have the settings for the shaders used, but you must not let these shaders change too much. The node interface will allow you to request data from the blender, write it to your shaders, in order to present the data as the user wants.
Perfection! Users want a better, more realistic
With the capabilities that modern shaders offer, we aim to add another render to the blender using OpenGL (after Internal and Cycles), which could use all the features of modern GPUs, and given that it will be realtime, it could become an alternative existing renderings. Many components are already there, but we can go even further by optimizing the implementation of shaders, especially for real-time rendering, in return for trying to emulate existing renders.
We must be sure that the materials will look decent, so we are studying modern rendering methods, such as physically based shading (a patch from Clement Foucault, using data from Unreal Engine 4, is already practically turned on) and deferred rendering.
I must say that this also improves the preview of materials for Internal and Cycles.