Not
a Number, Feb-May 2000
The goal of this document is providing general information about the design specifications for Blender 2.0. It will only contain elements that actually were decided to implement.
Please note that this in not a discussion document. Changes in these papers are possible; but only by the project leaders and the CTO.
- data - visualize - edit cycle
The user selects data, selects a visualization of this data, and selects an editing tool that performs at the data. It is a valuable approach to disconnect ‘editing’ (logic) and ‘data’ from ‘interface’.
- minimuze usage of custom toolkits.
For every necessary toolkit we decide whether or not to make it in-house. Speed of building is not an (important) issue, more important is control, executable size, stability and platform independence. OpenGL and Python are good examples of valuable external toolkits. Having our own interface and windows toolkit has been proven important for Blender’s success.
- target group: creatives
Blender is made for creative people motivated to learn and work with 3D. Blender is professional freeware.
- Blender is small and runs at every OS and platform
Blender’s sources and development environment has to become ready to work at with a larger team of developers. Aspects are:
- CVS system
-
configuring develop platforms
- release system, including
preparing h/w
- automatic testing system
Taking Blender development into the next phase also means a thorough reconstruction and clean-up of the code. Most of this is necessary maintainance. To keep track of the limited available time a minumum reconstruction will be defined. Planned is to split development (after 2.1) and redefine Blender’s functionality completely for a 2.5 release.
Aspects for the short term are:
- C
file and library organisation (incl. functional docs)
- Redbook (C syntax, file
format, naming conventions)
- reconstructing C files
(prototyping, fullwarn)
- internal event system
- display list system
- check subloops, and get
rid of them where possible.
- improved inter-Object
relationships for deformation/animation.
-
Constraint Object? Hooks?
The strength of the interface is:
- allow tools and commands to be available in many ways: gestures, hotkeys, menu’s or buttons. This is for personalizing, speed and minimizing RSI.
- a configurable, non-overlapping parallel functioning interface.
- cross platform identical, both in looks as in functionality
- goal-oriented; making the job faster to do.
- Limited but well-balanced toolset. Don’t think for the user, but offer him the tools that work for him.
The weakness of the current interface is:
- non standard; based at Unix and in-house traditions
- hard to learn; it doesn’t communicate functionality well
- buttons interface is not configurable and out of date
- no undo!
Aspects to work at are:
- "Screen" with more flexible buttons/menu options
- new interface (buttons/menu) toolkit, including standard “windows” like header-menu and definition of flexible (user-definable) interface/button blocks
-
integration of Python scripting
The current cross-platform GLUT toolkit doesn’t provide the required functionality and stability for Blender. Also because we want Blender running at specialized OS’s (PS2, STB) it is necessary to build our own. As a blueprint we will use the IrisGL windows toolkit (and Skiddle, as started by Daniel Dunbar).
- single event queue
- multiple window handling
- complex events system
- hooks for other input devices (Python API?)
The prototype has been evaluated, and most of the system will be redefined completely.
- No Sector Object for spatially subdivision; this will be done automatically
- No special Life Object; this will be a general Object property
New in Blender 2.0 will be:
- a general property system: all ‘library blocks’ will have a (user defined) expandable set of properties.
- “Sensor”, “Controller” and “Actuator” library blocks. These three blocks define a general system to achieve real time interactivity.
- Constraints, a special property class to define spatial relations between 2 objects (hinges, chains, …)
- An editor (new window type) for applying “properties” and editing the sensor, controllers and actuators.
Blender will keep its current Object, Mesh, Material, etc. datastructure. This will be passed on to the game engine ‘as is’.
General prerequisites
- in total (compiled and gzipped) the GE doesn't exceed 0.5 Mb
-
the GE can start from within Blender (and returns) with a
minimum of
preprocessing and/or compilation time.
-
The GE returns to the editor when pressing ESC or SPACE,
unless it was
started from a player.
-
The GE internal data description reflects that of Blender's,
to allow
functionality being defined and edited with Blender. For example: it uses
Scenes, Objects, Materials, Ipo's...
-
As far as possible the GE uses Blender functions for shared
features such
as loading images, audio, calculating vertex keyframes, metaballs, nurbs, etc.
- The GE can run as a separate executable.
Input:
-
The GE basically only needs a pointer to a Scene, probably
with some
additional data about window settings (for example: drawmodes, or drawing
in multiple windows).
- The Scene can have additional Scenes linked:
- "Set", a scene used as a default environment (drawn and zbuffered integrated)
- "Backdrop", a scene used as background. For "sky" or other features (zbuffered independent)
- "Overlay". a scene used for interface stuff. (zbuffered independent)
- The Scene links to the Objects, and given the Scene's layer settings it displays and handles the 'visible' Objects. Layers can change during game play (scripting, Ipo)
- Every Blender Object type can be a part of the GE. Every Object can get dynamical or animated properties.
Drawing:
- All drawing modes supported by Blender are also supported in the GE. (wire, solid, shaded, textured)
- GE lighting can be more sophisticated. (I need a proposal for that)
-
Mesh Objects have per-face UV coordinates or get it
procedurally
calculated (OpenGL standard). Nurbs Objects already have builtin UV coords, and
can have it procedurally calculated.
- The GE supports a debug mode for visualisation of properties.
- The GE supports animated texturemaps
Physics and Collisions
- The physics and collision engine should be able to record positions and return it to Blender.
-
It should be able to cope with animated objects and dynamic
objects
interacting.
General features
- Record mouse/controller input for playback
- Play back (mpeg) movie clips
- Save the state of the current game variables.
- Python scripting will be used for more sophisticated interactivity and AI systems
See the “Ketsji” documents for a description of the:
- General Architecture (mgt syst)
- Event System
- I/O System integration
- Rasterizer
- Audio System integration
Basically we need audio for the game system, but support for
animation production (lip sync) is necessary too.
- based at the OpenAL API. It supports wav and mp3.
- low level API mapper for OpenAL.
- Blender editor: interface for simple visualisation and playback
Blender 2.0 tools/features
Several new tools are necessary to assist making games with Blender:
- pack/unpack (single files with textures and audio included)
- grouping of Objects
- particle system (deflectors, forces, game engine part)
-
Mesh knife tool
And new tools/features as planned in general for 2.0:
- IK system reconstruction, constraints.
- 4 x 32 bits rendering engine
- expanded Nurbs toolkit
Blender will be a full cross platform application, therefore it is wise to think about built-in limitations to discourage people to construct virusses with Blender. The only part in Blender sensitive for this potential danger is Python.
Most probably we will create a “sand-box” model for Blender Player (webBlender). We also will incorporate a “signature” system (PGP key).
Ton Roosendaal
CTO NaN