[Bf-committers] Technical Development Question

Agustin Benavidez agustinbenavidez at gmail.com
Fri Nov 6 09:50:18 CET 2009


Many Thanks Joshua!   Very good tip about reading the comits logs, i
find out the way to inspect them in the tortoiseSVN !  Of course no
much explanations and references about functions and so, but it helps
a lot!
Next time i'll try make questions more shorter, hopefully.
Thanks! Agus


2009/11/5 Joshua Leung <aligorith at gmail.com>:
> Hi,
>
> 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
> Database.
>
> 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
> necessary.
>
> 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
>> TYPES DECLARATION BELONG, WHERE PUT THE NEW MODULE, HOW OPERATE WITH
>> RNA, HOW ADD BUTTONS AND SO....
>>
> 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
> properties.
>
> 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).
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>


More information about the Bf-committers mailing list