[Bf-committers] Technical Development Question

Joshua Leung aligorith at gmail.com
Thu Nov 5 07:11:26 CET 2009


On Thu, Nov 5, 2009 at 6:03 PM, Agustin Benavidez <
agustinbenavidez at gmail.com> wrote:

> I don't know if this is the right place to ask for technical
> development questions, so here we go.
> After download the source code and finally got compiled it, i spent a
> couple of hours reading the docs in
> http://wiki.blender.org/index.php/BlenderDev/Blender2.5 , looking at
> the code and so.
> ...I am still missing, of course this is the learning process, but now
> some concepts like operators, ui layout engine, RNA and so are more
> familiar to me.
> Q1) DNA is a collection of structs/functions that defines all the data
> editable and properties in blender (Meshes, configs, etc.), RNA is
> another collection of types/structs/Functions that is a abstraction
> layer of the DNA, and that RNA has functions and methods to write to
> RNA or read from it.
> So for example, blender 2.5 now does something like this:
>  - Load a .blend with DNA structs/functions, then fill the RNA with
> the DNA, and then the operators/modules and the whole blender start to
> run and operate through it. When close blender, the new/modif RNA data
> will be converted again to DNA and be saved in .blend.
> This is my interpretation of what i read.  IS ALL THIS RIGHT??
You're mostly on the right track there.


Blender stores all its data as a collection of C-structs defining what type
of data is stored for each type (i.e. property storage). This representation
is how data is stored in memory when Blender is running, and is also what
gets written to .blend files. In effect, this is the Data Layer / Main

The SDNA system takes these C-structs, and uses some "magic" to keep track
of the types+names of data stored in the structs and their ordering. This
info is used to ensure forward/backwards compatability, which it manages to
solve most of the time. There are some cases where manual intervention is

The RNA system is new in 2.5, and is basically an abstraction layer of the
data stored in the structs. It defines how to get/set properties stored in
the structs, and also defines some functions for working with them. It is
also used as the data-access backend for the animation system, is used by
the UI for getting/setting properties which include those used by the tools
(i.e. Operators), and is used for directly generating the Scripting API in
Python. However, most of the backend of Blender doesn't use this system,
instead, directly modifying the data stored in the structs.


Your description of what happens though is not quite right.

When you load a .blend file, the SDNA system loads the structs from the
file, and makes sure everything is set up nice again (i.e. relinking
pointers, dealing with variables changing order, and some limited type
conversions - for numerical types only).
However, this data is not 'converted' to an 'RNA form'. Although RNA defines
some type information which gets initialised at startup, this information is
only used as kind of template for interpreting that data that you tell it to
give you.

ALSO, would be fantastic if, in the wiki, some of you masters of the
> Development (which i really respect all of you), would create some
> tutorial and PRACTICAL EXAMPLE of how add a e.g. new module for add a
> text comment to a object, or how you port/add the transform
> manipulator and its buttons, showing THE PROCES TO ADD IT, WHERE THE
There are a few examples for some areas of Blender that area still current
AFAIK. Brecht wrote a few tutorials like this regarding how to add new

For actually adding features, one of the good ways is to watch out for
commits which add a feature similar to the one you want to add - i.e. look
out for a constraint commit if you're working on constraints. Most of the
time, these should be complete, though that may not always be the case.

Another good way is to trace a particular feature down by finding the UI
access for it, and tracing backwards from there...

Of course, this is as you say not a perfect substitute for documentation, I
shall try and make a few (lame) excuses anyway. A common problem we have, is
that there are just not enough knowledgeable people with the time and
motivation to write the documentation. Those that have the knowledge and
time, will probably be too busy actually writing the code to get much
documentation written (and often user documentation takes priority over
coder documentation, though there's not a lot of user documentation either
for some areas).

More information about the Bf-committers mailing list