Dev:2.5/Source/Architecture/Module Organization Proposal

Module Organization Proposal

Note: this is a proposal for organization of the source code modules in Blender. At the moment it is not an approved 2.50 project to re-organize the source like this, it's just an idea.

-- Brecht 00:40, 31 May 2008 (UTC)

In the 2.50 branch, the src/ directory is split up into spaces, and given the large architectural changes, it might also be a good time to rethink the source code layout more fundamentally.

The operaterization of the code and other user interface related changes pose the question of how exactly to separate out user interface code. The src/ directory contains many functions that are not directly user interface code, or functions which might be shared between multiple spaces. One solution is to move such functions to blenkernel/, but this module is also becoming quite large and could be split up.

A diagram of proposed levels is below, compare to these diagrams. Besides the fact that the extern and OS level are left out in this diagram, note the main changes:

• The Intern Libraries layer is gone and merged into other layers.
• The new Utilities layer containing blenlib and some intern libraries.
• The new Compute layer, combining code from blenkernel, src and some intern libraries.

A two-level hierarchy would be used, also joining modules from intern/ more closesly into the code, but still in separate subdirections. The submodules mostly give an indication of the contents, not a real proposal for subdirections.

util/
	guardedalloc/ 
	memutil/
	datatypes/
	datatypes-c++/
	io/
	arithb/
	moto/
	opennl/

Util would contain generally useful functions that do not depend on Blender data, and can be used from any other module. This module has no dependencies.

kernel/
	blenloader/
	readblenfile/
	blenkernel/
	makesdna/
	dataaccessapi/

Kernel contains functions for file reading and writing, DNA, datablock manipulation, libraries, data access, .. i.e. the core of Blender. This module depends on Util.

model/
	boolop/
	bsp/
	decimation/
	bmesh/
	nurbs/
	curves/

Model contains anything related to modelling: mesh editing, nurbs, curves, modifiers, booleans, decimation. This module depends on Util, Kernel.

animate/
	iksolver/
	elbeem/
	particles/
	cloth/
	softbody/
	collison/

Animate contains anything related animation and physics simulation. This module depends on Util, Kernel, Model.

media/
	soundsystem/
	imbuf/
	avi/
	quicktime/
	bmfont/
	ftfont/
	sequencer/
	compositor/

Media contains anything related to images, video, sound and fonts. This module depends on Util, Kernel.

evaluate/
	depsgraph/
	time/
	modifiers/
	nodes/

Evaluate contains anything related to dependency graph evaluation. It works on runtime data, not data saved to file. This was split off Kernel in order to avoid circular dependencies, Additionally, code in this module should become threadsafe and multithreaded. It depends on Util, Kernel, Model, Animate, Media, Render.

render/
	internal/
	yafray/
	radiosity/
	api/
	shadernodes/

Render contains anything related to rendering. This module depends on Util, Kernel, Evaluate, Media.

gameengine/
	gamelogic/
	rasterizer/
	..

Game Engine depends on Util, Kernel, Evaluate, Render.

windowmanager/
	ghost/
	creator/

Window Manager contains ghost, the event system, operators, notifiers, window management, ... i.e. core user interface functionality. This module depends on Kernel and Util.

editors/
	screen/
	space_view3d/
	space_image/
	..

Editors contains the user interface consisting of all spaces, operators. This module depends on most other modules.

scripting/
	python/
	blenpluginapi/

Scripting contains python scripting and external plugin api. It depends on many other modules to wrap their contents.

To wrap up, Extern and Util contain code without other dependencies that can be used from any other module. Kernel contains the core data manipulation. Evaluate handles runtime evaluation. Window Manager and Editors contains the user interface code. Model, Animate and Media contain code that is generally indepent of the user interface, but do contain the internal implementations of non-trivial operators. The code in these modules can be executed as part of an operator, or as part of a dependency graph evaluation. Render and Game Engine get their data through the Evaluate module. Scripting wraps code from nearly all other modules.

Issues

• What exactly goes into Model, Animate, Media? Currently the proposal says "non-trivial operations", but that is quite vague of course. The reason to have such modules separate is to separate them from the interface level, without stuffing everything into blenkernel.

• Do we want the modules from intern/ together with the other code? I personally think this makes for a more logical structure, and the practical difference is quite small as long as C++ modules stay separated, to me the current separation seems more historical than designed.