Blender Development Plans

Perhaps Blender is the highest quality Open Source project. But the developers do not stop on their laurels and set ambitious goals. Further translation of the article, in which developers share plans for how they see the future of their product.



In the previous post, we presented several technical and specific goals that we would like to achieve. Here they are:

1) Improving the performance of the drawing code. We must be sure that we use the best visualization method that maximizes the capabilities of the GPU and the features available only in newer versions of OpenGL, which allow us to achieve improvements in performance and code;
2) Presentation of materials in viewport based on nodes, and accordingly, a new system for visualizing materials in real time (for GLSL rendering);
3) The use of compositing in the viewport, which allows to do such effects as DOF, Ambient Occlusion, HDR, bloom, flares, contour rendering;
4) Mobile device support ( OpenGL ES ).
')

What we have at the moment

* Limited compositing (viewport_experiments development branch). When we say limited, we mean that composing is not tied to the properties of the display, it is applied to the entire contents of the frame buffer. Ideally, we want to ensure that interface indicators, such as mesh or reinforcement, are displayed in this mode. This is not so difficult to achieve, in the end, you can implement the same principle by which the transparency or X-ray system works, taking the object's grid and bringing it to the top rendering level.
* Some parts of our grid visualization code use Vertex Buffer Object optimally, others use it, but have performance problems, and some don't use it at all.

How will the soc_2014_viewport_fx development branch help us in achieving 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, which are required in modern versions of OpenGL, in which all rendering goes through Vertex Buffer Objects. It will also remove the GLU dependency, since this library uses the obsolete OpenGL features.

In addition, it will give impetus to such things and functions that can only be displayed by shaders. This is important if we move to a modern or mobile version of OpenGL at some point.

So this will mostly help with 1st and 4th goals, but more work will need to be done after the merger to realize these goals in full.

At what point, if we want support for modern or mobile versions of OpenGL, we will not be able to avoid having to rewrite most of the real-time rendering code. In this development branch we have 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 experiments on merging branches, this should take about 2-3 weeks of hard work.

Can we focus on some goals today?

Yes we can. Goals such as material based on nodes or copying simply assume support for GLSL, which is already fully implemented in the mainline, so nothing prevents their development. However, the earlier we add the Soc_2014_viewport_fx branch, the less we will have problems in the future.

Viewport, usability

Display modes

Display modes become a bit unpredictable when using materials limited by properties such as specular / diffuse / textured. They are also tied to the structure of polygons, which will become less significant if we use the mapping based on the properties of materials. Artists often set up a different number of properties of objects and materials in order to visually get what they need, which is also sometimes a painful process and, of course, does not suit beginners. We need a tool that artists can easily work with, who can quickly visualize what they want without torment and divination in search of how to visualize it better.

Operating modes (editing, sculpting, drawing, animation, development of game shaders)

Different workflows require different data and different displays. We can define “workflows” with sets of shaders and display options created specifically for this workflow. For example, the desktop mode in edit mode will have basic diffuse and specular shaders with various grid display options. And, for example, a simple grid display with volumetric transparency is more suitable for the retopology mode. To customize materials or texture painting, users may want a full final picture or a non-kernel version for detailed settings.

Debugging (logic, armature, etc.)

The “Debug” mode is intended to visually show the user the problem areas in the scene. For example, the calculation of dependencies or the number of polygons, or even some parameters for developers.
Easy to switch from one to another, easy setup or programming.
Using the workflow system, the user should see them as predictable as possible. Each worker thread may have settings for the shaders used, but you should not let these shaders change too much. The interface of the nodes will allow you to request data from the blender to write them to their shaders, in order to present the data as the user wants.

Perfection! Users want a better, more realistic

With the possibilities offered by modern shaders, we aim to add to the blender another render using OpenGL (after Internal and Cycles), which could use all the capabilities of modern GPUs, and given that it will be realtime, it could be an alternative existing renders. Many components are already there, but we can go even further by optimizing the implementation of shaders, especially for real-time rendering, instead of trying to emulate existing renderers.

We need to be sure that the materials will look decent, so we are studying modern rendering methods, such as physically based shading (the patch from Clement Foucault, using data from the Unreal Engine 4, is almost turned on) and deferred rendering.

I must say that it also improves the preview of materials for Internal and Cycles.