From the publication moment of the last article in the first big theoretical cycle has passed more than month. During this time, the new version of popular Linux distribution Ubuntu 9.10 has been released. It is pleasant to mark that the GDM (Gnome Display Manager) in the new release is behaving exactly as we described in the previous article "Few realism". I.e. the option of a desktop choice appears only after user name input, and by default it always -- the previous choice. Certainly, we can not say that this change of behavior was predicted by us - at the moment of article writing, for certain it has already occurred in the development version of the distributive. However, it well shows that our articles speak not about the invented problems of modern interfaces, and about absolutely essential. unDE project articles tell about development tendencies not of unearthly interface or of the interface of the far future, but about present, modern interface of computer systems.

Having talked enough about theory, we need to take care of the architecture of the new system. At this stage can not spare the time, after all, on it depends what in the future in our system will develop easily, and what not so. What reefs will arise by development and how soon it is necessary to rewrite all from zero.

In this article we will a little talk about the video subsystem architecture unDE. I.e. about system and ways of output interface units on the screen. We again will try to catch one of the last waves of development of modern interfaces - it begin to more use possibilities of videocards for interface output. Windows of versions Vista and Seven, KDE 4 practically is no longer working on computers of the beginning of the century, it literally "creeps" on this. We have a choice to base our drawing system on KDE 4 principles, having written the window manager with Compiz possibilities, or to offer other variant. It is necessary to mark that interfaces for construction of the accelerated applications for a graphic X Server are not yet well established and standardized. About it says in particular the fact that there is no terminal in which the background transparency (real, not pseudo) equally well would work as in environment KDE 4, and environment Gnome and in other window manager.

As a draw kernel we will try use a game engine of Blender 3D-editor. For an estimation of its possibilities it is necessary to play a little in game "Yo Frankie!" written by its community in 2008. On my computer with the Pentium 4 1,7 GHz processor and the GE Force 4 MX 440 videocard this game runs bright enough on eyes. In numbers this speed appears in the speed of drawing about 20 frames per second, falling on more difficult scenes to 8 frames per second. One can be sure that for absolute majority of our tasks there will be no necessity for drawing of scenes with complexity more than 20% from similar game scenes. So our system will work even more quickly, especially on modern computers. Also it will be easy to insert any 3D-effects or 3D-animation heroes into scenes.

In addition to the desktop machines we can also worry about performance on popular now netbooks. Fate has developed in such a way that just recently I bought a netbook Dell Inspiron 1010 with the video chipset from the Intel GMA 500. This chipset has been released in production relatively recently and the driver for it are in active development. At present last the driver from October, 8th, 2009 still very badly work with OpenGL, thus, that DirectX applications can fly. For example, SuperTux with enabled OpenGL starts to creep, and with the disabled acceleration - works perfectly! About any satisfactory performance of such game as "Yo Frankie!" here there is no to speak. Certainly, someone can tell that the blame is not the drivers, and the chipset, but I will object that there is the custom driver from Next Generation Coders with which and SuperTux in openGL mode does not brake (the truth at switching the screen becomes black, but it is corrected by switching in any other application and returning back), and in "Yo Frankie!" in a startup scene the bird flies well. Unfortunately further speed it was not possible to estimate, as after a choice of the options menu, the game has performed an illegal operation and was shut down. And at restartings produced it immediately. After several attempts of restarting this, Windows has at all shown the blue screen of death. Thus unfortunately the custom driver is too far from a stable state, but are unambiguously capable to squeeze out of the chipset GMA 500 more.

Usage of Blender game engine for rendering will allow us to create first of all cross-platform system. Unlike the same KDE 4, which cross-platform only at level of separate applications.

It is important to understand that unDE thus it can be started in modern systems as the ordinary window application. It will be especially convenient at the development initial stages while in unDE it will be impossible to carry out all tasks necessary for the majority of users. unDE it can be used at the initial stages as soon as text editor or just graphics editor etc. In process of development unDE can replace a growing number of applications until finally it cannot be run as the single application on X Server or in Windows-environment. Besides running unDE in other environments it is possible to implement and the reverse thing - start of X-applications in unDE environment. For this purpose it is necessary to implement the X-server protocol inside our system. However it is long-term schedules, and one of the first we will implement the virtual terminal to run in unDE any console applications of Unix-environment.

So, now our task is to understand Blender architecture and to take from its code the part which is responsible for rendering in game mode. First, we are not interested in the logic and animation - we will need to create the application which reads data about a static 3D scene from a Berkeley DB file and displays it on the screen. When you change a part of the database the image on the screen will immediately change.

One of curious features of Blender architecture is the binary format of its files. Each blend-file contains DNA of structures. DNA contains names of all fields, all structures used in it, their sizes and types. At loading Blender, knowing own DNA and file DNA, can easily recognise such modifications of structure as changes of an order of fields, changes of their size (for example, 16 bits on 32 bits) or type (for example, with float on integer and vice versa). Thanks to it Blender can open easy files created by the version of 10-year-old or vice versa the version much newer than installed on your computer Blender.

As we assume to use a binary format in unDE (BerkeleyDB) quite probably to adopt a similar approach and to write DNA of each file in one of the first records of a database.

Starting research of Blender code shows that it is desirable to study adequately Blender outside to know what are objects such as textures, materials, lamps, meshes, armatures, etc.

Now on Blender has appeared much more the documentation, than 5 years ago. Its community has extended, that is why studying of all its secrets by us became much easier.

We have started from wiki-book "Blender 3D: Noob to Pro" and first of all we managed to create following 3D-models (images of these models are distributed in article evenly):

Blender interface is rather original in comparison with the majority of modern applications. However, it strongly felt too many opportunities to do the same thing in many ways. Once unDE will be based on Blender code quite possibly will soon inherit the majority of its functionality, and it not only the 3D-editor, but at least the powerful video stream editor. But the interface will be essentially processed under the common unDE canons.

On it our first acquaintance with Blender is completed. In the following articles we will try to describe features of its architecture in the common words.