be11e88b2faca76ffc8d2e2d97c444d53485ea23
[blender.git] / doc / python_api / rst / info_gotcha.rst
1 *******
2 Gotchas
3 *******
4
5 This document attempts to help you work with the Blender API in areas that can be troublesome and avoid practices that are known to give instability.
6
7
8 Using Operators
9 ===============
10
11 Blender's operators are tools for users to access, that python can access them too is very useful nevertheless operators have limitations that can make them cumbersome to script.
12
13 Main limits are...
14
15 * Can't pass data such as objects, meshes or materials to operate on (operators use the context instead)
16
17 * The return value from calling an operator gives the success (if it finished or was canceled),
18   in some cases it would be more logical from an API perspective to return the result of the operation.
19
20 * Operators poll function can fail where an API function would raise an exception giving details on exactly why.
21
22
23 Why does an operator's poll fail?
24 ---------------------------------
25
26 When calling an operator gives an error like this:
27
28    >>> bpy.ops.action.clean(threshold=0.001)
29    RuntimeError: Operator bpy.ops.action.clean.poll() failed, context is incorrect
30
31 Which raises the question as to what the correct context might be?
32
33 Typically operators check for the active area type, a selection or active object they can operate on, but some operators are more picky about when they run.
34
35 In most cases you can figure out what context an operator needs simply be seeing how it's used in Blender and thinking about what it does.
36
37
38 Unfortunately if you're still stuck - the only way to **really** know whats going on is to read the source code for the poll function and see what its checking.
39
40 For python operators it's not so hard to find the source since it's included with Blender and the source file/line is included in the operator reference docs.
41
42 Downloading and searching the C code isn't so simple, especially if you're not familiar with the C language but by searching the operator name or description you should be able to find the poll function with no knowledge of C.
43
44 .. note::
45
46    Blender does have the functionality for poll functions to describe why they fail, but its currently not used much, if you're interested to help improve our API feel free to add calls to ``CTX_wm_operator_poll_msg_set`` where its not obvious why poll fails.
47
48       >>> bpy.ops.gpencil.draw()
49       RuntimeError: Operator bpy.ops.gpencil.draw.poll() Failed to find Grease Pencil data to draw into
50
51
52 The operator still doesn't work!
53 --------------------------------
54
55 Certain operators in Blender are only intended for use in a specific context, some operators for example are only called from the properties window where they check the current material, modifier or constraint.
56
57 Examples of this are:
58
59 * :mod:`bpy.ops.texture.slot_move`
60 * :mod:`bpy.ops.constraint.limitdistance_reset`
61 * :mod:`bpy.ops.object.modifier_copy`
62 * :mod:`bpy.ops.buttons.file_browse`
63
64 Another possibility is that you are the first person to attempt to use this operator in a script and some modifications need to be made to the operator to run in a different context, if the operator should logically be able to run but fails when accessed from a script it should be reported to the bug tracker.
65
66
67 Stale Data
68 ==========
69
70 No updates after setting values
71 -------------------------------
72
73 Sometimes you want to modify values from python and immediately access the updated values, eg:
74
75 Once changing the objects :class:`bpy.types.Object.location` you may want to access its transformation right after from :class:`bpy.types.Object.matrix_world`, but this doesn't work as you might expect.
76
77 Consider the calculations that might go into working out the object's final transformation, this includes:
78
79 * animation function curves.
80 * drivers and their pythons expressions.
81 * constraints
82 * parent objects and all of their f-curves, constraints etc.
83
84 To avoid expensive recalculations every time a property is modified, Blender defers making the actual calculations until they are needed.
85
86 However, while the script runs you may want to access the updated values.
87
88 This can be done by calling :class:`bpy.types.Scene.update` after modifying values which recalculates all data that is tagged to be updated.
89
90
91 Can I redraw during the script?
92 -------------------------------
93
94 The official answer to this is no, or... *"You don't want to do that"*.
95
96 To give some background on the topic...
97
98 While a script executes Blender waits for it to finish and is effectively locked until its done, while in this state Blender won't redraw or respond to user input.
99 Normally this is not such a problem because scripts distributed with Blender tend not to run for an extended period of time, nevertheless scripts *can* take ages to execute and its nice to see whats going on in the view port.
100
101 Tools that lock Blender in a loop and redraw are highly discouraged since they conflict with Blenders ability to run multiple operators at once and update different parts of the interface as the tool runs.
102
103 So the solution here is to write a **modal** operator, that is - an operator which defines a modal() function, See the modal operator template in the text  editor.
104
105 Modal operators execute on user input or setup their own timers to run frequently, they can handle the events or pass through to be handled by the keymap or other modal operators.
106
107 Transform, Painting, Fly-Mode and File-Select are example of a modal operators.
108
109 Writing modal operators takes more effort than a simple ``for`` loop that happens to redraw but is more flexible and integrates better with Blenders design.
110
111
112 **Ok, Ok! I still want to draw from python**
113
114 If you insist - yes its possible, but scripts that use this hack wont be considered for inclusion in Blender and any issues with using it wont be considered bugs, this is also not guaranteed to work in future releases.
115
116 .. code-block:: python
117
118    bpy.ops.wm.redraw_timer(type='DRAW_WIN_SWAP', iterations=1)
119
120
121 I can't edit the mesh in edit-mode!
122 ===================================
123
124 Blender's EditMesh is an internal data structure (not saved and not exposed to python), this gives the main annoyance that you need to exit edit-mode to edit the mesh from python.
125
126 The reason we have not made much attempt to fix this yet is because we
127 will likely move to BMesh mesh API eventually, so any work on the API now will be wasted effort.
128
129 With the BMesh API we may expose mesh data to python so we can
130 write useful tools in python which are also fast to execute while in edit-mode.
131
132 For the time being this limitation just has to be worked around but we're aware its frustrating needs to be addressed.
133
134
135 EditBones, PoseBones, Bone... Bones
136 ===================================
137
138 Armature Bones in Blender have three distinct data structures that contain them. If you are accessing the bones through one of them, you may not have access to the properties you really need.
139
140 .. note::
141
142    In the following examples ``bpy.context.object`` is assumed to be an armature object.
143
144
145 Edit Bones
146 ----------
147
148 ``bpy.context.object.data.edit_bones`` contains a editbones; to access them you must set the armature mode to edit mode first (editbones do not exist in object or pose mode). Use these to create new bones, set their head/tail or roll, change their parenting relationships to other bones, etc.
149
150 Example using :class:`bpy.types.EditBone` in armature editmode:
151
152 This is only possible in edit mode.
153
154    >>> bpy.context.object.data.edit_bones["Bone"].head = Vector((1.0, 2.0, 3.0)) 
155
156 This will be empty outside of editmode.
157
158    >>> mybones = bpy.context.selected_editable_bones
159
160 Returns an editbone only in edit mode.
161
162    >>> bpy.context.active_bone
163
164
165 Bones (Object Mode)
166 -------------------
167
168 ``bpy.context.object.data.bones`` contains bones. These *live* in object mode, and have various properties you can change, note that the head and tail properties are read-only.
169
170 Example using :class:`bpy.types.Bone` in object or pose mode:
171
172 Returns a bone (not an editbone) outside of edit mode
173
174    >>> bpy.context.active_bone
175
176 This works, as with blender the setting can be edited in any mode
177
178    >>> bpy.context.object.data.bones["Bone"].use_deform = True
179
180 Accessible but read-only
181
182    >>> tail = myobj.data.bones["Bone"].tail
183
184
185 Pose Bones
186 ----------
187
188 ``bpy.context.object.pose.bones`` contains pose bones. This is where animation data resides, i.e. animatable transformations are applied to pose bones, as are constraints and ik-settings.
189
190 Examples using :class:`bpy.types.PoseBone` in object or pose mode:
191
192 .. code-block:: python
193
194    # Gets the name of the first constraint (if it exists)
195    bpy.context.object.pose.bones["Bone"].constraints[0].name 
196
197    # Gets the last selected pose bone (pose mode only)
198    bpy.context.active_pose_bone
199
200
201 .. note::
202
203    Notice the pose is accessed from the object rather than the object data, this is why blender can have 2 or more objects sharing the same armature in different poses.
204
205 .. note::
206
207    Strictly speaking PoseBone's are not bones, they are just the state of the armature, stored in the :class:`bpy.types.Object` rather than the :class:`bpy.types.Armature`, the real bones are however accessible from the pose bones - :class:`bpy.types.PoseBone.bone`
208
209
210 Armature Mode Switching
211 -----------------------
212
213 While writing scripts that deal with armatures you may find you have to switch between modes, when doing so take care when switching out of editmode not to keep references to the edit-bones or their head/tail vectors. Further access to these will crash blender so its important the script clearly separates sections of the code which operate in different modes.
214
215 This is mainly an issue with editmode since pose data can be manipulated without having to be in pose mode, however for operator access you may still need to enter pose mode.
216
217
218 Data Names
219 ==========
220
221
222 Naming Limitations
223 ------------------
224
225 A common mistake is to assume newly created data is given the requested name.
226
227 This can cause bugs when you add some data (normally imported) and then reference it later by name.
228
229 .. code-block:: python
230
231    bpy.data.meshes.new(name=meshid)
232    
233    # normally some code, function calls...
234    bpy.data.meshes[meshid]
235
236
237 Or with name assignment...
238
239 .. code-block:: python
240
241    obj.name = objname
242    
243    # normally some code, function calls...
244    obj = bpy.data.meshes[objname]
245
246
247 Data names may not match the assigned values if they exceed the maximum length, are already used or an empty string.
248
249
250 Its better practice not to reference objects by names at all, once created you can store the data in a list, dictionary, on a class etc, there is rarely a reason to have to keep searching for the same data by name.
251
252
253 If you do need to use name references, its best to use a dictionary to maintain a mapping between the names of the imported assets and the newly created data, this way you don't run this risk of referencing existing data from the blend file, or worse modifying it.
254
255 .. code-block:: python
256
257    # typically declared in the main body of the function.
258    mesh_name_mapping = {}
259    
260    mesh = bpy.data.meshes.new(name=meshid)
261    mesh_name_mapping[meshid] = mesh
262    
263    # normally some code, or function calls...
264    
265    # use own dictionary rather then bpy.data
266    mesh = mesh_name_mapping[meshid]
267
268
269 Library Collisions
270 ------------------
271
272 Blender keeps data names unique - :class:`bpy.types.ID.name` so you can't name two objects, meshes, scenes etc the same thing by accident.
273
274 However when linking in library data from another blend file naming collisions can occur, so its best to avoid referencing data by name at all.
275
276 This can be tricky at times and not even blender handles this correctly in some case (when selecting the modifier object for eg you can't select between multiple objects with the same name), but its still good to try avoid problems in this area.
277
278
279 If you need to select between local and library data, there is a feature in ``bpy.data`` members to allow for this.
280
281 .. code-block:: python
282
283    # typical name lookup, could be local or library.
284    obj = bpy.data.objects["my_obj"]
285
286    # library object name look up using a pair
287    # where the second argument is the library path matching bpy.types.Library.filepath
288    obj = bpy.data.objects["my_obj", "//my_lib.blend"]
289
290    # local object name look up using a pair
291    # where the second argument excludes library data from being returned.
292    obj = bpy.data.objects["my_obj", None]
293
294    # both the examples above also works for 'get'
295    obj = bpy.data.objects.get(("my_obj", None))
296
297
298 Relative File Paths
299 ===================
300
301 Blenders relative file paths are not compatible with standard python modules such as ``sys`` and ``os``.
302
303 Built in python functions don't understand blenders ``//`` prefix which denotes the blend file path.
304
305 A common case where you would run into this problem is when exporting a material with associated image paths.
306
307 >>> bpy.path.abspath(image.filepath)
308
309
310 When using blender data from linked libraries there is an unfortunate complication since the path will be relative to the library rather then the open blend file. When the data block may be from an external blend file pass the library argument from the :class:`bpy.types.ID`.
311
312 >>> bpy.path.abspath(image.filepath, library=image.library)
313
314
315 These returns the absolute path which can be used with native python modules.
316
317
318 Unicode Problems
319 ================
320
321 Python supports many different encodings so there is nothing stopping you from writing a script in latin1 or iso-8859-15.
322
323 See `pep-0263 <http://www.python.org/dev/peps/pep-0263/>`_
324
325 However this complicates things for the python api because blend files themselves don't have an encoding.
326
327 To simplify the problem for python integration and script authors we have decided all strings in blend files **must** be UTF-8 or ASCII compatible.
328
329 This means assigning strings with different encodings to an object names for instance will raise an error.
330
331 Paths are an exception to this rule since we cannot ignore the existane of non-utf-8 paths on peoples filesystems.
332
333 This means seemingly harmless expressions can raise errors, eg.
334
335    >>> print(bpy.data.filepath)
336    UnicodeEncodeError: 'ascii' codec can't encode characters in position 10-21: ordinal not in range(128)
337
338    >>> bpy.context.object.name = bpy.data.filepath
339    Traceback (most recent call last):
340      File "<blender_console>", line 1, in <module>
341    TypeError: bpy_struct: item.attr= val: Object.name expected a string type, not str
342
343
344 Here are 2 ways around filesystem encoding issues:
345
346    >>> print(repr(bpy.data.filepath))
347
348    >>> import os
349    >>> filepath_bytes = os.fsencode(bpy.data.filepath)
350    >>> filepath_utf8 = filepath_bytes.decode('utf-8', "replace")
351    >>> bpy.context.object.name = filepath_utf8
352
353
354 Unicode encoding/decoding is a big topic with comprehensive python documentation, to avoid getting stuck too deep in encoding problems - here are some suggestions:
355
356 * Always use utf-8 encoiding or convert to utf-8 where the input is unknown.
357
358 * Avoid manipulating filepaths as strings directly, use ``os.path`` functions instead.
359
360 * Use ``os.fsencode()`` / ``os.fsdecode()`` rather then the built in string decoding functions when operating on paths.
361
362 * To print paths or to include them in the user interface use ``repr(path)`` first or ``"%r" % path`` with string formatting.
363
364 * **Possibly** - use bytes instead of python strings, when reading some input its less trouble to read it as binary data though you will still need to decide how to treat any strings you want to use with Blender, some importers do this.
365
366
367 Strange errors using 'threading' module
368 =======================================
369
370 Python threading with Blender only works properly when the threads finish up before the script does. By using ``threading.join()`` for example.
371
372 Heres an example of threading supported by Blender:
373
374 .. code-block:: python
375
376    import threading
377    import time
378
379    def prod():
380        print(threading.current_thread().name, "Starting")
381
382        # do something vaguely useful
383        import bpy
384        from mathutils import Vector
385        from random import random
386
387        prod_vec = Vector((random() - 0.5, random() - 0.5, random() - 0.5))
388        print("Prodding", prod_vec)
389        bpy.data.objects["Cube"].location += prod_vec
390        time.sleep(random() + 1.0)
391        # finish
392
393        print(threading.current_thread().name, "Exiting")
394
395    threads = [threading.Thread(name="Prod %d" % i, target=prod) for i in range(10)]
396
397
398    print("Starting threads...")
399
400    for t in threads:
401        t.start()
402
403    print("Waiting for threads to finish...")
404
405    for t in threads:
406        t.join()
407
408
409 This an example of a timer which runs many times a second and moves the default cube continuously while Blender runs (Unsupported).
410
411 .. code-block:: python
412
413    def func():
414        print("Running...")
415        import bpy
416        bpy.data.objects['Cube'].location.x += 0.05
417
418    def my_timer():
419        from threading import Timer
420        t = Timer(0.1, my_timer)
421        t.start()
422        func()
423
424    my_timer()
425
426 Use cases like the one above which leave the thread running once the script finishes may seem to work for a while but end up causing random crashes or errors in Blender's own drawing code.
427
428 So far, no work has gone into making Blender's python integration thread safe, so until its properly supported, best not make use of this.
429
430 .. note::
431
432    Pythons threads only allow co-currency and won't speed up your scripts on multi-processor systems, the ``subprocess`` and ``multiprocess`` modules can be used with blender and make use of multiple CPU's too.
433
434
435 Help! My script crashes Blender
436 ===============================
437
438 Ideally it would be impossible to crash Blender from python however there are some problems with the API where it can be made to crash.
439
440 Strictly speaking this is a bug in the API but fixing it would mean adding memory verification on every access since most crashes are caused by the python objects referencing Blenders memory directly, whenever the memory is freed, further python access to it can crash the script. But fixing this would make the scripts run very slow, or writing a very different kind of API which doesn't reference the memory directly.
441
442 Here are some general hints to avoid running into these problems.
443
444 * Be aware of memory limits, especially when working with large lists since Blender can crash simply by running out of memory.
445
446 * Many hard to fix crashes end up being because of referencing freed data, when removing data be sure not to hold any references to it.
447
448 * Modules or classes that remain active while Blender is used, should not hold references to data the user may remove, instead, fetch data from the context each time the script is activated.
449
450 * Crashes may not happen every time, they may happen more on some configurations/operating-systems.
451
452
453 Undo/Redo
454 ---------
455
456 Undo invalidates all :class:`bpy.types.ID` instances (Object, Scene, Mesh etc).
457
458 This example shows how you can tell undo changes the memory locations.
459
460    >>> hash(bpy.context.object)
461    -9223372036849950810
462    >>> hash(bpy.context.object)
463    -9223372036849950810
464
465    # ... move the active object, then undo
466
467    >>> hash(bpy.context.object)
468    -9223372036849951740
469
470 As suggested above, simply not holding references to data when Blender is used interactively by the user is the only way to ensure the script doesn't become unstable.
471
472
473 Edit Mode / Memory Access
474 -------------------------
475
476 Switching edit-mode ``bpy.ops.object.mode_set(mode='EDIT')`` / ``bpy.ops.object.mode_set(mode='OBJECT')`` will re-allocate objects data, any references to a meshes vertices/faces/uvs, armatures bones, curves points etc cannot be accessed after switching edit-mode.
477
478 Only the reference to the data its self can be re-accessed, the following example will crash.
479
480 .. code-block:: python
481
482    mesh = bpy.context.active_object.data
483    faces = mesh.faces
484    bpy.ops.object.mode_set(mode='EDIT')
485    bpy.ops.object.mode_set(mode='OBJECT')
486
487    # this will crash
488    print(faces)
489
490
491 So after switching edit-mode you need to re-access any object data variables, the following example shows how to avoid the crash above.
492
493 .. code-block:: python
494
495    mesh = bpy.context.active_object.data
496    faces = mesh.faces
497    bpy.ops.object.mode_set(mode='EDIT')
498    bpy.ops.object.mode_set(mode='OBJECT')
499
500    # faces have been re-allocated
501    faces = mesh.faces
502    print(faces)
503
504
505 These kinds of problems can happen for any functions which re-allocate the object data but are most common when switching edit-mode.
506
507
508 Array Re-Allocation
509 -------------------
510
511 When adding new points to a curve or vertices's/edges/faces to a mesh, internally the array which stores this data is re-allocated.
512
513 .. code-block:: python
514
515    bpy.ops.curve.primitive_bezier_curve_add()
516    point = bpy.context.object.data.splines[0].bezier_points[0]
517    bpy.context.object.data.splines[0].bezier_points.add()
518
519    # this will crash!
520    point.co = 1.0, 2.0, 3.0
521
522 This can be avoided by re-assigning the point variables after adding the new one or by storing indices's to the points rather then the points themselves.
523
524 The best way is to sidestep the problem altogether add all the points to the curve at once. This means you don't have to worry about array re-allocation and its faster too since reallocating the entire array for every point added is inefficient.
525
526
527 Removing Data
528 -------------
529
530 **Any** data that you remove shouldn't be modified or accessed afterwards, this includes f-curves, drivers, render layers, timeline markers, modifiers, constraints along with objects, scenes, groups, bones.. etc.
531
532 This is a problem in the API at the moment that we should eventually solve.
533
534
535 sys.exit
536 ========
537
538 Some python modules will call sys.exit() themselves when an error occurs, while not common behavior this is something to watch out for because it may seem as if blender is crashing since sys.exit() will quit blender immediately.
539
540 For example, the ``optparse`` module will print an error and exit if the arguments are invalid.
541
542 An ugly way of troubleshooting this is to set ``sys.exit = None`` and see what line of python code is quitting, you could of course replace ``sys.exit``/ with your own function but manipulating python in this way is bad practice.
543