Blender的架构

minlearn

所以，你们看到的the blender editor 处在第二，第三个层次。
blender是一个产品体系，它至少存在三个层次的产品： THE ENGINE(RENDER&CG),THE EDITOR(EDITORS,修改器)&THE GAME ENGINE ,THE EXTENDING PARTS(PY SCRIPTS,NATIVE PLUGINS)
EDITOR SCENE 与 GAME SCENE 是不一样的。
EDITOR和GAME需要的cg&render style根本是不一样的，一个不要求REAL TIME,一个强烈需要实时，故，blender src中，场景图这样的强化帧速促成实时的算法只出现在GAME ENGINE中。
BLENDER 中使用的库都是面向问题的专题库，而不是通用库，这使它成为从C级研究问题的良好参考源码库，只有经过C++的封装抽象后，才转为通用的。
BLENDERP是一个包含CG和GAME逻辑的源码系统，并不等于也不是THE BLENDER EDITOR。
BLENDER LIB 就是 BLENDER SRC中那个BLENLIB，现在的问题是：它将整个blender src中那些部分做进了这个（供c++编译进行静态链接）的库（将其）中，又有那些部分是做成了PLUGIN（供操作系统运行时导入）的。这是研究BLENDER SRC的基本和常识。
BLENDR EDITOR 本身，是作为blender lib的扩展级的产品级出现的。BLENDER SRC中，对每一个它使用到的EXTERN LIB 都进行了to c++的抽象与封装（放在INTERAL 中），这使它成为一套很好的研究两种语言混合编程的参考源码。

minlearn

1.BLENDER 并没有隐藏图形程序领域的任何抽象，而且它提供了流行的产品级支持有成型的产品线支持，所以他是一个程序员复用，参考，学习，开发的良好素材。
2.架构最重要的，应是提供正确的领域抽象体系（在复用了其他外来库的情况下，也至少应在它那个层次提供正确的抽象和接口），而不是设计模式语言技法等复用抽象，正确的抽象对专业程序员的复用目的的参考价值始终是第一位的。
3.我常想，架构的合理性到底在哪？首先，它不应该隐蔽领域抽象，而给复用它的程序员一套纯粹的复用抽象（而这是面向接口的编程积极提倡的），因为这样一来，专业的程序员看不到这个程序在这个领域的抽象所处。