* 'Show Debug' now enabled for all newly created drivers. For most users, it is
useful to be able to see this to help figure out what's going on
* Removed failed experiment of creating new drivers with Generator FModifiers. I
had hoped that this would make it easier to create drivers that doubled or
halved the input values, but that has proved to not be the case, and instead
made harder for most users to set things up (as they'd have to remove these
first).
Now, when adding drivers from the UI, these get created with two keyframes (at
(0,0) and (1,1) for a 1-1 mapping), which can be easily tweaked normally.
However, for backwards compatability of scripts (notably rigify, and perhaps
some others out there), when creating drivers from scripts, they will still get
created with Generator FModifiers for now. We can review this situation again
for 2.7, but for now it seems ok.
of keyframe verts
Previously, every time you toggled the selection of all keyframes (using AKEY),
the active curve would get deselected and deactivated. However, this was a pain
when trying to tweak the shape of a particular curve, as doing this would cause
that curve to either fade into the background or into the jumble of other
curves.
It is now possible to use "Apply Scale" for Empties. While Empties don't exactly
have any Object data attached to them which can be used for supporting "true"
apply scale (i.e. with non-uniform scaling), they do have a drawsize value which
controls how large the empties are drawn (before scaling). This works by taking
the scale factor on the most-scaled axis, and combines this with the existing
empty drawsize to maintain the correct dimensions on that axis at least.
Core Assumptions:
1) Most scaled empties have uniform scaling anyways (i.e. most empties used for
bone shapes)
2) On balance, preserving non-uniform scaling of empties after apply scale is
not as important as not being able to do it at all
This means calling invoke operators from python in states that dont support will give a meaningful error message.
also reduce context lookups when polling.
So now, their generation is controlled by a flag, else previous "simple values" group ids are generated (one per poly region, no need here to reduce the number of used IDs!).
Will update obj exporter too.
In fact, smooth groups are supposed to be bitflags, not simply integer values (would be far too much simple!). This adds quite a bit of work, as with only 32 values, we can't just assign one to each group. Somewhat related to the "Four colors theorem"! ;)
Here we simply use the first available bit for current smooth group (i.e. first bit not used by any of the already defined contiguous groups).
The internal connections used for muted nodes are a "best guess" only. The algorithm would connect linked input/output sockets first, regardless of sensible connections. Replaced this by a more strict
connection method now which only uses matching types, so that Normal outputs won't get input from values, etc.
This is still far from perfect though. Eventually it may be necessary to implement dedicated methods for certain types of nodes to respect different semantics - using the plain socket type is just not
enough information. Also the value used for connections from muted nodes with no matching input will currently be the hidden(!) socket input values, this can lead to unexpected results. Needs further
thought ...
The BKE_bpath_traverse_id method updates path variables of image data blocks, but did not cause the image to be reloaded (or rather, tagged so it gets reloaded on next use). This requires also updating
all the ImageUser "ok" tags, which happens in some odd places in other cases where reload happens (e.g. the reload operator and the image path button handler function in image template).
Byte images and movies will now fully follow input color space.
Before this non-sRGB input colorspace for byte images and movies
behave really doggy (results in preview and final render were
totally different).
To prevent data loss, if byte image is set not stored in sequencer's
space it'll be internally converted to float buffer.
In theory some setups might be rendering a bit different now, but
new behavior is totally expected and someone used non-sRGB input
space for byte images/movies had Convert Float enabled anyway.
Issue was caused by tacks map merge re-allocating the tracks and this
didn't update plane tracks.
Ideally tracks_map_merge shall not re-allocate tracks, but for now
just update plane tracks. Shouldn't be too much slow anyway and could
always be tweaked without affecting any artists.
curve children of a triangle vertex parent would only display their relationship line to the first vertex. (confusing)
also added OB_TYPE_SUPPORT_PARVERT macro.
previously this had to be done one by one.
both single and triagle vertex parents can be made, selected based on distance to the verts.
Developer notes:
- looks like this was old TODO, enums existed but weren't used.
- only meshes currently support using.
- added BKE_object_as_kdtree(), may come in handy for similar cases.
Also fixed a nasty (but inofensive for now) stuff, we had both MOD_UVPROJECT_MAX and MOD_UVPROJECT_MAXPROJECTORS (the former used in RNA code, the later in modifier code)! Kept MOD_UVPROJECT_MAXPROJECTORS.
Instead of having ifdef __GNUC__ all over the headers
to use special compiler's hints use a special file where
all things like this are concentrated.
Makes code easier to follow and allows to manage special
attributes in more efficient way.
Thanks Campbell for review!
A new operator to alter the backdrop zoom level so that it fits fully within the node editor area, and centers the image.
Shortcut alt-home, as home is used for fitting stuff into the view everywhere.
- replace numbers with defines for allocation increments and default array size.
- move array reallocation into a static function (deduplicate 2x).
also fix own mistake with uninitialized slop-space var in memory printing statistics.
In file included from source\blender\compositor\operations\COM_PlaneTrackMaskOperation.cpp:31:0:
source\blender\blenlib/BLI_jitter.h:36:65: error: expected ',' or '...' before numeric constant
source\blender\blenlib/BLI_jitter.h:37:65: error: expected ',' or '...' before numeric constant
It appears that an include used in COM_PlaneTrackMaskOperation.cpp brings in some Windows header file, which in turn defines rad/rad1/rad2 as some numeric constants.
Apparently mingw/gcc is too stupid to recognise that the values
in alphatest will only be used if they're within the range of
unsigned char (i.e. 0 <= x < 255) when this is done using a ternary
operator. Then again, it's quite hard for humans to immediately
parse what is going on here either! Converting this clever code
back to a more obvious form that mere mortals (and compilers it
seems) can handle with ease ;)
