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. @@
_______________________________________________
Bf-blender-cvs mailing list
[email protected]
http://lists.blender.org/mailman/listinfo/bf-blender-cvs
