bpy Gotcha's section on bones by Bassam Kurdali, with some edit.
[blender.git] / doc / python_api / rst / info_gotcha.rst
1 ########
2 Gotcha's
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 .. code-block:: python
29
30    >>> bpy.ops.action.clean(threshold=0.001)
31    Traceback (most recent call last):
32      File "<blender_console>", line 1, in <module>
33      File "scripts/modules/bpy/ops.py", line 179, in __call__
34        ret = op_call(self.idname_py(), None, kw)
35    RuntimeError: Operator bpy.ops.action.clean.poll() failed, context is incorrect
36
37 Which raises the question as to what the correct context might be?
38
39 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.
40
41 In most cases you can figure out what context an operator needs simply be seeing how its used in Blender and thinking about what it does.
42
43
44 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.
45
46 For python operators its not so hard to find the source since its included with with Blender and the source file/line is included in the operator reference docs.
47
48 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.
49
50 .. note::
51
52    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.
53
54    .. code-block:: python
55
56       >>> bpy.ops.gpencil.draw()
57       RuntimeError: Operator bpy.ops.gpencil.draw.poll() Failed to find Grease Pencil data to draw into
58
59 ================================
60 The operator still doesn't work!
61 ================================
62
63 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.
64
65 Examples of this are:
66
67 * :mod:`bpy.ops.texture.slot_move`
68 * :mod:`bpy.ops.constraint.limitdistance_reset`
69 * :mod:`bpy.ops.object.modifier_copy`
70 * :mod:`bpy.ops.buttons.file_browse`
71
72 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.
73
74
75 **********
76 Stale Data
77 **********
78
79 ===============================
80 No updates after setting values
81 ===============================
82
83 Sometimes you want to modify values from python and immediately access the updated values, eg:
84
85 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.
86
87 Consider the calculations that might go into working out the objects final transformation, this includes:
88
89 * animation function curves.
90 * drivers and their pythons expressions.
91 * constraints
92 * parent objects and all of their f-curves, constraints etc.
93
94 To avoid expensive recalculations every time a property is modified, Blender defers making the actual calculations until they are needed.
95
96 However, while the script runs you may want to access the updated values.
97
98 This can be done by calling :class:`bpy.types.Scene.update` after modifying values which recalculates all data that is tagged to be updated.
99
100 ===============================
101 Can I redraw during the script?
102 ===============================
103
104 The official answer to this is no, or... *"You don't want to do that"*.
105
106 To give some background on the topic...
107
108 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.
109 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.
110
111 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.
112
113 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.
114
115 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.
116
117 Transform, Painting, Fly-Mode and File-Select are example of a modal operators.
118
119 Writing modal operators takes more effort then a simple ``for`` loop that happens to redraw but is more flexible and integrates better with Blenders design.
120
121
122 **Ok, Ok! I still want to draw from python**
123
124 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.
125
126 .. code-block:: python
127
128    bpy.ops.wm.redraw_timer(type='DRAW_WIN_SWAP', iterations=1)
129
130
131 ******************************
132 Matrix multiplication is wrong
133 ******************************
134
135 Every so often users complain that Blenders matrix math is wrong, the confusion comes from mathutils matrices being column-major to match OpenGL and the rest of Blenders matrix operations and stored matrix data.
136
137 This is different to **numpy** which is row-major which matches what you would expect when using conventional matrix math notation.
138
139
140 ***********************************
141 I can't edit the mesh in edit-mode!
142 ***********************************
143
144 Blenders 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.
145
146 The reason we have not made much attempt to fix this yet is because we
147 will likely move to BMesh mesh API eventually, so any work on the API now will be wasted effort.
148
149 With the BMesh API we may expose mesh data to python so we can
150 write useful tools in python which are also fast to execute while in edit-mode.
151
152 For the time being this limitation just has to be worked around but we're aware its frustrating needs to be addressed.
153
154
155 ***********************************
156 EditBones, PoseBones, Bone... Bones
157 ***********************************
158
159 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.
160
161 .. note::
162
163         In the following examples ``bpy.context.object`` is assumed to be an armature object.
164
165
166 ==========
167 Edit Bones
168 ==========
169
170 ``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.
171
172 Example using :class:`bpy.types.EditBone` in armature editmode:
173
174 .. code-block:: python
175
176         # This is only possible in edit mode.
177         bpy.context.object.data.edit_bones["Bone"].head = Vector((1.0, 2.0, 3.0)) 
178
179         # This will be empty outside of editmode.
180         mybones = bpy.context.selected_editable_bones
181
182         # Returns an editbone only in edit mode.
183         bpy.context.active_bone
184
185
186 ===================
187 Bones (Object Mode)
188 ===================
189
190 ``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.
191
192 Example using :class:`bpy.types.Bone` in object or pose mode:
193
194 .. code-block:: python
195
196         # returns a bone (not an editbone) outside of edit mode
197         bpy.context.active_bone
198
199         # This works, as with blender the setting can be edited in any mode
200         bpy.context.object.data.bones["Bone"].use_deform = True
201
202         # Accessible but read-only
203         tail = myobj.data.bones["Bone"].tail
204
205
206 ==========
207 Pose Bones
208 ==========
209
210 ``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.
211
212 Examples using :class:`bpy.types.PoseBone` in object or pose mode:
213
214 .. code-block:: python
215
216         # Gets the name of the first constraint (if it exists)
217         bpy.context.object.pose.bones["Bone"].constraints[0].name 
218
219         # Gets the last selected pose bone (pose mode only)
220         bpy.context.active_pose_bone
221
222
223 .. note::
224
225         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.
226
227 .. note::
228
229         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`
230
231
232 =======================
233 Armature Mode Switching
234 =======================
235
236 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.
237
238 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.
239
240
241 ****************
242 Unicode Problems
243 ****************
244
245 Python supports many different encpdings so there is nothing stopping you from writing a script in latin1 or iso-8859-15.
246
247 See `pep-0263 <http://www.python.org/dev/peps/pep-0263/>`_
248
249 However this complicates things for the python api because blend files themselves dont have an encoding.
250
251 To simplify the problem for python integration and script authors we have decieded all strings in blend files **must** be UTF-8 or ASCII compatible.
252
253 This means assigning strings with different encodings to an object names for instance will raise an error.
254
255 Paths are an exception to this rule since we cannot ignore the existane of non-utf-8 paths on peoples filesystems.
256
257 This means seemingly harmless expressions can raise errors, eg.
258
259 .. code-block:: python
260
261    >>> print(bpy.data.filepath)
262    UnicodeEncodeError: 'ascii' codec can't encode characters in position 10-21: ordinal not in range(128)
263
264    >>> bpy.context.object.name = bpy.data.filepath
265    Traceback (most recent call last):
266      File "<blender_console>", line 1, in <module>
267    TypeError: bpy_struct: item.attr= val: Object.name expected a string type, not str
268
269
270 Here are 2 ways around filesystem encoding issues.
271
272 .. code-block:: python
273
274    >>> print(repr(bpy.data.filepath))
275
276    >>> import os
277    >>> filepath_bytes = os.fsencode(bpy.data.filepath)
278    >>> filepath_utf8 = filepath_bytes.decode('utf-8', "replace")
279    >>> bpy.context.object.name = filepath_utf8
280
281
282 Unicode encoding/decoding is a big topic with comprehensive python documentation, to avoid getting stuck too deep in encoding problems - here are some suggestions:
283
284 * Always use utf-8 encoiding or convert to utf-8 where the input is unknown.
285
286 * Avoid manipulating filepaths as strings directly, use ``os.path`` functions instead.
287
288 * Use ``os.fsencode()`` / ``os.fsdecode()`` rather then the built in string decoding functions when operating on paths.
289
290 * To print paths or to include them in the user interface use ``repr(path)`` first or ``"%r" % path`` with string formatting.
291
292 * **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 deciede how to treat any strings you want to use with Blender, some importers do this.
293
294
295 ***************************************
296 Strange errors using 'threading' module
297 ***************************************
298
299 Python threading with Blender only works properly when the threads finish up before the script does. By using ``threading.join()`` for example.
300
301 Heres an example of threading supported by Blender:
302
303 .. code-block:: python
304
305    import threading
306    import time
307
308    def prod():
309        print(threading.current_thread().name, "Starting")
310
311        # do something vaguely useful
312        import bpy
313        from mathutils import Vector
314        from random import random
315
316        prod_vec = Vector((random() - 0.5, random() - 0.5, random() - 0.5))
317        print("Prodding", prod_vec)
318        bpy.data.objects["Cube"].location += prod_vec
319        time.sleep(random() + 1.0)
320        # finish
321
322        print(threading.current_thread().name, "Exiting")
323
324    threads = [threading.Thread(name="Prod %d" % i, target=prod) for i in range(10)]
325
326
327    print("Starting threads...")
328
329    for t in threads:
330        t.start()
331
332    print("Waiting for threads to finish...")
333
334    for t in threads:
335        t.join()
336
337
338 This an example of a timer which runs many times a second and moves the default cube continuously while Blender runs (Unsupported).
339
340 .. code-block:: python
341
342    def func():
343        print("Running...")
344        import bpy
345        bpy.data.objects['Cube'].location.x += 0.05
346
347    def my_timer():
348        from threading import Timer
349        t = Timer(0.1, my_timer)
350        t.start()
351        func()
352
353    my_timer()
354
355 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 Blenders own drawing code.
356
357 So far no work has gone into making Blenders python integration thread safe, so until its properly supported, best not make use of this.
358
359 .. note::
360
361    Pythons threads only allow co-currency and wont speed up you're scripts on multi-processor systems, the ``subprocess`` and ``multiprocess`` modules can be used with blender and make use of multiple CPU's too.
362
363
364 *******************************
365 Help! My script crashes Blender
366 *******************************
367
368 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.
369
370 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.
371
372 Here are some general hints to avoid running into these problems.
373
374 * Be aware of memory limits, especially when working with large lists since Blender can crash simply by running out of memory.
375
376 * 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.
377
378 * 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.
379
380 * Crashes may not happen every time, they may happen more on some configurations/operating-systems.
381
382
383 =========
384 Undo/Redo
385 =========
386
387 Undo invalidates all :class:`bpy.types.ID` instances (Object, Scene, Mesh etc).
388
389 This example shows how you can tell undo changes the memory locations.
390
391 .. code-block:: python
392
393    >>> hash(bpy.context.object)
394    -9223372036849950810
395    >>> hash(bpy.context.object)
396    -9223372036849950810
397
398    # ... move the active object, then undo
399
400    >>> hash(bpy.context.object)
401    -9223372036849951740
402
403 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.
404
405
406 ===================
407 Array Re-Allocation
408 ===================
409
410 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.
411
412 .. code-block:: python
413
414    bpy.ops.curve.primitive_bezier_curve_add()
415    point = bpy.context.object.data.splines[0].bezier_points[0]
416    bpy.context.object.data.splines[0].bezier_points.add()
417
418    # this will crash!
419    point.co = 1.0, 2.0, 3.0
420
421 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.
422
423 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.
424
425
426 =============
427 Removing Data
428 =============
429
430 **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.
431
432 This is a problem in the API at the moment that we should eventually solve.