This was caused by static variables used in plNearestPoints().
For now solved by making the solvers allocated in the stack,
seems no noticeable affect on the simulation speed so far.
This is a regression introduced in fbc7ab30f and caused by the wrong object
being passed to the function.
Not sure passing editnurb as an argument is a good thing to do..
The copy-to-selected operator for RNA buttons uses paths for copying
object pointer properties. Copying other ID data blocks is deliberately
disabled:
https://developer.blender.org/diffusion/B/browse/master/source/blender/editors/interface/interface_ops.c$274
However, the RNA_path_resolve_full function is not properly working for
retrieving pointer properties: it always will dereference pointer
properties in anticipation of further path elements.
In fact the return value of RNA_path_resolve_full has a conflicting
double meaning. It returns `false` when
* the RNA path is invalid
* any of the pointer properties is NULL
This means that it is not capable of returning pointer properties at all.
To make this possible, there is now an internal function for path
parsing, which returns false //only// if the the path is invalid.
On top of this there are 4 wrapper functions for retrieving either
actual property values (RNA_path_resolve, RNA_path_resolve_full) and for
retrieving pointer+property pairs (RNA_path_resolve_property,
RNA_path_resolve_property_full). The latter 2 variants will **not**
dereference pointer properties at the end of the path, so callers can
actually get the property itself. The `***_full` variants include an
array index return value.
Differential Revision: https://developer.blender.org/D396
This was suggested by Christopher Barrett (terrachild). Corner pin is a common feature in compositing.
The corners for the plane warping can be defined by using vector node inputs to allow using perspective plane transformations without having to go via the MovieClip editor tracking data.
Uses the same math as the PlaneTrack node, but without the link to MovieClip and Object.
{F78199}
The code for PlaneTrack operations has been restructured a bit to share it with the CornerPin node.
* PlaneDistortCommonOperation.h/.cpp: Shared generic code for warping images based on 4 plane corners and a perspective matrix generated from these. Contains operation base classes for both the WarpImage and Mask operations.
* PlaneTrackOperation.h/.cpp: Current plane track node operations, based on the common code above. These add pointers to MovieClip and Object which define the track data from wich to read the corners.
* PlaneCornerPinOperation.h/.cpp: New corner pin variant, using explicit input sockets for the plane corners.
One downside of the current compositor design is that there is no concept of invariables (constants) that don't vary over the image space. This has already been an issue for Blur nodes (size input is usually constant except when "variable size" is enabled) and a few others. For the corner pin node it is necessary that the corner input sockets are also invariant. They have to be evaluated for each tile now, otherwise the data is not available. This in turn makes it necessary to make the operation "complex" and request full input buffers, which adds unnecessary overhead.
option after reentering a paint mode.
Solution by Bastien with modifications, thanks!
Show Brush flag need not be reenabled always, but make sure it is at
least enabled once on paint initialization.
* Moved collection key parsing and array index parsing into their own
functions, to make the main path loop easier to follow.
* Unified boolean return values.
This adds a new option "Sample All Lights" to the Sampling panel in Cycles (Branched Path). When enabled, Cycles will sample all the lights in the scene for the indirect samples, instead of randomly picking one. This is already happening for direct samples, now you can optionally enable it for indirect.
Example file and renders:
Blend file: http://www.pasteall.org/blend/27411
Random: http://www.pasteall.org/pic/show.php?id=68033
All: http://www.pasteall.org/pic/show.php?id=68034
Sampling all lights is a bit slower, but there is less variance, so it should help in situations with many lights.
Patch by myself with some tweaks by Brecht.
Differential Revision: https://developer.blender.org/D391
In many BI shader setups, the material which owns the nodetree is often itself
included as a node in that nodetree (i.e. to provide the base colour for that
mesh). This would often result in the material (and its subtree) getting included
in the dopesheet results twice.
