accessing a bmesh from python would reallocate all customdata layers.
add an assert to BM_data_layer_free(), when its called unnecessarily since its reallocating all layers.
previous commit was incorrect, the face flipping depended on the orientation of the curve.
fix by passing the bevel direction to the fill function so we can have a reliable front/back.
This also gives some speedup for all curve filling since we can avoid calculating the normal since its already known.
- enable site-packages for bundled python distrobution, py3.2 had a problem where it would try to parse headers we didnt include, but its resolved now.
- workaround for glitch I was having on arch-linux where lib64 would be be used for the bundled python directory when it was just a symlink.
Most of the places which relied on RNA_path_resolve() did so believing that if
it returned true, that it had found a valid property, and that the returned
pointer+property combination would be what the path referred to. However, it
turns out that if the property at the end of the path turns out to be a
"pointer" property (e.g. "data" for Object.data), this would automatically
become the pointer part, while the prop part would be set to null. Hence, if a
user accidentally (or otherwise) specifies a path for the single-property driver
variable type like this, then Blender would crash.
This commit introduces two convenience functions - RNA_path_resolve_property()
and RNA_path_resolve_property_full() - which mirror/wrap the existing
RNA_path_resolve() functions. The only difference though is that these include a
check to ensure that what was found from resolving the path was in fact a
property (they only return true iff this is the case), and make it explicitly
clear in the name that this is what they will do so that there's no further
confusion. It is possible to do without these wrapper functions by doing these
checks inline, but the few cases that had been patched already were pretty
hideous looking specimens. Using these just make it clearer and simpler for all.
I've also beefed up the docs on these a bit, and changed these to using bools.
- add rna property 'as_bytes' method so you can get a string property as python bytes (bypass encoding).
- make bpy.path.abspath/relpath compatible with bytes.
- add 'relpath' option to bpy_extras.image_utils.load_image(), so you can load an image relative to a path.
- Revert some stylistic changes made in branch
They weren't directly related on freestyle project
and better be handled in trunk. Helps reading patches
ad prevents possible merge conflicts.
- Solved issue introduced with recent deprecation of
RenderData.maximize,
Conflicts resolved:
source/blenderplayer/bad_level_call_stubs/SConscript
Partly reverted changes to intern/cycles/blender/addon/ui.py in revision 52899
to make it easier to merge trunk changes.
This simply adds a third "translation type" (in addition to iface and tip), "new data", with relevant user settings flag and helper funcs/macros (and py api).
Currently implemented name translation when adding new objects, as well as modifiers and constraints, will add the others (cd layers, scenes, perhaps nodes [though I think they do not need this], etc.) later.
Issue is that the real default context is NULL, however, in python and RNA, this value can't be used easily. So we use a specific string instead ("*"), defined as BLF_I18NCONTEXT_DEFAULT_BPYRNA.
From now on, all bpy/rna code should only use the BLF_I18NCONTEXT_DEFAULT_BPYRNA value, while all "usual" C code should use the BLF_I18NCONTEXT_DEFAULT value (BLF_pgettext is still able to "understand" both, anyway).
Also added BLF_is_default_context helper func, so that we can keep that check in a single place!
Finally, we should no need anymore to understand the void string "" as default context too - two values for a same thing are more than enough!
PyNodes opens up the node system in Blender to scripters and adds a number of UI-level improvements.
=== Dynamic node type registration ===
Node types can now be added at runtime, using the RNA registration mechanism from python. This enables addons such as render engines to create a complete user interface with nodes.
Examples of how such nodes can be defined can be found in my personal wiki docs atm [1] and as a script template in release/scripts/templates_py/custom_nodes.py [2].
=== Node group improvements ===
Each node editor now has a tree history of edited node groups, which allows opening and editing nested node groups. The node editor also supports pinning now, so that different spaces can be used to edit different node groups simultaneously. For more ramblings and rationale see (really old) blog post on code.blender.org [3].
The interface of node groups has been overhauled. Sockets of a node group are no longer displayed in columns on either side, but instead special input/output nodes are used to mirror group sockets inside a node tree. This solves the problem of long node lines in groups and allows more adaptable node layout. Internal sockets can be exposed from a group by either connecting to the extension sockets in input/output nodes (shown as empty circle) or by adding sockets from the node property bar in the "Interface" panel. Further details such as the socket name can also be changed there.
[1] http://wiki.blender.org/index.php/User:Phonybone/Python_Nodes
[2] http://projects.blender.org/scm/viewvc.php/trunk/blender/release/scripts/templates_py/custom_nodes.py?view=markup&root=bf-blender
[3] http://code.blender.org/index.php/2012/01/improving-node-group-interface-editing/
Resolved conflicts:
release/datafiles/startup.blend
source/blender/editors/space_nla/nla_buttons.c
Also updated source/blender/blenkernel/intern/linestyle.c as a follow-up of
recent changes for the use of bool.
