[Bf-blender-cvs] SVN commit: /data/svn/bf-blender [41955] branches/bmesh/blender: svn merge ^/trunk/blender -r41939:41954
Campbell Barton
ideasman42 at gmail.com
Fri Nov 18 06:06:57 CET 2011
Revision: 41955
http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=41955
Author: campbellbarton
Date: 2011-11-18 05:06:53 +0000 (Fri, 18 Nov 2011)
Log Message:
-----------
svn merge ^/trunk/blender -r41939:41954
Revision Links:
--------------
http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=41939
Modified Paths:
--------------
branches/bmesh/blender/SConstruct
branches/bmesh/blender/build_files/scons/tools/btools.py
branches/bmesh/blender/doc/python_api/rst/info_gotcha.rst
branches/bmesh/blender/release/scripts/modules/addon_utils.py
branches/bmesh/blender/release/scripts/startup/bl_ui/__init__.py
branches/bmesh/blender/release/scripts/startup/bl_ui/space_userpref.py
branches/bmesh/blender/source/blender/blenkernel/intern/fcurve.c
branches/bmesh/blender/source/blender/blenlib/intern/DLRB_tree.c
branches/bmesh/blender/source/blender/editors/interface/interface_anim.c
branches/bmesh/blender/source/blender/makesrna/RNA_types.h
branches/bmesh/blender/source/blender/makesrna/intern/makesrna.c
branches/bmesh/blender/source/blender/makesrna/intern/rna_actuator.c
branches/bmesh/blender/source/blender/python/BPY_extern.h
branches/bmesh/blender/source/blender/python/intern/bpy_driver.c
branches/bmesh/blender/source/blender/python/intern/bpy_driver.h
branches/bmesh/blender/source/blender/python/intern/bpy_rna.c
branches/bmesh/blender/source/blenderplayer/bad_level_call_stubs/stubs.c
branches/bmesh/blender/source/creator/CMakeLists.txt
Property Changed:
----------------
branches/bmesh/blender/
branches/bmesh/blender/release/
branches/bmesh/blender/release/scripts/
branches/bmesh/blender/source/blender/editors/space_outliner/
Property changes on: branches/bmesh/blender
___________________________________________________________________
Modified: svn:mergeinfo
- /trunk/blender:39992-41939
+ /trunk/blender:39992-41954
Modified: branches/bmesh/blender/SConstruct
===================================================================
--- branches/bmesh/blender/SConstruct 2011-11-18 04:55:43 UTC (rev 41954)
+++ branches/bmesh/blender/SConstruct 2011-11-18 05:06:53 UTC (rev 41955)
@@ -70,6 +70,7 @@
B = Blender
VERSION = btools.VERSION # This is used in creating the local config directories
+VERSION_RELEASE_CYCLE = btools.VERSION_RELEASE_CYCLE
### globals ###
platform = sys.platform
@@ -524,6 +525,10 @@
if '__pycache__' in dn: # py3.2 cache dir
dn.remove('__pycache__')
+ # only for testing builds
+ if VERSION_RELEASE_CYCLE == "release" and "addons_contrib" in dn:
+ dn.remove('addons_contrib')
+
dir = os.path.join(env['BF_INSTALLDIR'], VERSION)
dir += os.sep + os.path.basename(scriptpath) + dp[len(scriptpath):]
Modified: branches/bmesh/blender/build_files/scons/tools/btools.py
===================================================================
--- branches/bmesh/blender/build_files/scons/tools/btools.py 2011-11-18 04:55:43 UTC (rev 41954)
+++ branches/bmesh/blender/build_files/scons/tools/btools.py 2011-11-18 05:06:53 UTC (rev 41955)
@@ -52,7 +52,7 @@
else:
ver_display = "%s%s" % (ver_base, ver_char) # assume release
- return ver_base, ver_display
+ return ver_base, ver_display, ver_cycle
raise Exception("%s: missing version string" % fname)
@@ -80,7 +80,7 @@
# This is used in creating the local config directories
-VERSION, VERSION_DISPLAY = get_version()
+VERSION, VERSION_DISPLAY, VERSION_RELEASE_CYCLE = get_version()
REVISION = get_revision()
ENDIAN = checkEndian()
Modified: branches/bmesh/blender/doc/python_api/rst/info_gotcha.rst
===================================================================
--- branches/bmesh/blender/doc/python_api/rst/info_gotcha.rst 2011-11-18 04:55:43 UTC (rev 41954)
+++ branches/bmesh/blender/doc/python_api/rst/info_gotcha.rst 2011-11-18 05:06:53 UTC (rev 41955)
@@ -147,7 +147,7 @@
.. note::
- In the following examples ``bpy.context.object`` is assumed to be an armature object.
+ In the following examples ``bpy.context.object`` is assumed to be an armature object.
Edit Bones
@@ -163,11 +163,11 @@
This will be empty outside of editmode.
- >>> mybones = bpy.context.selected_editable_bones
+ >>> mybones = bpy.context.selected_editable_bones
Returns an editbone only in edit mode.
- >>> bpy.context.active_bone
+ >>> bpy.context.active_bone
Bones (Object Mode)
@@ -179,15 +179,15 @@
Returns a bone (not an editbone) outside of edit mode
- >>> bpy.context.active_bone
+ >>> 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
+ >>> bpy.context.object.data.bones["Bone"].use_deform = True
Accessible but read-only
- >>> tail = myobj.data.bones["Bone"].tail
+ >>> tail = myobj.data.bones["Bone"].tail
Pose Bones
@@ -199,20 +199,20 @@
.. code-block:: python
- # Gets the name of the first constraint (if it exists)
- bpy.context.object.pose.bones["Bone"].constraints[0].name
+ # 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
+ # 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.
+ 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`
+ 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
@@ -223,6 +223,86 @@
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.
+Data Names
+==========
+
+
+Naming Limitations
+------------------
+
+A common mistake is to assume newly created data is given the requested name.
+
+This can cause bugs when you add some data (normally imported) and then reference it later by name.
+
+.. code-block:: python
+
+ bpy.data.meshes.new(name=meshid)
+
+ # normally some code, function calls...
+ bpy.data.meshes[meshid]
+
+
+Or with name assignment...
+
+.. code-block:: python
+
+ obj.name = objname
+
+ # normally some code, function calls...
+ obj = bpy.data.meshes[objname]
+
+
+Data names may not match the assigned values if they exceed the maximum length, are already used or an empty string.
+
+
+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.
+
+
+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.
+
+.. code-block:: python
+
+ # typically declared in the main body of the function.
+ mesh_name_mapping = {}
+
+ mesh = bpy.data.meshes.new(name=meshid)
+ mesh_name_mapping[meshid] = mesh
+
+ # normally some code, or function calls...
+
+ # use own dictionary rather then bpy.data
+ mesh = mesh_name_mapping[meshid]
+
+
+Library Collisions
+------------------
+
+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.
+
+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.
+
+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.
+
+
+If you need to select between local and library data, there is a feature in ``bpy.data`` members to allow for this.
+
+.. code-block:: python
+
+ # typical name lookup, could be local or library.
+ obj = bpy.data.objects["my_obj"]
+
+ # library object name look up using a pair
+ # where the second argument is the library path matching bpy.types.Library.filepath
+ obj = bpy.data.objects["my_obj", "//my_lib.blend"]
+
+ # local object name look up using a pair
+ # where the second argument excludes library data from being returned.
+ obj = bpy.data.objects["my_obj", None]
+
+ # both the examples above also works for 'get'
+ obj = bpy.data.objects.get(("my_obj", None))
+
+
Relative File Paths
===================
@@ -230,12 +310,12 @@
Built in python functions don't understand blenders ``//`` prefix which denotes the blend file path.
-A common case where you would run into this problem is when exporting a material with assosiated image paths.
+A common case where you would run into this problem is when exporting a material with associated image paths.
>>> bpy.path.abspath(image.filepath)
-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 `bpy.types.ID`.
+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`.
>>> bpy.path.abspath(image.filepath, library=image.library)
@@ -289,7 +369,7 @@
* 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.
+* **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.
Strange errors using 'threading' module
@@ -458,3 +538,14 @@
**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.
+
+
+sys.exit
+========
+
+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.
+
+For example, the ``optparse`` module will print an error and exit if the arguments are invalid.
+
+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.
+
Property changes on: branches/bmesh/blender/release
___________________________________________________________________
Modified: svn:mergeinfo
@@ Diff output truncated at 10240 characters. @@
More information about the Bf-blender-cvs
mailing list