Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorJoerg Mueller <nexyon@gmail.com>2011-08-30 12:22:03 +0400
committerJoerg Mueller <nexyon@gmail.com>2011-08-30 12:22:03 +0400
commit43ab8e86247b7889d16d915b4f370ceb618aaad4 (patch)
tree64b1fec1adcc399eb1de5cd86ebafd753a921d8d /doc
parent5b5e600db6f529ad7e1af9d4bb3a193be2265342 (diff)
parentd049a722fea3d150fbfad06ffdbbb5c150717134 (diff)
* Merge trunk up to r39790.soc-2011-pepper
* Subversion bump (also for init_userdef_do_versions). * Minor fix for compilation without ffmpeg.
Diffstat (limited to 'doc')
-rw-r--r--doc/python_api/examples/bpy.types.BlendDataLibraries.load.py5
-rw-r--r--doc/python_api/examples/bpy.types.ID.user_clear.1.py19
-rw-r--r--doc/python_api/rst/info_gotcha.rst405
-rw-r--r--doc/python_api/rst/info_overview.rst373
-rw-r--r--doc/python_api/rst/info_quickstart.rst468
-rw-r--r--doc/python_api/sphinx_doc_gen.py39
-rwxr-xr-xdoc/python_api/sphinx_doc_gen.sh66
7 files changed, 1344 insertions, 31 deletions
diff --git a/doc/python_api/examples/bpy.types.BlendDataLibraries.load.py b/doc/python_api/examples/bpy.types.BlendDataLibraries.load.py
index 42e2a71cc70..5e7022c88b4 100644
--- a/doc/python_api/examples/bpy.types.BlendDataLibraries.load.py
+++ b/doc/python_api/examples/bpy.types.BlendDataLibraries.load.py
@@ -23,11 +23,6 @@ with bpy.data.libraries.load(filepath) as (data_from, data_to):
setattr(data_to, attr, getattr(data_from, attr))
-# the 'data_to' variables lists are
-with bpy.data.libraries.load(filepath) as (data_from, data_to):
- data_to.scenes = ["Scene"]
-
-
# the loaded objects can be accessed from 'data_to' outside of the context
# since loading the data replaces the strings for the datablocks or None
# if the datablock could not be loaded.
diff --git a/doc/python_api/examples/bpy.types.ID.user_clear.1.py b/doc/python_api/examples/bpy.types.ID.user_clear.1.py
new file mode 100644
index 00000000000..68c35caa7d4
--- /dev/null
+++ b/doc/python_api/examples/bpy.types.ID.user_clear.1.py
@@ -0,0 +1,19 @@
+"""
+User Clear
+++++++++++
+This function is for advanced use only, misuse can crash blender since the user
+count is used to prevent data being removed when it is used.
+"""
+
+# This example shows what _not_ to do, and will crash blender.
+import bpy
+
+# object which is in the scene.
+obj = bpy.data.objects["Cube"]
+
+# without this, removal would raise an error.
+obj.user_clear()
+
+# runs without an exception
+# but will crash on redraw.
+bpy.data.objects.remove(obj)
diff --git a/doc/python_api/rst/info_gotcha.rst b/doc/python_api/rst/info_gotcha.rst
new file mode 100644
index 00000000000..c97fc3ab427
--- /dev/null
+++ b/doc/python_api/rst/info_gotcha.rst
@@ -0,0 +1,405 @@
+********
+Gotcha's
+********
+
+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.
+
+
+Using Operators
+===============
+
+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.
+
+Main limits are...
+
+* Can't pass data such as objects, meshes or materials to operate on (operators use the context instead)
+
+* The return value from calling an operator gives the success (if it finished or was canceled),
+ in some cases it would be more logical from an API perspective to return the result of the operation.
+
+* Operators poll function can fail where an API function would raise an exception giving details on exactly why.
+
+
+Why does an operator's poll fail?
+---------------------------------
+
+When calling an operator gives an error like this:
+
+ >>> bpy.ops.action.clean(threshold=0.001)
+ RuntimeError: Operator bpy.ops.action.clean.poll() failed, context is incorrect
+
+Which raises the question as to what the correct context might be?
+
+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.
+
+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.
+
+
+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.
+
+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.
+
+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.
+
+.. note::
+
+ 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.
+
+ >>> bpy.ops.gpencil.draw()
+ RuntimeError: Operator bpy.ops.gpencil.draw.poll() Failed to find Grease Pencil data to draw into
+
+
+The operator still doesn't work!
+--------------------------------
+
+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.
+
+Examples of this are:
+
+* :mod:`bpy.ops.texture.slot_move`
+* :mod:`bpy.ops.constraint.limitdistance_reset`
+* :mod:`bpy.ops.object.modifier_copy`
+* :mod:`bpy.ops.buttons.file_browse`
+
+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.
+
+
+Stale Data
+==========
+
+No updates after setting values
+-------------------------------
+
+Sometimes you want to modify values from python and immediately access the updated values, eg:
+
+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.
+
+Consider the calculations that might go into working out the objects final transformation, this includes:
+
+* animation function curves.
+* drivers and their pythons expressions.
+* constraints
+* parent objects and all of their f-curves, constraints etc.
+
+To avoid expensive recalculations every time a property is modified, Blender defers making the actual calculations until they are needed.
+
+However, while the script runs you may want to access the updated values.
+
+This can be done by calling :class:`bpy.types.Scene.update` after modifying values which recalculates all data that is tagged to be updated.
+
+
+Can I redraw during the script?
+-------------------------------
+
+The official answer to this is no, or... *"You don't want to do that"*.
+
+To give some background on the topic...
+
+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.
+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.
+
+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.
+
+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.
+
+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.
+
+Transform, Painting, Fly-Mode and File-Select are example of a modal operators.
+
+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.
+
+
+**Ok, Ok! I still want to draw from python**
+
+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.
+
+.. code-block:: python
+
+ bpy.ops.wm.redraw_timer(type='DRAW_WIN_SWAP', iterations=1)
+
+
+Matrix multiplication is wrong
+==============================
+
+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.
+
+This is different to **numpy** which is row-major which matches what you would expect when using conventional matrix math notation.
+
+
+I can't edit the mesh in edit-mode!
+===================================
+
+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.
+
+The reason we have not made much attempt to fix this yet is because we
+will likely move to BMesh mesh API eventually, so any work on the API now will be wasted effort.
+
+With the BMesh API we may expose mesh data to python so we can
+write useful tools in python which are also fast to execute while in edit-mode.
+
+For the time being this limitation just has to be worked around but we're aware its frustrating needs to be addressed.
+
+
+EditBones, PoseBones, Bone... Bones
+===================================
+
+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.
+
+.. note::
+
+ In the following examples ``bpy.context.object`` is assumed to be an armature object.
+
+
+Edit Bones
+----------
+
+``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.
+
+Example using :class:`bpy.types.EditBone` in armature editmode:
+
+This is only possible in edit mode.
+
+ >>> bpy.context.object.data.edit_bones["Bone"].head = Vector((1.0, 2.0, 3.0))
+
+This will be empty outside of editmode.
+
+ >>> mybones = bpy.context.selected_editable_bones
+
+Returns an editbone only in edit mode.
+
+ >>> bpy.context.active_bone
+
+
+Bones (Object Mode)
+-------------------
+
+``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.
+
+Example using :class:`bpy.types.Bone` in object or pose mode:
+
+Returns a bone (not an editbone) outside of edit mode
+
+ >>> bpy.context.active_bone
+
+This works, as with blender the setting can be edited in any mode
+
+ >>> bpy.context.object.data.bones["Bone"].use_deform = True
+
+Accessible but read-only
+
+ >>> tail = myobj.data.bones["Bone"].tail
+
+
+Pose Bones
+----------
+
+``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.
+
+Examples using :class:`bpy.types.PoseBone` in object or pose mode:
+
+.. code-block:: python
+
+ # Gets the name of the first constraint (if it exists)
+ bpy.context.object.pose.bones["Bone"].constraints[0].name
+
+ # Gets the last selected pose bone (pose mode only)
+ bpy.context.active_pose_bone
+
+
+.. note::
+
+ 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.
+
+.. note::
+
+ 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`
+
+
+Armature Mode Switching
+-----------------------
+
+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.
+
+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.
+
+
+Unicode Problems
+================
+
+Python supports many different encpdings so there is nothing stopping you from writing a script in latin1 or iso-8859-15.
+
+See `pep-0263 <http://www.python.org/dev/peps/pep-0263/>`_
+
+However this complicates things for the python api because blend files themselves dont have an encoding.
+
+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.
+
+This means assigning strings with different encodings to an object names for instance will raise an error.
+
+Paths are an exception to this rule since we cannot ignore the existane of non-utf-8 paths on peoples filesystems.
+
+This means seemingly harmless expressions can raise errors, eg.
+
+ >>> print(bpy.data.filepath)
+ UnicodeEncodeError: 'ascii' codec can't encode characters in position 10-21: ordinal not in range(128)
+
+ >>> bpy.context.object.name = bpy.data.filepath
+ Traceback (most recent call last):
+ File "<blender_console>", line 1, in <module>
+ TypeError: bpy_struct: item.attr= val: Object.name expected a string type, not str
+
+
+Here are 2 ways around filesystem encoding issues:
+
+ >>> print(repr(bpy.data.filepath))
+
+ >>> import os
+ >>> filepath_bytes = os.fsencode(bpy.data.filepath)
+ >>> filepath_utf8 = filepath_bytes.decode('utf-8', "replace")
+ >>> bpy.context.object.name = filepath_utf8
+
+
+Unicode encoding/decoding is a big topic with comprehensive python documentation, to avoid getting stuck too deep in encoding problems - here are some suggestions:
+
+* Always use utf-8 encoiding or convert to utf-8 where the input is unknown.
+
+* Avoid manipulating filepaths as strings directly, use ``os.path`` functions instead.
+
+* Use ``os.fsencode()`` / ``os.fsdecode()`` rather then the built in string decoding functions when operating on paths.
+
+* To print paths or to include them in the user interface use ``repr(path)`` first or ``"%r" % path`` with string formatting.
+
+* **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.
+
+
+Strange errors using 'threading' module
+=======================================
+
+Python threading with Blender only works properly when the threads finish up before the script does. By using ``threading.join()`` for example.
+
+Heres an example of threading supported by Blender:
+
+.. code-block:: python
+
+ import threading
+ import time
+
+ def prod():
+ print(threading.current_thread().name, "Starting")
+
+ # do something vaguely useful
+ import bpy
+ from mathutils import Vector
+ from random import random
+
+ prod_vec = Vector((random() - 0.5, random() - 0.5, random() - 0.5))
+ print("Prodding", prod_vec)
+ bpy.data.objects["Cube"].location += prod_vec
+ time.sleep(random() + 1.0)
+ # finish
+
+ print(threading.current_thread().name, "Exiting")
+
+ threads = [threading.Thread(name="Prod %d" % i, target=prod) for i in range(10)]
+
+
+ print("Starting threads...")
+
+ for t in threads:
+ t.start()
+
+ print("Waiting for threads to finish...")
+
+ for t in threads:
+ t.join()
+
+
+This an example of a timer which runs many times a second and moves the default cube continuously while Blender runs (Unsupported).
+
+.. code-block:: python
+
+ def func():
+ print("Running...")
+ import bpy
+ bpy.data.objects['Cube'].location.x += 0.05
+
+ def my_timer():
+ from threading import Timer
+ t = Timer(0.1, my_timer)
+ t.start()
+ func()
+
+ my_timer()
+
+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.
+
+So far no work has gone into making Blenders python integration thread safe, so until its properly supported, best not make use of this.
+
+.. note::
+
+ 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.
+
+
+Help! My script crashes Blender
+===============================
+
+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.
+
+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.
+
+Here are some general hints to avoid running into these problems.
+
+* Be aware of memory limits, especially when working with large lists since Blender can crash simply by running out of memory.
+
+* 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.
+
+* 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.
+
+* Crashes may not happen every time, they may happen more on some configurations/operating-systems.
+
+
+Undo/Redo
+---------
+
+Undo invalidates all :class:`bpy.types.ID` instances (Object, Scene, Mesh etc).
+
+This example shows how you can tell undo changes the memory locations.
+
+ >>> hash(bpy.context.object)
+ -9223372036849950810
+ >>> hash(bpy.context.object)
+ -9223372036849950810
+
+ # ... move the active object, then undo
+
+ >>> hash(bpy.context.object)
+ -9223372036849951740
+
+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.
+
+
+Array Re-Allocation
+-------------------
+
+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.
+
+.. code-block:: python
+
+ bpy.ops.curve.primitive_bezier_curve_add()
+ point = bpy.context.object.data.splines[0].bezier_points[0]
+ bpy.context.object.data.splines[0].bezier_points.add()
+
+ # this will crash!
+ point.co = 1.0, 2.0, 3.0
+
+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.
+
+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.
+
+
+Removing Data
+-------------
+
+**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.
+
+This is a problem in the API at the moment that we should eventually solve.
diff --git a/doc/python_api/rst/info_overview.rst b/doc/python_api/rst/info_overview.rst
new file mode 100644
index 00000000000..fe730088c44
--- /dev/null
+++ b/doc/python_api/rst/info_overview.rst
@@ -0,0 +1,373 @@
+*******************
+Python API Overview
+*******************
+
+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.
+
+
+Python in Blender
+=================
+
+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.
+
+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.
+
+Here is a simple example of moving a vertex of the object named **Cube**:
+
+.. code-block:: python
+
+ import bpy
+ bpy.data.objects["Cube"].data.vertices[0].co.x += 1.0
+
+This modifies Blender's internal data directly. When you run this in the interactive console you will see the 3D viewport update.
+
+
+The Default Environment
+=======================
+
+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.
+
+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.5/Manual/Introduction/Installing_Blender/DirectoryLayout>`_
+
+
+Script Loading
+==============
+
+This may seem obvious but it's important to note the difference between executing a script directly or importing it as a module.
+
+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.
+
+For this reason it's preferable to only use directly execute scripts that don't extend blender by registering classes.
+
+
+Here are some ways to run scripts directly in blender.
+
+* Loaded in the text editor and press **Run Script**.
+
+* Typed or pasted into the interactive console.
+
+* Execute a python file from the command line with blender, eg:
+
+ ``blender --python /home/me/my_script.py``
+
+
+To run as modules:
+
+* The obvious way, ``import some_module`` command from the text window or interactive console.
+
+* Open as a text block and tick "Register" option, this will load with the blend file.
+
+* copy into one of the directories ``scripts/startup``, where they will be automatically imported on startup.
+
+* define as an addon, enabling the addon will load it as a python module.
+
+
+Addons
+------
+
+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.
+
+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.
+
+The user preferences addon listing uses **bl_info** to display information about each addon.
+
+`See Addons <http://wiki.blender.org/index.php/Dev:2.5/Py/Scripts/Guidelines/Addons>`_ for details on the **bl_info** dictionary.
+
+
+Integration through Classes
+===========================
+
+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.
+
+The blender python api allows integration for:
+
+* :class:`bpy.types.Panel`
+
+* :class:`bpy.types.Menu`
+
+* :class:`bpy.types.Operator`
+
+* :class:`bpy.types.PropertyGroup`
+
+* :class:`bpy.types.KeyingSet`
+
+* :class:`bpy.types.RenderEngine`
+
+
+This is intentionally limited. Currently, for more advanced features such as mesh modifiers, object types, or shader nodes, C/C++ must be used.
+
+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.
+
+For example:
+
+.. code-block:: python
+
+ import bpy
+ class SimpleOperator(bpy.types.Operator):
+ bl_idname = "object.simple_operator"
+ bl_label = "Tool Name"
+
+ def execute(self, context):
+ print("Hello World")
+ return {'FINISHED'}
+
+ bpy.utils.register_class(SimpleOperator)
+
+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.
+
+Both class properties start with a **bl_** prefix. This is a convention used to distinguish blender properties from those you add yourself.
+
+Next see the execute function, which takes an instance of the operator and the current context. A common prefix is not used for functions.
+
+Lastly the register function is called, this takes the class and loads it into blender. See `Class Registration`_.
+
+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.
+
+class mix-in example:
+
+.. code-block:: python
+
+ import bpy
+ class BaseOperator:
+ def execute(self, context):
+ print("Hello World BaseClass")
+ return {'FINISHED'}
+
+ class SimpleOperator(bpy.types.Operator, BaseOperator):
+ bl_idname = "object.simple_operator"
+ bl_label = "Tool Name"
+
+ bpy.utils.register_class(SimpleOperator)
+
+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.
+
+.. note:: Modal operators are an exception, keeping their instance variable as blender runs, see modal operator template.
+
+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.
+
+To run operators you can call them through the operator api, eg:
+
+.. code-block:: python
+
+ import bpy
+ bpy.ops.object.simple_operator()
+
+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.
+
+
+Registration
+============
+
+
+Module Registration
+-------------------
+
+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.
+
+A simple blender/python module can look like this:
+
+.. code-block:: python
+
+ import bpy
+
+ class SimpleOperator(bpy.types.Operator):
+ """ See example above """
+
+ def register():
+ bpy.utils.register_class(SimpleOperator)
+
+ def unregister():
+ bpy.utils.unregister_class(SimpleOperator)
+
+ if __name__ == "__main__":
+ register()
+
+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.
+
+The register/unregister calls are used so it's possible to toggle addons and reload scripts while blender runs.
+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.
+
+This becomes problematic when a script imports classes from another module making it difficult to manage which classes are being loaded and when.
+
+The last 2 lines are only for testing:
+
+.. code-block:: python
+
+ if __name__ == "__main__":
+ register()
+
+This allows the script to be run directly in the text editor to test changes.
+This ``register()`` call won't run when the script is imported as a module since ``__main__`` is reserved for direct execution.
+
+
+Class Registration
+------------------
+
+Registering a class with blender results in the class definition being loaded into blender, where it becomes available alongside existing functionality.
+
+Once this class is loaded you can access it from :mod:`bpy.types`, using the bl_idname rather than the classes original name.
+
+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.
+
+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:
+
+Using the function arguments ``def execute(self, context, spam)``, will raise an exception:
+
+``ValueError: expected Operator, SimpleOperator class "execute" function to have 2 args, found 3``
+
+Using ``bl_idname = 1`` will raise.
+
+``TypeError: validating class error: Operator.bl_idname expected a string type, not int``
+
+
+Multiple-Classes
+^^^^^^^^^^^^^^^^
+
+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.
+
+For more convenient loading/unloading :mod:`bpy.utils.register_module` (module) and :mod:`bpy.utils.unregister_module` (module) functions exist.
+
+A script which defines many of its own operators, panels menus etc. you only need to write:
+
+.. code-block:: python
+
+ def register():
+ bpy.utils.register_module(__name__)
+
+ def unregister():
+ bpy.utils.unregister_module(__name__)
+
+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.
+
+
+Inter Classes Dependencies
+^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+Custom properties groups are themselves classes which need to be registered.
+
+Say you want to store material settings for a custom engine.
+
+.. code-block:: python
+
+ # Create new property
+ # bpy.data.materials[0].my_custom_props.my_float
+ import bpy
+
+ class MyMaterialProps(bpy.types.PropertyGroup):
+ my_float = bpy.props.FloatProperty()
+
+ def register():
+ bpy.utils.register_class(MyMaterialProps)
+ bpy.types.Material.my_custom_props = bpy.props.PointerProperty(type=MyMaterialProps)
+
+ def unregister():
+ del bpy.types.Material.my_custom_props
+ bpy.utils.unregister_class(MyMaterialProps)
+
+ if __name__ == "__main__":
+ register()
+
+.. note::
+
+ *The class must be registered before being used in a property, failing to do so will raise an error:*
+
+ ``ValueError: bpy_struct "Material" registration error: my_custom_props could not register``
+
+
+.. code-block:: python
+
+ # Create new property group with a sub property
+ # bpy.data.materials[0].my_custom_props.sub_group.my_float
+ import bpy
+
+ class MyMaterialSubProps(bpy.types.PropertyGroup):
+ my_float = bpy.props.FloatProperty()
+
+ class MyMaterialGroupProps(bpy.types.PropertyGroup):
+ sub_group = bpy.props.PointerProperty(type=MyMaterialSubProps)
+
+ def register():
+ bpy.utils.register_class(MyMaterialSubProps)
+ bpy.utils.register_class(MyMaterialGroupProps)
+ bpy.types.Material.my_custom_props = bpy.props.PointerProperty(type=MyMaterialGroupProps)
+
+ def unregister():
+ del bpy.types.Material.my_custom_props
+ bpy.utils.unregister_class(MyMaterialGroupProps)
+ bpy.utils.unregister_class(MyMaterialSubProps)
+
+ if __name__ == "__main__":
+ register()
+
+.. note::
+
+ *The lower most class needs to be registered first and that unregister() is a mirror of register()*
+
+
+Manipulating Classes
+^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+For example:
+
+.. code-block:: python
+
+ # add a new property to an existing type
+ bpy.types.Object.my_float = bpy.props.FloatProperty()
+ # remove
+ del bpy.types.Object.my_float
+
+This works just as well for PropertyGroup subclasses you define yourself.
+
+.. code-block:: python
+
+ class MyPropGroup(bpy.types.PropertyGroup):
+ pass
+ MyPropGroup.my_float = bpy.props.FloatProperty()
+
+...this is equivalent to:
+
+.. code-block:: python
+
+ class MyPropGroup(bpy.types.PropertyGroup):
+ my_float = bpy.props.FloatProperty()
+
+
+Dynamic Defined-Classes (Advanced)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+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.
+
+.. code-block:: python
+
+ for i in range(10):
+ idname = "object.operator_%d" % i
+
+ def func(self, context):
+ print("Hello World", self.bl_idname)
+ return {'FINISHED'}
+
+ opclass = type("DynOp%d" % i,
+ (bpy.types.Operator, ),
+ {"bl_idname": idname, "bl_label": "Test", "execute": func},
+ )
+ bpy.utils.register_class(opclass)
+
+.. note::
+
+ Notice ``type()`` is called to define the class. This is an alternative syntax for class creation in python, better suited to constructing classes dynamically.
+
+
+Calling these operators:
+
+ >>> bpy.ops.object.operator_1()
+ Hello World OBJECT_OT_operator_1
+ {'FINISHED'}
+
+ >>> bpy.ops.object.operator_2()
+ Hello World OBJECT_OT_operator_2
+ {'FINISHED'}
+
diff --git a/doc/python_api/rst/info_quickstart.rst b/doc/python_api/rst/info_quickstart.rst
new file mode 100644
index 00000000000..e77e9a76d7f
--- /dev/null
+++ b/doc/python_api/rst/info_quickstart.rst
@@ -0,0 +1,468 @@
+***********************
+Quickstart Introduction
+***********************
+
+Intro
+=====
+
+This API is generally stable but some areas are still being added and improved.
+
+The Blender/Python API can do the following:
+
+* Edit any data the user interface can (Scenes, Meshes, Particles etc.)
+
+* Modify user preferences, keymaps and themes
+
+* Run tools with own settings
+
+* Create user interface elements such as menus, headers and panels
+
+* Create new tools
+
+* Create interactive tools
+
+* Create new rendering engines that integrate with Blender
+
+* Define new settings in existing Blender data
+
+* Draw in the 3D view using OpenGL commands from Python
+
+
+The Blender/Python API **can't** (yet)...
+
+* Create new space types.
+
+* Assign custom properties to every type.
+
+* Define callbacks or listeners to be notified when data is changed.
+
+
+Before Starting
+===============
+
+This document isn't intended to fully cover each topic. Rather, its purpose is to familiarize you with Blender 2.5's new Python API.
+
+
+A quick list of helpful things to know before starting:
+
+* Blender uses Python 3.x; some 3rd party extensions are not available yet.
+
+* The interactive console in Blender 2.5 has been improved; testing one-liners in the console is a good way to learn.
+
+* Button tool tips show Python attributes and operator names.
+
+* Right clicking on buttons and menu items directly links to API documentation.
+
+* For more examples, the text menu has a templates section where some example operators can be found.
+
+* To examine further scripts distributed with Blender, see ``~/.blender/scripts/startup/bl_ui`` for the user interface and ``~/.blender/scripts/startup/bl_op`` for operators.
+
+
+Key Concepts
+============
+
+Data Access
+-----------
+
+Accessing datablocks
+^^^^^^^^^^^^^^^^^^^^
+
+Python accesses Blender's data in the same way as the animation system and user interface, which means any setting that is changed via a button can also be changed from Python.
+
+Accessing data from the currently loaded blend file is done with the module :mod:`bpy.data`. This gives access to library data. For example:
+
+ >>> bpy.data.objects
+ <bpy_collection[3], BlendDataObjects>
+
+ >>> bpy.data.scenes
+ <bpy_collection[1], BlendDataScenes>
+
+ >>> bpy.data.materials
+ <bpy_collection[1], BlendDataMaterials>
+
+
+About Collections
+^^^^^^^^^^^^^^^^^
+
+You'll notice that an index as well as a string can be used to access members of the collection.
+
+Unlike Python's dictionaries, both methods are acceptable; however, the index of a member may change while running Blender.
+
+ >>> list(bpy.data.objects)
+ [bpy.data.objects["Cube"], bpy.data.objects["Plane"]]
+
+ >>> bpy.data.objects['Cube']
+ bpy.data.objects["Cube"]
+
+ >>> bpy.data.objects[0]
+ bpy.data.objects["Cube"]
+
+
+Accessing attributes
+^^^^^^^^^^^^^^^^^^^^
+
+Once you have a data block such as a material, object, groups etc. its attributes can be accessed just like changing a setting in the interface; in fact, the button tooltip also displays the Python attribute which can help in finding what settings to change in a script.
+
+ >>> bpy.data.objects[0].name
+ 'Camera'
+
+ >>> bpy.data.scenes["Scene"]
+ bpy.data.scenes['Scene']
+
+ >>> bpy.data.materials.new("MyMaterial")
+ bpy.data.materials['MyMaterial']
+
+
+For testing what data to access it's useful to use the "Console", which is its own space type in Blender 2.5. This supports auto-complete, giving you a fast way to dig into different data in your file.
+
+Example of a data path that can be quickly found via the console:
+
+ >>> bpy.data.scenes[0].render.resolution_percentage
+ 100
+ >>> bpy.data.scenes[0].objects["Torus"].data.vertices[0].co.x
+ 1.0
+
+
+Custom Properties
+^^^^^^^^^^^^^^^^^
+
+Python can access properties on any datablock that has an ID (data that can be linked in and accessed from :mod:`bpy.data`. When assigning a property, you can make up your own names, these will be created when needed or overwritten if they exist.
+
+This data is saved with the blend file and copied with objects.
+
+Example:
+
+.. code-block:: python
+
+ bpy.context.object["MyOwnProperty"] = 42
+
+ if "SomeProp" in bpy.context.object:
+ print("Property found")
+
+ # Use the get function like a python dictionary
+ # which can have a fallback value.
+ value = bpy.data.scenes["Scene"].get("test_prop", "fallback value")
+
+ # dictionaries can be assigned as long as they only use basic types.
+ group = bpy.data.groups.new("MyTestGroup")
+ group["GameSettings"] = {"foo": 10, "bar": "spam", "baz": {}}
+
+ del group["GameSettings"]
+
+
+Note that these properties can only be assigned basic Python types.
+
+* int, float, string
+
+* array of ints/floats
+
+* dictionary (only string keys types on this list)
+
+These properties are valid outside of Python. They can be animated by curves or used in driver paths.
+
+
+Context
+-------
+
+While it's useful to be able to access data directly by name or as a list, it's more common to operate on the user's selection. The context is always available from '''bpy.context''' and can be used to get the active object, scene, tool settings along with many other attributes.
+
+Common-use cases:
+
+ >>> bpy.context.object
+ >>> bpy.context.selected_objects
+ >>> bpy.context.visible_bones
+
+Note that the context is read-only. These values cannot be modified directly, though they may be changed by running API functions or by using the data API.
+
+So ``bpy.context.object = obj`` will raise an error.
+
+But ``bpy.context.scene.objects.active = obj`` will work as expected.
+
+
+The context attributes change depending on where it is accessed. The 3D view has different context members to the Console, so take care when accessing context attributes that the user state is known.
+
+See :mod:`bpy.context` API reference
+
+
+Operators (Tools)
+-----------------
+
+Operators are tools generally accessed by the user from buttons, menu items or key shortcuts. From the user perspective they are a tool but Python can run these with its own settings through the :mod:`bpy.ops` module.
+
+Examples:
+
+ >>> bpy.ops.mesh.flip_normals()
+ {'FINISHED'}
+ >>> bpy.ops.mesh.hide(unselected=False)
+ {'FINISHED'}
+ >>> bpy.ops.object.scale_apply()
+ {'FINISHED'}
+
+.. note::
+
+ The menu item: Help -> Operator Cheat Sheet" gives a list of all operators and their default values in Python syntax, along with the generated docs. This is a good way to get an overview of all blender's operators.
+
+
+Operator Poll()
+^^^^^^^^^^^^^^^
+
+Many operators have a "poll" function which may check that the mouse is a valid area or that the object is in the correct mode (Edit Mode, Weight Paint etc). When an operator's poll function fails within python, an exception is raised.
+
+For example, calling bpy.ops.view3d.render_border() from the console raises the following error:
+
+.. code-block:: python
+
+ RuntimeError: Operator bpy.ops.view3d.render_border.poll() failed, context is incorrect
+
+In this case the context must be the 3d view with an active camera.
+
+To avoid using try/except clauses wherever operators are called you can call the operators own .poll() function to check if it can run in the current context.
+
+.. code-block:: python
+
+ if bpy.ops.view3d.render_border.poll():
+ bpy.ops.view3d.render_border()
+
+
+Integration
+===========
+
+Python scripts can integrate with Blender in the following ways:
+
+* By defining a rendering engine.
+
+* By defining operators.
+
+* By defining menus, headers and panels.
+
+* By inserting new buttons into existing menus, headers and panels
+
+
+In Python, this is done by defining a class, which is a subclass of an existing type.
+
+
+Example Operator
+----------------
+
+.. literalinclude:: ../../../release/scripts/templates/operator_simple.py
+
+Once this script runs, ``SimpleOperator`` is registered with Blender and can be called from the operator search popup or added to the toolbar.
+
+To run the script:
+
+#. Highlight the above code then press Ctrl+C to copy it.
+
+#. Start Blender
+
+#. Press Ctrl+Right twice to change to the Scripting layout.
+
+#. Press Ctrl+V to paste the code into the text panel (the upper left frame).
+
+#. Click on the button **Run Script**.
+
+#. Move you're mouse into the 3D view, press spacebar for the operator search
+ menu, and type "Simple".
+
+#. Click on the "Simple Operator" item found in search.
+
+
+.. seealso:: The class members with the **bl_** prefix are documented in the API
+ reference :class:`bpy.types.Operator`
+
+
+Example Panel
+-------------
+
+Panels register themselves as a class, like an operator. Notice the extra **bl_** variables used to set the context they display in.
+
+.. literalinclude:: ../../../release/scripts/templates/ui_panel_simple.py
+
+To run the script:
+
+#. Highlight the above code then press Ctrl+C to copy it
+
+#. Start Blender
+
+#. Press Ctrl+Right twice to change to the Scripting layout
+
+#. Press Ctrl+V to paste the code into the text panel (the upper left frame)
+
+#. Click on the button **Run Script**.
+
+
+To view the results:
+
+#. Select the the default cube.
+
+#. Click on the Object properties icon in the buttons panel (far right; appears as a tiny cube).
+
+#. Scroll down to see a panel named **Hello World Panel**.
+
+#. Changing the object name also updates **Hello World Panel's** Name: field.
+
+Note the row distribution and the label and properties that are available through the code.
+
+.. seealso:: :class:`bpy.types.Panel`
+
+
+Types
+=====
+
+Blender defines a number of Python types but also uses Python native types.
+
+Blender's Python API can be split up into 3 categories.
+
+
+Native Types
+------------
+
+In simple cases returning a number or a string as a custom type would be cumbersome, so these are accessed as normal python types.
+
+* blender float/int/boolean -> float/int/boolean
+
+* blender enumerator -> string
+
+ >>> C.object.rotation_mode = 'AXIS_ANGLE'
+
+
+* blender enumerator (multiple) -> set of strings
+
+ .. code-block:: python
+
+ # setting multiple camera overlay guides
+ bpy.context.scene.camera.data.show_guide = {'GOLDEN', 'CENTER'}
+
+ # passing as an operator argument for report types
+ self.report({'WARNING', 'INFO'}, "Some message!")
+
+
+Internal Types
+--------------
+
+Used for Blender datablocks and collections: :class:`bpy.types.bpy_struct`
+
+For data that contains its own attributes groups/meshes/bones/scenes... etc.
+
+There are 2 main types that wrap Blenders data, one for datablocks (known internally as bpy_struct), another for properties.
+
+ >>> bpy.context.object
+ bpy.data.objects['Cube']
+
+ >>> C.scene.objects
+ bpy.data.scenes['Scene'].objects
+
+Note that these types reference Blender's data so modifying them is immediately visible.
+
+
+Mathutils Types
+---------------
+
+Used for vectors, quaternion, eulers, matrix and color types, accessible from :mod:`mathutils`
+
+Some attributes such as :class:`bpy.types.Object.location`, :class:`bpy.types.PoseBone.rotation_euler` and :class:`bpy.types.Scene.cursor_location` can be accessed as special math types which can be used together and manipulated in various useful ways.
+
+Example of a matrix, vector multiplication:
+
+.. code-block:: python
+
+ bpy.context.object.matrix_world * bpy.context.object.data.verts[0].co
+
+.. note::
+
+ mathutils types keep a reference to Blender's internal data so changes can
+ be applied back.
+
+
+ Example:
+
+ .. code-block:: python
+
+ # modifies the Z axis in place.
+ bpy.context.object.location.z += 2.0
+
+ # location variable holds a reference to the object too.
+ location = bpy.context.object.location
+ location *= 2.0
+
+ # Copying the value drops the reference so the value can be passed to
+ # functions and modified without unwanted side effects.
+ location = bpy.context.object.location.copy()
+
+
+Animation
+=========
+
+There are 2 ways to add keyframes through Python.
+
+The first is through key properties directly, which is similar to inserting a keyframe from the button as a user. You can also manually create the curves and keyframe data, then set the path to the property. Here are examples of both methods.
+
+Both examples insert a keyframe on the active object's Z axis.
+
+Simple example:
+
+.. code-block:: python
+
+ obj = bpy.context.object
+ obj.location[2] = 0.0
+ obj.keyframe_insert(data_path="location", frame=10.0, index=2)
+ obj.location[2] = 1.0
+ obj.keyframe_insert(data_path="location", frame=20.0, index=2)
+
+Using Low-Level Functions:
+
+.. code-block:: python
+
+ obj = bpy.context.object
+ obj.animation_data_create()
+ obj.animation_data.action = bpy.data.actions.new(name="MyAction")
+ fcu_z = obj.animation_data.action.fcurves.new(data_path="location", index=2)
+ fcu_z.keyframe_points.add(2)
+ fcu_z.keyframe_points[0].co = 10.0, 0.0
+ fcu_z.keyframe_points[1].co = 20.0, 1.0
+
+
+Style Conventions
+=================
+
+For Blender 2.5 we have chosen to follow python suggested style guide to avoid mixing styles amongst our own scripts and make it easier to use python scripts from other projects.
+
+Using our style guide for your own scripts makes it easier if you eventually want to contribute them to blender.
+
+This style guide is known as pep8 and can be found `here <http://www.python.org/dev/peps/pep-0008>`_
+
+A brief listing of pep8 criteria.
+
+* camel caps for class names: MyClass
+
+* all lower case underscore separated module names: my_module
+
+* indentation of 4 spaces (no tabs)
+
+* spaces around operators. ``1 + 1``, not ``1+1``
+
+* only use explicit imports, (no importing '*')
+
+* don't use single line: ``if val: body``, separate onto 2 lines instead.
+
+
+As well as pep8 we have other conventions used for blender python scripts.
+
+* Use single quotes for enums, and double quotes for strings.
+
+ Both are of course strings but in our internal API enums are unique items from a limited set. eg.
+
+ .. code-block:: python
+
+ bpy.context.scene.render.file_format = 'PNG'
+ bpy.context.scene.render.filepath = "//render_out"
+
+* pep8 also defines that lines should not exceed 79 characters, we felt this is too restrictive so this is optional per script.
+
+Periodically we run checks for pep8 compliance on blender scripts, for scripts to be included in this check add this line as a comment at the top of the script.
+
+``# <pep8 compliant>``
+
+To enable line length checks use this instead.
+
+``# <pep8-80 compliant>``
+
diff --git a/doc/python_api/sphinx_doc_gen.py b/doc/python_api/sphinx_doc_gen.py
index f8561c719bc..6d29c57c91f 100644
--- a/doc/python_api/sphinx_doc_gen.py
+++ b/doc/python_api/sphinx_doc_gen.py
@@ -60,11 +60,13 @@ if __import__("sys").modules.get("bpy") is None:
# Switch for quick testing
if 1:
# full build
+ EXCLUDE_INFO_DOCS = False
EXCLUDE_MODULES = ()
FILTER_BPY_TYPES = None
FILTER_BPY_OPS = None
else:
+ EXCLUDE_INFO_DOCS = False
# for testing so doc-builds dont take so long.
EXCLUDE_MODULES = (
"bpy.context",
@@ -77,7 +79,7 @@ else:
"bpy.types", # supports filtering
"bpy.ops", # supports filtering
"bpy_extras",
- # "bge",
+ "bge",
"aud",
"bgl",
"blf",
@@ -85,7 +87,7 @@ else:
"mathutils.geometry",
)
- FILTER_BPY_TYPES = ("bpy_struct", "Panel", "Menu", "Operator", "RenderEngine") # allow
+ FILTER_BPY_TYPES = ("bpy_struct", "Panel", "ID") # allow
FILTER_BPY_OPS = ("import.scene", ) # allow
# for quick rebuilds
@@ -96,6 +98,13 @@ sphinx-build doc/python_api/sphinx-in doc/python_api/sphinx-out
"""
+# extra info, not api reference docs
+# stored in ./rst/info/
+INFO_DOCS = (
+ ("info_quickstart.rst", "Blender/Python Quickstart: new to blender/scripting and want to get you're feet wet?"),
+ ("info_overview.rst", "Blender/Python API Overview: a more complete explanation of python integration"),
+ ("info_gotcha.rst", "Gotcha's: some of the problems you may come up against when writing scripts"),
+ )
# import rpdb2; rpdb2.start_embedded_debugger('test')
@@ -744,6 +753,8 @@ def pyrna2sphinx(BASEPATH):
descr = prop.name
fw(" `%s`, %s, %s\n\n" % (prop.identifier, descr, type_descr))
+ write_example_ref(" ", fw, "bpy.types." + struct.identifier + "." + func.identifier)
+
fw("\n")
# python methods
@@ -999,14 +1010,17 @@ def rna2sphinx(BASEPATH):
fw("\n")
- fw("============================\n")
- fw("Blender/Python Documentation\n")
- fw("============================\n")
- fw("\n")
- fw("\n")
- fw("* `Quickstart Intro <http://wiki.blender.org/index.php/Dev:2.5/Py/API/Intro>`_ if you are new to scripting in blender and want to get you're feet wet!\n")
- fw("* `Blender/Python Overview <http://wiki.blender.org/index.php/Dev:2.5/Py/API/Overview>`_ for a more complete explanation of python integration in blender\n")
- fw("\n")
+ if not EXCLUDE_INFO_DOCS:
+ fw("============================\n")
+ fw("Blender/Python Documentation\n")
+ fw("============================\n")
+ fw("\n")
+ fw("\n")
+ fw(".. toctree::\n")
+ fw(" :maxdepth: 1\n\n")
+ for info, info_desc in INFO_DOCS:
+ fw(" %s <%s>\n\n" % (info_desc, info))
+ fw("\n")
fw("===================\n")
fw("Application Modules\n")
@@ -1208,6 +1222,11 @@ def rna2sphinx(BASEPATH):
shutil.copy2(os.path.join(BASEPATH, "..", "rst", "change_log.rst"), BASEPATH)
+
+ if not EXCLUDE_INFO_DOCS:
+ for info, info_desc in INFO_DOCS:
+ shutil.copy2(os.path.join(BASEPATH, "..", "rst", info), BASEPATH)
+
if 0:
filepath = os.path.join(BASEPATH, "bpy.rst")
file = open(filepath, "w")
diff --git a/doc/python_api/sphinx_doc_gen.sh b/doc/python_api/sphinx_doc_gen.sh
index a3befe1b7cb..ea55fbb3907 100755
--- a/doc/python_api/sphinx_doc_gen.sh
+++ b/doc/python_api/sphinx_doc_gen.sh
@@ -3,11 +3,21 @@
# bash source/blender/python/doc/sphinx_doc_gen.sh
# ssh upload means you need an account on the server
+
+# ----------------------------------------------------------------------------
+# Upload vars
+
+# disable for testing
+DO_UPLOAD=true
+
BLENDER="./blender.bin"
SSH_USER="ideasman42"
SSH_HOST=$SSH_USER"@emo.blender.org"
SSH_UPLOAD="/data/www/vhosts/www.blender.org/documentation" # blender_python_api_VERSION, added after
+# ----------------------------------------------------------------------------
+# Blender Version & Info
+
# 'Blender 2.53 (sub 1) Build' --> '2_53_1' as a shell script.
# "_".join(str(v) for v in bpy.app.version)
# custom blender vars
@@ -28,28 +38,52 @@ SSH_UPLOAD_FULL=$SSH_UPLOAD/"blender_python_api_"$BLENDER_VERSION
SPHINXBASE=doc/python_api/
+
+# ----------------------------------------------------------------------------
+# Generate reStructuredText (blender/python only)
+
# dont delete existing docs, now partial updates are used for quick builds.
$BLENDER --background --factory-startup --python $SPHINXBASE/sphinx_doc_gen.py
-# html
-sphinx-build $SPHINXBASE/sphinx-in $SPHINXBASE/sphinx-out
-cp $SPHINXBASE/sphinx-out/contents.html $SPHINXBASE/sphinx-out/index.html
-ssh $SSH_USER@emo.blender.org 'rm -rf '$SSH_UPLOAD_FULL'/*'
-rsync --progress -avze "ssh -p 22" $SPHINXBASE/sphinx-out/* $SSH_HOST:$SSH_UPLOAD_FULL/
+# ----------------------------------------------------------------------------
+# Generate HTML (sphinx)
-## symlink the dir to a static URL
-#ssh $SSH_USER@emo.blender.org 'rm '$SSH_UPLOAD'/250PythonDoc && ln -s '$SSH_UPLOAD_FULL' '$SSH_UPLOAD'/250PythonDoc'
+sphinx-build -n -b html $SPHINXBASE/sphinx-in $SPHINXBASE/sphinx-out
-# better redirect
-ssh $SSH_USER@emo.blender.org 'echo "<html><head><title>Redirecting...</title><meta http-equiv=\"REFRESH\" content=\"0;url=../blender_python_api_'$BLENDER_VERSION'/\"></head><body>Redirecting...</body></html>" > '$SSH_UPLOAD'/250PythonDoc/index.html'
-# pdf
-sphinx-build -b latex $SPHINXBASE/sphinx-in $SPHINXBASE/sphinx-out
-cd $SPHINXBASE/sphinx-out
-make
-cd -
+# ----------------------------------------------------------------------------
+# Generate PDF (sphinx/laytex)
-# rename so local PDF has matching name.
+sphinx-build -n -b latex $SPHINXBASE/sphinx-in $SPHINXBASE/sphinx-out
+make -C $SPHINXBASE/sphinx-out
mv $SPHINXBASE/sphinx-out/contents.pdf $SPHINXBASE/sphinx-out/blender_python_reference_$BLENDER_VERSION.pdf
-rsync --progress -avze "ssh -p 22" $SPHINXBASE/sphinx-out/blender_python_reference_$BLENDER_VERSION.pdf $SSH_HOST:$SSH_UPLOAD_FULL/blender_python_reference_$BLENDER_VERSION.pdf
+
+# ----------------------------------------------------------------------------
+# Upload to blender servers, comment this section for testing
+
+if $DO_UPLOAD ; then
+
+ cp $SPHINXBASE/sphinx-out/contents.html $SPHINXBASE/sphinx-out/index.html
+ ssh $SSH_USER@emo.blender.org 'rm -rf '$SSH_UPLOAD_FULL'/*'
+ rsync --progress -avze "ssh -p 22" $SPHINXBASE/sphinx-out/* $SSH_HOST:$SSH_UPLOAD_FULL/
+
+ ## symlink the dir to a static URL
+ #ssh $SSH_USER@emo.blender.org 'rm '$SSH_UPLOAD'/250PythonDoc && ln -s '$SSH_UPLOAD_FULL' '$SSH_UPLOAD'/250PythonDoc'
+
+ # better redirect
+ ssh $SSH_USER@emo.blender.org 'echo "<html><head><title>Redirecting...</title><meta http-equiv=\"REFRESH\" content=\"0;url=../blender_python_api_'$BLENDER_VERSION'/\"></head><body>Redirecting...</body></html>" > '$SSH_UPLOAD'/250PythonDoc/index.html'
+
+ # rename so local PDF has matching name.
+ rsync --progress -avze "ssh -p 22" $SPHINXBASE/sphinx-out/blender_python_reference_$BLENDER_VERSION.pdf $SSH_HOST:$SSH_UPLOAD_FULL/blender_python_reference_$BLENDER_VERSION.pdf
+
+fi
+
+
+# ----------------------------------------------------------------------------
+# Print some useful text
+
+echo ""
+echo "Finished! view the docs from: "
+echo " html:" $SPHINXBASE/sphinx-out/contents.html
+echo " pdf:" $SPHINXBASE/sphinx-out/blender_python_reference_$BLENDER_VERSION.pdf