Thanks to D1080 by @rockets, I've now been able to easily implement the
ability to type multiple word snippets/partial words into the text filter
field (in the Animation Editors), and have it filter the channels which
contain just some of those parts (instead of having to match everything).
For example, the following search strings will now work:
* "loc rot" or "lo ro" will now filter all location and rotation FCurves
* "col loc" will filter all location and color FCurves
* "scale" will also work as before to filter all scale FCurves
But, the following will not work:
* "lc rt" will NOT filter all location and rotation, as the fuzzy search only
breaks down the search string based on whitespace placement
By default, this is not enabled when using name filtering (i.e. magnifying glass is checked,
and some filtering text is specified). Instead, you need to enable the "AZ" toggle beside
the name field. This fuzzy matching is not enabled by default as it could end up being
quite a bit slower on really heavy scenes. (There are probably some optimisation
opportunities, but that's only a future option if someone really needs it)
This is a mix of regression and old unsupported configuration.
Regression was caused by some checks added on Blender side which was
checking whether python function returned error or not. This made it
impossible to enable Cycles when running from a file path which can't
be encoded with MBCS codepage.
Non-regression issue was that it wasn't possible to use pre-compiled
CUDA kernels when running from a path with non-ascii multi-byte
characters.
This commit fixes regression and CUDA parts, but OSL still can't be
used from a non-ascii location because it uses non-widechar API to
work with file paths by the looks of it. Not sure we can solve this
just from our side by using some codepage trick (UTF-16?) since even
oslc fails to compile shader when there are non-ascii characters in
the path.
* As requested by venomgfx, rotations now only display to 2 decimal places (more than
enough for rotations in degrees)
* Also, made it so that the "factor" types now show 3 dp (previously only 2, which isn't
really enough when dealing with values from 0.0 - 1.0)
The radial control operator is commonly used for setting sculpt brush Size and Strength
settings. However, when using it, it can often be difficult to remember which hotkey
is responsible for which setting, meaning that you can often accidentally modify the
wrong setting without knowing it (or even what new value you've set it to).
This commit makes it so that the property name and the current value are always shown
on the header. Previously this info was only shown when the doing numeric input.
(It also fixes a bug where the numeric input print would hang around even after it
wasn't being used).
Previously it would average all points under the brush, giving an off feedback loop that often depended on the
direction of the brush stroke, giving not-very-useful smearing effect.
Now blend brush smooths between connected edges.
rB5b3af3dd made the poll function here slightly too laxist.
To be backported to 2.77 should we make an 'a' release.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D1861
This patch implements Mirror influence for environment textures. Approach matches the one from BI.
{F281871}
See the video https://youtu.be/BskgCv6dcIE
Example: {F281876}
Alexander (Blend4Web Team)
Reviewers: campbellbarton, merwin, brecht
Reviewed By: brecht
Subscribers: TwisterGE, blueprintrandom, youle, Evgeny_Rodygin, AlexKowel, yurikovelenov
Differential Revision: https://developer.blender.org/D1786
Using 32nd bit of integer with our int RNA prop is not a good idea, it does not
really support unsigned int even with PROP_UNSIGNED type...
Most likely this has been unveiled by recent work over property clamping in RNA.
Not critical, but should be backported should we make an 'a' release.
When all the names in Blender were updated to go from having 32 characters to 64,
the "pchan_name" field in the DriverTarget struct was missed. This meant that if you
had a bone with a suitably long name, it would have been impossible to use values from this
bone in a driver.
The only reason this probably hasn't been discovered yet is because the standard/old depsgraph
doesn't work that well for bones in the same armatures, so setups where this may have
occurred are not that common.
To prevent this problem from happening in future, I've added the standard "MAX_ID_NAME-2"
comment to the comments on each line likely to be impacted by such changes, making it
easier for whoever does a search and replace in future :)
While this isn't essential, accessing this setting required navigating to each scene and using render menu.
Expose in sequencer UI for more convenient access.
Something weird, seems some buffers _might_ be shared between codec context
and frame, which is quite weird. Could be a bug in FFmpeg or could be wrong
API usage somewhere else..
Was possible to do Alt-RMB on a strips handle - which only make the strip active (but didn't select).
This isn't really useful, so just select the strip and its handles in this case.
