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.
In fact, some areas in FFmpeg might require alignment up to 32, so now we
make temporary conversion in an aligned frame. We only do this if width is
not aligned to 32.
As suggested by Sergey, do not register those anymore, this way we keep undo step,
but user cannot 'redo' them (does not work, since cached DM in particle modifier data
is not yet re-created by depsgraph update after undo when operator is redone).
UI now has two buttons, one to (dic)connect current psys, the other to (dis)connect all.
Also fixed similar issue with Connect Hair op.
This has several benefits:
* User count remains coherent, regardless of the order in which you use 'user_one' & real refcounting users
(i.e. if you add to group, and then link in scene, or the reverse, you now always get same final user count).
* Avoids the need to check for potential 'user_one' extra user in count in several places in code (e.g. when
making IDs single users...).
* Users won't wonder why they cannot make 'single user' and ID even though its user count shows '2'!
* readfile.c now always uses code from BKE's library.c when modifying id->us. Which means we can consider
(asside from assignment during initialization) that id->us is read-only outside of library.c context.
Note that this commit reverts previous one (rB6b1d77a8052b) - please **do not** backport this one in 2.77.
Similar cause as in T47482, we used to have poor handling of 'user_one' cases of ID usage,
leading to inconsistent behavior depending on order of operations e.g.
Here, was object used by a group but not linked in any scene - once linked in scene,
their usercount would be 2, leading to 'making single copy', when it's actually not needed.
We now have better control here, so let's use it!
Note that other ID 'make single user' code will likely need similar fix (Images, etc.).
Safe to be backported to 2.77.
Problem was, during initialization of boids particles in `dynamics_step()`,
psys of target objects was not obtained with generic `psys_get_target_system()`
as later in code, which could lead to some uninitialized `psys->tree` usage...
Think it's safe enough for 2.77, though not a regression.
