svn merge ^/trunk/blender -r43294:43338
[blender.git] / doc / python_api / rst / info_overview.rst
1 *******************
2 Python API Overview
3 *******************
4
5 This document is to give an understanding of how python and blender fit together, covering some of the functionality that isn't obvious from reading the API reference and example scripts.
6
7
8 Python in Blender
9 =================
10
11 Blender embeds a python interpreter which is started with blender and stays active. This interpreter runs scripts to draw the user interface and is used for some of Blender's internal tools too.
12
13 This is a typical python environment so tutorials on how to write python scripts will work running the scripts in blender too. Blender provides the :mod:`bpy` module to the python interpreter. This module can be imported in a script and gives access to blender data, classes, and functions. Scripts that deal with blender data will need to import this module. 
14
15 Here is a simple example of moving a vertex of the object named **Cube**:
16
17 .. code-block:: python
18
19    import bpy
20    bpy.data.objects["Cube"].data.vertices[0].co.x += 1.0
21
22 This modifies Blender's internal data directly. When you run this in the interactive console you will see the 3D viewport update.
23
24
25 The Default Environment
26 =======================
27
28 When developing your own scripts it may help to understand how blender sets up its python environment. Many python scripts come bundled with blender and can be used as a reference because they use the same API that script authors write tools in. Typical usage for scripts include: user interface, import/export, scene manipulation, automation, defining your own toolset and customization.
29
30 On startup blender scans the ``scripts/startup/`` directory for python modules and imports them. The exact location of this directory depends on your installation. `See the directory layout docs <http://wiki.blender.org/index.php/Doc:2.6/Manual/Introduction/Installing_Blender/DirectoryLayout>`_
31
32
33 Script Loading
34 ==============
35
36 This may seem obvious but it's important to note the difference between executing a script directly or importing it as a module.
37
38 Scripts that extend blender - define classes that exist beyond the scripts execution, this makes future access to these classes (to unregister for example) more difficult than importing as a module where class instance is kept in the module and can be accessed by importing that module later on.
39
40 For this reason it's preferable to only use directly execute scripts that don't extend blender by registering classes.
41
42
43 Here are some ways to run scripts directly in blender.
44
45 * Loaded in the text editor and press **Run Script**.
46
47 * Typed or pasted into the interactive console.
48
49 * Execute a python file from the command line with blender, eg:
50
51   ``blender --python /home/me/my_script.py``
52
53
54 To run as modules:
55
56 * The obvious way, ``import some_module`` command from the text window or interactive console.
57
58 * Open as a text block and tick "Register" option, this will load with the blend file.
59
60 * copy into one of the directories ``scripts/startup``, where they will be automatically imported on startup.
61
62 * define as an addon, enabling the addon will load it as a python module.
63
64
65 Addons
66 ------
67
68 Some of blenders functionality is best kept optional, alongside scripts loaded at startup we have addons which are kept in their own directory ``scripts/addons``, and only load on startup if selected from the user preferences.
69
70 The only difference between addons and built-in python modules is that addons must contain a **bl_info** variable which blender uses to read metadata such as name, author, category and URL.
71
72 The user preferences addon listing uses **bl_info** to display information about each addon.
73
74 `See Addons <http://wiki.blender.org/index.php/Dev:2.6/Py/Scripts/Guidelines/Addons>`_ for details on the **bl_info** dictionary.
75
76
77 Integration through Classes
78 ===========================
79
80 Running python scripts in the text editor is useful for testing but you’ll want to extend blender to make tools accessible like other built-in functionality.
81
82 The blender python api allows integration for:
83
84 * :class:`bpy.types.Panel`
85
86 * :class:`bpy.types.Menu`
87
88 * :class:`bpy.types.Operator`
89
90 * :class:`bpy.types.PropertyGroup`
91
92 * :class:`bpy.types.KeyingSet`
93
94 * :class:`bpy.types.RenderEngine`
95
96
97 This is intentionally limited. Currently, for more advanced features such as mesh modifiers, object types, or shader nodes, C/C++ must be used.
98
99 For python intergration Blender defines methods which are common to all types. This works by creating a python subclass of a Blender class which contains variables and functions specified by the parent class which are pre-defined to interface with Blender.
100
101 For example:
102
103 .. code-block:: python
104
105    import bpy
106    class SimpleOperator(bpy.types.Operator):
107        bl_idname = "object.simple_operator"
108        bl_label = "Tool Name"
109
110        def execute(self, context):
111            print("Hello World")
112            return {'FINISHED'}
113
114    bpy.utils.register_class(SimpleOperator)
115
116 First note that we subclass a member of :mod:`bpy.types`, this is common for all classes which can be integrated with blender and used so we know if this is an Operator and not a Panel when registering.
117
118 Both class properties start with a **bl_** prefix. This is a convention used to distinguish blender properties from those you add yourself.
119
120 Next see the execute function, which takes an instance of the operator and the current context. A common prefix is not used for functions.
121
122 Lastly the register function is called, this takes the class and loads it into blender. See `Class Registration`_.
123
124 Regarding inheritance, blender doesn't impose restrictions on the kinds of class inheritance used, the registration checks will use attributes and functions defined in parent classes.
125
126 class mix-in example:
127
128 .. code-block:: python
129
130    import bpy
131    class BaseOperator:
132        def execute(self, context):
133            print("Hello World BaseClass")
134            return {'FINISHED'}
135
136    class SimpleOperator(bpy.types.Operator, BaseOperator):
137        bl_idname = "object.simple_operator"
138        bl_label = "Tool Name"
139
140    bpy.utils.register_class(SimpleOperator)
141
142 Notice these classes don't define an ``__init__(self)`` function. While ``__init__()`` and ``__del__()`` will be called if defined, the class instances lifetime only spans the execution. So a panel for example will have a new instance for every redraw, for this reason there is rarely a cause to store variables in the panel instance. Instead, persistent variables should be stored in Blenders data so that the state can be restored when blender is restarted.
143
144 .. note:: Modal operators are an exception, keeping their instance variable as blender runs, see modal operator template.
145
146 So once the class is registered with blender, instancing the class and calling the functions is left up to blender. In fact you cannot instance these classes from the script as you would expect with most python API's.
147
148 To run operators you can call them through the operator api, eg:
149
150 .. code-block:: python
151
152    import bpy
153    bpy.ops.object.simple_operator()
154
155 User interface classes are given a context in which to draw, buttons window, file header, toolbar etc, then they are drawn when that area is displayed so they are never called by python scripts directly.
156
157
158 Registration
159 ============
160
161
162 Module Registration
163 -------------------
164
165 Blender modules loaded at startup require ``register()`` and ``unregister()`` functions. These are the *only* functions that blender calls from your code, which is otherwise a regular python module.
166
167 A simple blender/python module can look like this:
168
169 .. code-block:: python
170
171    import bpy
172
173    class SimpleOperator(bpy.types.Operator):
174        """ See example above """
175
176    def register():
177        bpy.utils.register_class(SimpleOperator)
178
179    def unregister():
180        bpy.utils.unregister_class(SimpleOperator)    
181
182    if __name__ == "__main__":
183        register()
184
185 These functions usually appear at the bottom of the script containing class registration sometimes adding menu items. You can also use them for internal purposes setting up data for your own tools but take care since register won't re-run when a new blend file is loaded.
186
187 The register/unregister calls are used so it's possible to toggle addons and reload scripts while blender runs.
188 If the register calls were placed in the body of the script, registration would be called on import, meaning there would be no distinction between importing a module or loading its classes into blender.
189
190 This becomes problematic when a script imports classes from another module making it difficult to manage which classes are being loaded and when.
191
192 The last 2 lines are only for testing:
193
194 .. code-block:: python
195
196    if __name__ == "__main__":
197        register()
198
199 This allows the script to be run directly in the text editor to test changes.
200 This ``register()`` call won't run when the script is imported as a module since ``__main__`` is reserved for direct execution.
201
202
203 Class Registration
204 ------------------
205
206 Registering a class with blender results in the class definition being loaded into blender, where it becomes available alongside existing functionality.
207
208 Once this class is loaded you can access it from :mod:`bpy.types`, using the bl_idname rather than the classes original name.
209
210 When loading a class, blender performs sanity checks making sure all required properties and functions are found, that properties have the correct type, and that functions have the right number of arguments.
211
212 Mostly you will not need concern yourself with this but if there is a problem with the class definition it will be raised on registering:
213
214 Using the function arguments ``def execute(self, context, spam)``, will raise an exception:
215
216 ``ValueError: expected Operator, SimpleOperator class "execute" function to have 2 args, found 3``
217
218 Using ``bl_idname = 1`` will raise.
219
220 ``TypeError: validating class error: Operator.bl_idname expected a string type, not int``
221
222
223 Multiple-Classes
224 ^^^^^^^^^^^^^^^^
225
226 Loading classes into blender is described above, for simple cases calling :mod:`bpy.utils.register_class` (SomeClass) is sufficient, but when there are many classes or a packages submodule has its own classes it can be tedious to list them all for registration.
227
228 For more convenient loading/unloading :mod:`bpy.utils.register_module` (module) and :mod:`bpy.utils.unregister_module` (module) functions exist.
229
230 A script which defines many of its own operators, panels menus etc. you only need to write:
231
232 .. code-block:: python
233
234    def register():
235        bpy.utils.register_module(__name__)
236
237    def unregister():
238        bpy.utils.unregister_module(__name__)
239
240 Internally blender collects subclasses on registrable types, storing them by the module in which they are defined. By passing the module name to :mod:`bpy.utils.register_module` blender can register all classes created by this module and its submodules.
241
242
243 Inter Classes Dependencies
244 ^^^^^^^^^^^^^^^^^^^^^^^^^^
245
246 When customizing blender you may want to group your own settings together, after all, they will likely have to co-exist with other scripts. To group these properties classes need to be defined, for groups within groups or collections within groups you can find yourself having to deal with order of registration/unregistration.
247
248 Custom properties groups are themselves classes which need to be registered.
249
250 Say you want to store material settings for a custom engine.
251
252 .. code-block:: python
253
254    # Create new property
255    # bpy.data.materials[0].my_custom_props.my_float
256    import bpy
257
258    class MyMaterialProps(bpy.types.PropertyGroup):
259        my_float = bpy.props.FloatProperty()
260
261    def register():
262        bpy.utils.register_class(MyMaterialProps)
263        bpy.types.Material.my_custom_props = bpy.props.PointerProperty(type=MyMaterialProps)
264
265    def unregister():
266        del bpy.types.Material.my_custom_props
267        bpy.utils.unregister_class(MyMaterialProps)
268
269    if __name__ == "__main__":
270        register()
271
272 .. note::
273
274    *The class must be registered before being used in a property, failing to do so will raise an error:*
275    
276    ``ValueError: bpy_struct "Material" registration error: my_custom_props could not register``
277
278
279 .. code-block:: python
280
281    # Create new property group with a sub property
282    # bpy.data.materials[0].my_custom_props.sub_group.my_float
283    import bpy
284
285    class MyMaterialSubProps(bpy.types.PropertyGroup):
286        my_float = bpy.props.FloatProperty()
287
288    class MyMaterialGroupProps(bpy.types.PropertyGroup):
289        sub_group = bpy.props.PointerProperty(type=MyMaterialSubProps)
290
291    def register():
292        bpy.utils.register_class(MyMaterialSubProps)
293        bpy.utils.register_class(MyMaterialGroupProps)
294        bpy.types.Material.my_custom_props = bpy.props.PointerProperty(type=MyMaterialGroupProps)
295
296    def unregister():
297        del bpy.types.Material.my_custom_props
298        bpy.utils.unregister_class(MyMaterialGroupProps)
299        bpy.utils.unregister_class(MyMaterialSubProps)
300
301    if __name__ == "__main__":
302        register()
303
304 .. note::
305
306    *The lower most class needs to be registered first and that unregister() is a mirror of register()*
307
308
309 Manipulating Classes
310 ^^^^^^^^^^^^^^^^^^^^
311
312 Properties can be added and removed as blender runs, normally happens on register or unregister but for some special cases it may be useful to modify types as the script runs.
313
314 For example:
315
316 .. code-block:: python
317
318    # add a new property to an existing type
319    bpy.types.Object.my_float = bpy.props.FloatProperty()
320    # remove
321    del bpy.types.Object.my_float
322
323 This works just as well for PropertyGroup subclasses you define yourself.
324
325 .. code-block:: python
326
327    class MyPropGroup(bpy.types.PropertyGroup):
328        pass
329    MyPropGroup.my_float = bpy.props.FloatProperty()
330
331 ...this is equivalent to:
332
333 .. code-block:: python
334
335    class MyPropGroup(bpy.types.PropertyGroup):
336        my_float = bpy.props.FloatProperty()
337
338
339 Dynamic Defined-Classes (Advanced)
340 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
341
342 In some cases the specifier for data may not be in blender, renderman shader definitions for example and it may be useful to define types and remove them on the fly.
343
344 .. code-block:: python
345
346    for i in range(10):
347        idname = "object.operator_%d" % i
348
349        def func(self, context):
350            print("Hello World", self.bl_idname)
351            return {'FINISHED'}
352
353        opclass = type("DynOp%d" % i,
354                       (bpy.types.Operator, ),
355                       {"bl_idname": idname, "bl_label": "Test", "execute": func},
356                       )
357        bpy.utils.register_class(opclass)
358
359 .. note::
360
361    Notice ``type()`` is called to define the class. This is an alternative syntax for class creation in python, better suited to constructing classes dynamically.
362
363
364 Calling these operators:
365
366    >>> bpy.ops.object.operator_1()
367    Hello World OBJECT_OT_operator_1
368    {'FINISHED'}
369
370    >>> bpy.ops.object.operator_2()
371    Hello World OBJECT_OT_operator_2
372    {'FINISHED'}
373