archive/blender-archive
Archived
1
1
Fork 0
Code Pull Requests Packages Activity

Merged changes in the trunk up to revision 42021.

Browse Source 
Conflicts resolved:
source/blender/blenkernel/intern/scene.c
source/blender/blenloader/intern/readfile.c
source/blender/editors/interface/resources.c
source/blender/render/intern/source/pipeline.c
This commit is contained in:
Tamito Kajiyama
2011-11-20 21:02:12 +00:00
parent bb9976f058 4ab1dadf72
commit 2676f2d58f
497 changed files with 12939 additions and 5809 deletions
Download Patch File Download Diff File Expand all files Collapse all files

45
doc/python_api/epy/testbgl.py
View File

@@ -1,45 +0,0 @@
# Testing the BGL module
import Blender
from Blender.BGL import *
from Blender import Draw
R = G = B = 0
A = 1
instructions = "Hold mouse buttons to change the background color."
quitting = " Press ESC or q to quit."
def show_win():
glClearColor(R,G,B,A) # define color used to clear buffers
glClear(GL_COLOR_BUFFER_BIT) # use it to clear the color buffer
glColor3f(1,1,1) # change default color
glRasterPos2i(50,100) # move cursor to x = 50, y = 100
Draw.Text("Testing BGL + Draw") # draw this text there
glRasterPos2i(350,20) # move cursor again
Draw.Text(instructions + quitting) # draw another msg
glBegin(GL_LINE_LOOP) # begin a vertex-data list
glVertex2i(46,92)
glVertex2i(120,92)
glVertex2i(120,115)
glVertex2i(46,115)
glEnd() # close this list
glColor3f(0.35,0.18,0.92) # change default color again
glBegin(GL_POLYGON) # another list, for a polygon
glVertex2i(315, 292)
glVertex2i(412, 200)
glVertex2i(264, 256)
glEnd()
Draw.Redraw(1) # make changes visible.
def ev(evt, val): # this is a callback for Draw.Register()
global R,G,B,A # it handles input events
if evt == Draw.ESCKEY or evt == Draw.QKEY:
Draw.Exit() # this quits the script
elif evt == Draw.LEFTMOUSE: R = 1 - R
elif evt == Draw.MIDDLEMOUSE: G = 1 - G
elif evt == Draw.RIGHTMOUSE: B = 1 - B
else:
Draw.Register(show_win, ev, None)
Draw.Register(show_win, ev, None) # start the main loop

121
doc/python_api/rst/info_gotcha.rst
View File

@@ -147,7 +147,7 @@ Armature Bones in Blender have three distinct data structures that contain them.
.. 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 is only possible in edit mode.
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 @@ 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
>>> 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 @@ 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 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 @@ While writing scripts that deal with armatures you may find you have to switch b
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 @@ Blenders relative file paths are not compatible with standard python modules suc
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 @@ Unicode encoding/decoding is a big topic with comprehensive python documentation
* 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 @@ 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.
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.

5
doc/python_api/sphinx_doc_gen.py
View File

@@ -597,6 +597,7 @@ def pycontext2sphinx(BASEPATH):
"active_base": ("ObjectBase", False),
"active_bone": ("Bone", False),
"active_object": ("Object", False),
"active_operator": ("Operator", False),
"active_pose_bone": ("PoseBone", False),
"armature": ("Armature", False),
"bone": ("Bone", False),
@@ -605,6 +606,7 @@ def pycontext2sphinx(BASEPATH):
"cloth": ("ClothModifier", False),
"collision": ("CollisionModifier", False),
"curve": ("Curve", False),
"dynamic_paint": ("DynamicPaintModifier", False),
"edit_bone": ("EditBone", False),
"edit_image": ("Image", False),
"edit_object": ("Object", False),
@@ -643,6 +645,7 @@ def pycontext2sphinx(BASEPATH):
"speaker": ("Speaker", False),
"texture": ("Texture", False),
"texture_slot": ("MaterialTextureSlot", False),
"texture_user": ("ID", False),
"vertex_paint_object": ("Object", False),
"visible_bases": ("ObjectBase", True),
"visible_bones": ("Object", True),
@@ -663,7 +666,7 @@ def pycontext2sphinx(BASEPATH):
char_array = c_char_p_p.from_address(attr)
i = 0
while char_array[i] is not None:
member = ctypes.string_at(char_array[i]).decode()
member = ctypes.string_at(char_array[i]).decode(encoding="ascii")
fw(".. data:: %s\n\n" % member)
member_type, is_seq = type_map[member]
fw(" :type: %s :class:`bpy.types.%s`\n\n" % ("sequence of " if is_seq else "", member_type))