blender data model (Re: py drawing to 3dview (Re: [Bf-committers] User-defined Material Properties))

antont at antont at
Thu Oct 20 13:03:06 CEST 2005

On Wednesday 19 October 2005 02:29, Greg MacDonald wrote:
> I assume you're directing these comments to me, because its under my old
> thread name. I just wanted to inform you that someone else should pick up

as someone already pointed out, that was a false assumption - i even changed 
the subject line to have the subject i e-mailed about. now i changed it 
again :) . the 'py drawing to 3dview' was to the main developers and the 
python team.

> the torch because I've decided not to contribute. I think the most
> important thing Blender needs to do right now is replace the internal data
> model with an extensible, object oriented design. I also believe strongly

well, that may well be true from your point of view. from many other angles, 
the current SDNA is pretty elegant and flexible and is serving its purpose 
well, and the current problems are totally different (like the inability to 
have multiple materials layered on a single object, or the lack of Python 
modifiers -- which are both coming soon I think). if features such as those 
require changes to the Blender data model, those changes are just made, and 
it does not break forwards compatibility (you can still open old .blends in 
new versions etc.), so things are good. i believe Blender enables us (here at 
Orange) to make the Elephants Dream a good movie.

but i do agree that the data model deserves rethinking, and perhaps a 
reimplementation. and like said, have some plans for it too (as do other 
people). Ton even started it at one point some time ago (as project Olive), 
but he then observed that Blender could be developed further without a change 
of architecture, which has proven to be true. like now we have the dependency 
graph and a totally rewritten character animation system, which is a major 

> If Maya can be rewritten, Blender can too. And be done in a way that all
> the old scripts still work the same. 

Of course. And like said, parts of it already have been.

Also the Python API has a history of rewrites, and also it has been adjusted 
to rewrites in the core (like the Text3D module works in 2.40 with the new 
text/font object code that was added recently, but the scripts made with 
2.37a where the Text3d module was introduced with the old code that was in 
then, work of course).

> I know you paid a lot for that C 
> program, but now that you have everyone's attention you surely can muster
> the troops for a rewrite. If I were to rewrite Blender, I'd probably end up
> doing it from scratch and then porting pieces over to the new framework.
> But I have a job and don't have time. Its really not a one man project.

my idea actually is to start the rewrite from the data model, like i said, 
port/change the SDNA. instead of enforcing a class hierarchy, i've been 
thinking of using interfaces i.e. 'duck typing': "if it walks like a duck, 
and talks like a duck, it must be a duck.". no matter what type it has 
otherwise. so it is not required to inherit anything or somesuch to create 
e.g. your own material type. and if someone would manage to write a thing / 
object that is at the same time e.g. a material and mesh, the 'DuckBlender' 
would not care. for more info on duck typing see e.g. . this thinking of the basic architecture i 
like to keep independent of programming languages and other such details, so 
i'm thinking of it as 'project white'.

then in 'project green' (so not quite Olive :) the plan is to start 
implementing such a new datamodel in Python - i.e. port the sdna to Python 
something (probably classes). as you probably saw, Blender has it's own 
linked list and hashtable, as does Python, so Green uses the Python ones 
instead. the idea is to continue using as much of the existing C code as 
possible, to have the change done quickly (like in a couple of months). 
Python lists and hashtables are fast (i actually hope that faster then the 
current Blender ones), so i hope that it works ok for Blender to just start 
using them .. am also hoping that they are similar to use, so that the 
existing code is easy to modify to work with the python data. this should 
give us a running prototype, more or less the existing Blender, so we can 
examine the performance etc. to find possible bottlenecks etc. if the basic 
data access proves to be too slow or otherwise bad, then Green is just 

but if that Green prototype would work well, well, then i'd just use it :) and 
then we could start rewriting more parts of Blender in Python, to have a 
modular architecture that enables UI configuring, has a nice event system 
etc. and eventually "only" the CPU intensive parts would remain in C (quotes 
because those are the major and large parts, like transforms, many modifiers, 
and of course the renderer. and the opengl wrapping Ghost. so Python would 
just give the basic data types (lists, hastables) and combine the parts 
together, enabling configuring etc). for holding large amounts of numerical 
data such as vertices and pixels, the Python Numerical libraries provide 
efficient c-written Arrays etc.

> This is my honest professional opinion. I offer it not to be mean, but with
> the hope someone can do something constructive with it. If I wanted to be

sure, and thanks for that. i don't know if you were saying much new actually, 
'cause many people have thought about many of these things, but at least you 
brought the issue up again so that i became to voice my recent little 
ideas :o

i think i will use like ~0.5% of my time here at Orange to start Green slowly 
(doing the thinking when being at home and drawing something to my notebook, 
which is my own time, right?-) , 'cause it wont help with the current issues 
in the coming months, and it does not contribute to the movie in making. but 
there seem to be other people interested in these things, and perhaps with 
more urgent needs, so who knows perhaps we get somewhere. then in March or so 
when the movie is all rendered and packaged etc., i hope the needs of my work 
coincide with such developments. 

in the meantime, i hope you have fun with Maya :)
(no irony there. i've understood it's on ok app. like Ton once said, it's 
Blender's girlfriend .. (so i don't know how the recent business moves 

> -Greg


More information about the Bf-committers mailing list