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.
This can freeze Blender if you accidentally press ctrl+m on a large
script, conversion from text to 3d objects is fairly special case,
restricting access to the menu only.
When the keyframes at either end of the source curve don't lie on exact frame boundaries,
this casued problems with the Cycles F-Modifier, as part of the cycle would get chopped
off.
This was caused by float -> integer truncation that was occurring, since one variable
was of the wrong type. The problem here wasn't discovered until now (thanks to gcc's
invalid-type warnings on printf's) as in standard usage, we can safely assume that all
keyframes are strictly on frame boundaries.
In order to combat the problem of users frequently trying to use inlined
bpy.data/bpy.context paths for data access in their driver expressions
and then finding/complaining that these don't update correctly, the UI
now flags these as the error conditions that they are (with suggestions
on how to fix this).
Also tweaked the "Add Variable" button to have more descriptive text about
what exactly variables are and why to use these, along with some other
visual tweaks (icons!).
All textures are sampled bi-linear currently with the exception of OSL there texture sampling is fixed and set to smart bi-cubic.
This patch adds user control to this setting.
Added:
- bits to DNA / RNA in the form of an enum for supporting multiple interpolations types
- changes to the image texture node drawing code ( add enum)
- to ImageManager (this needs to know to allocate second texture when interpolation type is different)
- to node compiler (pass on interpolation type)
- to device tex_alloc this also needs to get the concept of multiple interpolation types
- implementation for doing non interpolated lookup for cuda and cpu
- implementation where we pass this along to osl ( this makes OSL also do linear untill I add smartcubic to the interface / DNA/ RNA)
Reviewers: brecht, dingto
Reviewed By: brecht
CC: dingto, venomgfx
Differential Revision: https://developer.blender.org/D317
dyntopo
Layer brush would not invalidate the layer_disp arrays in dyntopo mode,
checking only for the existence of the array. This means that if a tool
resized the node due to topology changes, the layer brush code could
index (and write!) out of bounds in the array. Solution is to invalidate
the layer data prior to each stroke in dyntopo.
- Added update callback to perform on-update validation when changing the
extrapolation mode on F-Curves
- There was a patch in the tracker for adding an "update()" method to F-Curves
which does a similar thing when manually called by scripts. Since we've added
a function for this in RNA anyways, we might as well add this too while we're
at it. (NOTE: upon closer inspection, the original patch by Tom Edwards had a
number of issues, so I ended up reimplementing here)
