Dev:Ref/Requests/Internal Refactor

Internal Refactor (AKA "Blender Evolved")

point of contact: Bob Holcomb bob_holcomb-at-hotmail.com

Design Overview

Overview

This is an attempt to refactor the internal key components of blender in an effort to support a more modular design. This will allow greater flexibility and easier extendability in blender's future without changing the look and feel of the application or losing any functionality.

However the old phrase, "you can't make an omelet without breaking a few eggs" is ever so true. A majority of the ideas presented here are intended to be coded in C++ and Lua. I will try to provide rationale for my ideas since some deviate substantially from the current code base.

Rationale: I choose Lua over python for several reasons. First, it is by design, easier to embed in an application, whereas python was designed to be extended. As new features are added to blender, this is an important consideration for the scripting capabilities. Lua is also significantly faster than most other scripting languages and also offers a Just-In-Time compiler that requires zero extra work on the script developers once it has been integrated (which is a drop in change) and boosts performance to near-native code speed.

The main ideas is that the main blender application becomes a kernel that manages modules. Each modules represents a space (or possibly several related spaces). The kernel is able to load/unload modules at runtime. The kernel also manages the data structures that the modules define. This allows for new modules to be developed and tested without having to rebuild the entire tree.

Candidate Modules and Kernel Libraries

• Event System
• Math Library
• Scripting System
• Rendering Module
• Audio System
• Utility Libraries
• Module Loader
• Space Factory
• Various Spaces (Image editing, UV layout, 3d Mesh, text editor, etc)
• UI Factory
• UI Elements (function objects=can be stateful, but don't have to be)
• Data System
• Data Storage
• IPO system

Compiled In Modules

Some modules may be compiled in with the kernel so that a base install will always be somewhat functional:

• IPO
• Text Editor
• GUI Editor
• Command Prompt
• Settings Module
• Data Manager

This base install will provide an environment that is a capable tool for creating new modules. Custom modules built in this fashion will be script based, but the end user should not be able to tell the difference since all functionality should be scriptable.

A module will be responsible for several things:

• Registering data types
• loader/saver for said data types
• register new spaces to visualize/edit said data types
• register menus in other spaces (add a menu to the settings space)
• require other modules be loaded

Dependencies

This is a list of possible dependencies that could be expected

• Lua 5.1
• Lua Modules (luaGL, LuaSocket, LuaSQL, LuaFilename, LuaZip)
• FFMPEG
• Freetype 2
• FreeImage or DevIL
• sqlite
• GLEW
• GLFW or SFML or SDL or just keep GHOST

Unsorted Ideas

• abstract script/plugin API with more script backends (Lua, Squirrel, Python, etc)
• realtime game editing
• allow to embed blender as an opengl widget (embed into ogre or QT::GLWidget, etc)