This commit bundles new libmv version from own branch
which brings fix for wrong parameter block used for
modal solver parameterization.
Fixes#34985: Crash with Motion tracker (Tripod Motion)
render of objects could slow things down when redrawing the view each time a new
sample is displayed.
Now it does a partial redraw of the viewport with only the render border area,
skipping OpenGL object drawing while the render is refining.
The latest ffmpeg versions include a workaround to deal with a certain
pecularity in Canon DSLR footage: instead of decoding pictures with the
proper resolution of 1920x1080 they decode it with 1920x1088 and add a
black bar at the bottom.
Needless to say, that this screws up things in a lot of areas within blender
(proxy indices, mask animations etc.)
Since all blender versions besides Linux x86 32bit seem still to include
older ffmpeg versions which still contain this bug, this patch adds
a workaround for older versions until we have all versions on all platforms
up to date.
See also: http://git.libav.org/?p=libav.git;a=commit;h=30f515091c323da59c0f1b533703dedca2f4b95d
Robustness: Avoid translating the stencil outside the active area. Helps
to avoid losing the stencil somewhere in bitspace.
Usability: Take image repeat mapping and scaling into account when
fitting stencil aspect. Togglable by operator properties.
* Have all "Info" nodes next to each other.
* Moved "Material Output" to the top.
* Have all light shaders (Emission, Background, AO) next to each other.
Freestyle edge marks were messed up with Collision and other physics mesh modifiers.
The issue was due to copied Vlak instances without resetting edge marks to proper values.
Also made minor changes for avoiding unnecessary hash table lookups, and added an
assertion to check potential buffer overrun.
Option to draw mesh vertex-weights in editmode, available from the 'Mesh Display' panel.
TODO: get this to work when modifiers are applied in solid mode (texface-solidmode is working).
As some people have already noticed, the "Add" menu for nodes is a bit messy since pynodes merge. The reason for this is that the order of nodes in submenus (categories) was previously defined by the order in which all nodes are registered (at the bottom of blenkernel/intern/node.c). For the dynamic registration of node types now possible this system of defining node order along with registration is no longer viable: while it would still sort of work for C nodes, it is completely meaningless for dynamic (python) nodes, which are basically registered automatically in whatever order modules and addons are loaded, with the added complexity of unloading and reloading.
To fix this problem and add a bunch of desirable features this commit replaces the C menu with a python implementation. The new menu does not rely on any particular order of types in the node registry, but instead uses a simple explicit list of all the available nodes, grouped by categories (in scripts/nodeitems_builtins.py).
There are a number of additional features that become possible with this implementation:
1) Node Toolbar can be populated!
The list of nodes is used to create 2 UI items for each node: 1 entry in a submenu of "Add" menu and 1 item in a node toolbar panel with basically the same functionality. Clicking a button in the toolbar will add a new node of this type, just like selecting an item in the menu. The toolbar has the advantage of having collapsible panels for each category, so users can decide if they don't need certain nodes categories and have the rest more easily accessible.
2) Each node item is a true operator call.
The old Add menu is a pretty old piece of C code which doesn't even use proper operator buttons. Now there is a generic node_add operator which can be used very flexibly for adding any of the available nodes.
3) Node Items support additional settings.
Each "NodeItem" consists of the basic node type plus an optional list of initial settings that shall be applied to a new instance. This gives additional flexibility for creating variants of the same node or for defining preferred initial settings. E.g. it has been requested to disable previews for all nodes except inputs, this would be simple change in the py code and much less intrusive than in C.
4) Node items can be generated with a function.
A callback can be used in any category instead of the fixed list, which generates a set of items based on the context (much like dynamic enum items in bpy.props). Originally this was implemented for group nodes, because these nodes only make sense when linked to a node tree from the library data. This principle could come in handy for a number of other nodes, e.g. Image nodes could provide a similar list of node variants based on images in the library - no need to first add node, then select an image.
WARNING: pynodes scripters will have to rework their "draw_add_menu" callback in node tree types, this has been removed now! It was already pretty redundant, since one can add draw functions to the Add menu just like for any other menu. In the future i'd like to improve the categories system further so scripters can use it for custom node systems too, for now just make a draw callback and attach it to the Add menu.
If you have two windows, each with different scene, the render output for a window
would go to the other, if it was already drawing a render for the other scene.
Now you can have renders draw correct in two windows for two scenes.
