from Tom Edwards (artfunkel), with minor edits.
This patch makes the following improvements to environment map scripting:
* Adds a "is_valid" RNA property to envmaps. True if the map is ready for use, False if it needs rendering.
* Adds a "clear" RNA function to envmaps. Deletes any envmap image data.
* Adds a "save" RNA function to envmaps. Writes the envmap to disc with a configurable layout. (Defaults to the current hard-coded layout.)
* Updates bpy.ops.texture.envmap_save with configurable layout support as above.
These changes, particularly configurable layouts, make exporting envmaps to other software much easier.
Diff Keymaps
User edited keymaps now no longer override the builtin keymaps entirely, but
rather save only the difference and reapply those changes. This means they can
stay better in sync when the builtin keymaps change. The diff/patch algorithm
is not perfect, but better for the common case where only a few items are changed
rather than entire keymaps The main weakness is that if a builtin keymap item
changes, user modification of that item may need to be redone in some cases.
Keymap Editor
The most noticeable change here is that there is no longer an "Edit" button for
keymaps, all are editable immediately, but a "Restore" buttons shows for keymaps
and items that have been edited. Shortcuts for addons can also be edited in the
keymap editor.
Addons
Addons now should only modify the new addon keyconfiguration, the keymap items
there will be added to the builtin ones for handling events, and not get lost
when starting new files. Example code of register/unregister:
km = wm.keyconfigs.addon.keymaps.new("3D View", space_type="VIEW_3D")
km.keymap_items.new('my.operator', 'ESC', 'PRESS')
km = wm.keyconfigs.addon.keymaps["3D View"]
km.keymap_items.remove(km.keymap_items["my.operator"])
Compatibility
The changes made are not forward compatible, i.e. if you save user preferences
with newer versions, older versions will not have key configuration changes that
were made.
Actions now get tagged with an ID-code, which is used to determine
what ID-blocks they can be assigned to. This ensures that material
actions cannot be assigned to the object-level for example.
* Action lists in general will now show only the actions that can be
set for that particular slot. This prevents selection of invalid
actions, and helps cut down the list of actions.
** An exception here is the Add Action Clip in NLA Editor, which will
show all actions but will only add where appropriate. This is because
it's not easy/possible to tell in advance which blocktypes to filter
for when building this list. (TODO?)
* The "Action Editor" is now strictly for object-level action
editing+setting now. This avoids repeateded confusion by people who
try using this to view their shapekey actions, which should go to the
Shape Key Editor instead!
** A context switcher for the legitimate times where this capability
might come in handy is still being investigated.
* "Floating" actions (i.e. actions in some action_library.blend) are
NOT able to be automatically tagged until they are assigned to some
datablocks (i.e. loaded onto the rig + played back once). It is
possible to write scripts that check for certain RNA-paths and "guess"
what datablocks they work on, but it is recommended that you load up
the Datablocks Viewer, and go through such actions by hand, setting
the "ID Root Type" property as appropriate per action.
Crash in Bezier animation (inserting keys on control points in
curve object). The animation rna paths were not fixed after an
editmode session, which got fixed 2 weeks ago, but for all older
binaries the issue can still pop up.
The crash happened because the RNA array-itterator was not doing
a boundary check, even whilst the array size was passed on to the
itterator callbacks. With rna then writing far outside of valid
memory, very bad and unpredictable corruptions happen.
I've added a range check now, and a decent print to denote the
issue. An assert quit is useless, since a tab-tab on curve objects
will fix the channels nicely.
Example of warning print:
Array itterator out of range: Spline_bezier_points_lookup_int (index 30 range 2)
from Dan Eicher (dna)
Basically just wraps distfactor_to_bone() and passes the correct head/tail depending on which bone type it's called
from.
note:
renamed envelope() --> evaluate_envelope()
- move: material.add_texture(tex, coords, mapto) --> material.texture_slots.add()
- added material.texture_slots.create(index), material.texture_slots.clear(index)
- texture slot functions also work for lamp and world now.
Other minor changes
- allow rna functions to set FUNC_NO_SELF and FUNC_USE_SELF_ID at once.
- [#23317] Changed some operators' RNA to accept lengths, a modification I made to this patch made it not work as intended, removed this edit so unit buttons appier in the UI for certain operators.
- Sphinx doc gen, 2 columns rather then 3, didnt quite fit in some cases.
An example of how this is useful - an importer mixin could define the filepath properties and a generic invoke function which can run the subclasses exec for each selected file.
- Panels and Menus now skip the property check when registering.
- renamed _idproperties_ to _idprops_ in function names, function names were getting very long.
After initial talk with Matt (awhile ago) we realzed that rna_api would fit well for this instead of an operator.
The next step would be to move the current UI code to use the rna funcs instead.
Note: it takes the s/c/a as argument, not its name. (e.g. cont.link(actuator=act) )
Sample code to link all the logic bricks between each other:
ob = bpy.context.object
for cont in ob.game.controllers:
for sens in ob.game.sensors:
cont.link(sensor=sens)
for act in ob.game.actuators:
cont.link(actuator=act)
For a script to create bricks, link bricks, unlink bricks and remove them:
http://www.pasteall.org/14266
This commit is just meant to give the new GUI framework a concrete shape.
There is no usefulness in newly introduced elements at the moment.
Freestyle options in render layers now include a pull-down menu named Control
Mode that allows you to choose either the Python Scripting or Parameter Editor
mode. The Python Scripting mode is the conventional way of controlling
Freestyle by directly using style modules written in Python. The Parameter
Editor is a new control mode that is intended to be used by everyone without
relying on Python programming.
In the Parameter Editor mode, you can specify multiple line sets for each
render layer. A line set defines feature edge selection criteria, as
well as a line style for drawing the selected feature edges using specific
line stylization parameters. Line style is a new datablock type, meaning
that a line style can be shared by multiple line sets (possibly those in
different render layers in different scenes).
Much more additions are anticipated in subsequent commits to implement UI
controls for specifying feature edge selection criteria and line stylization
parameters.
