This operator (the snowflake icon, beside the pushdown button on the Action Editor
header) adds the currently active action to the NLA stack in a muted track, then
creates + loads a new action ready to be populated with new keyframes.
Since the NLA is being used to hang on to all the actions here, no actions are
getting lost.
Usage Notes (there will be some additional tweaks to make this nicer):
* To preview different actions that have been "stashed", simply click the "Solo"
toggle for the track containing the action in question. Playing back the NLA will
now show the stashed track
* To edit a previously stashed action - simply enter tweakmode on it in the NLA
while the "Solo" toggle is enabled.
Todo:
* Add some more operators here to polish up the Action <-> NLA bridge to make the
layered and stash workflows smoother. Examples include some tools to easily
switch between the different actions layers in the stack, as well as making it
easier to get out of tweakmode (and sync up the action lengths)
* Review and cleanup the behaviour of the "new" operator here to avoid the old
problems that users were running into
* After the next release - Implement the full Action Libraries functionality, with
ways to bridge the stashed strips over to a full-blown library.
The Solo and Mute functionality for the NLA system should really be mutually
exclusive features. They both affect whether a given track applies or not.
The only difference is that the Solo option mutes all the others, while the Mute
only does this on a per track basis.
Before this fix, muting a strip and then making it solo meant that the solo'd
track would not play at all, which isn't really what we want.
This commit exposes the "Push Down" button/functionality found in the NLA Editor
to the Action Editor, so that actions can be added NLA Stack from here too. The
main point of this for now is to make the whole layered-animation workflow nicer
more efficient, but not requiring the second editor be visible in common cases.
It also conveniently sets things up for the next few changes (already hinted at
here)...
(Note for the uninitiated looking at the diffs: this is very much *not* what
you're probably thinking right now, if you're looking at the line in
act_new_exec())
* There was no real default value for this parameter (neither "" nor None would work the same as
not specifying that parameter). Now, 'None' is considered as default value, and you get
exact same behavior with this value and if not specifying it. This is important at least for
consistency, and potentially too in some esoteric cases (like generated code or so).
* Add a warning about the fact that 'default' parameter shall not be psecified when items
are given a callback function.
Own mistake in refactoring of `BLI_strncpy_wchar_as_utf8()`, if given size was exactly
the one needed, we'd lost last char (off-by-one error).
Many thanks to plasmasolutions (Thomas Beck) who found the issue and did
all the investigation work here!
This is still not so correct, to make it work we really have to do a
blurring pass based on the real coc (currently we are just blending 3
levels of blur)
`enforce_locks()` would reset weights of non-locked modified vgroups if it could not
find any other non-modified non-locked vgroup to 'distribute' weights into.
Sounds rather stupid, yet I hope I did not break something else, this code
is rather convoluted to say the least.
Side-reported by zeauro (ronan ducluzeau) in T43814, thanks!
This patch fix two bugs related to CreateConstraint().
1. Disable linked collision only working with 6DoF constraints.
2. If all pivot axis rotations setted to zero the linked object disappears.
{F101374}
Reviewers: moguri, sybren, brita_, lordloki
Reviewed By: lordloki
Subscribers: p9ablo
Differential Revision: https://developer.blender.org/D704
Things here are simple, selected bone joint could have same priority as
unselected bone, so bone would always win. Gave joints a little more
priority than bones, usually user will be more precise just to select
the joint anyway.
frame start.
Issue here is that if we failed to get an image from the cache, we would
try to load from file. This would fail when the queried frame was less
than the animated sequence start frame, and invalidate the OK state of
the image.
Solution is that when loading from cache succeeds, we also reset the OK
state of the image for animated textures.
The fix might be relevant elsewhere too, but kept it isolated just in
case.
We need to use 'W' widechar variants of win funcs and convert wchar to utf8-encoded bytes
in those cases, sigh...
Note: theoritical fix only, need org reporter to test it...
- spiral scheme is much more intuitive here. Also use float number for
spirals to avoid having samples on the same radial direction when sample
number is divisible by spiral number.
OpenGL is detected:
Hoping to decrease the frequency of by far one of the most frequent bug
reports by windows users.
There is some reorganization of the GHOST API to allow easy addition of
further OpenGL options in the future. The change is not propagated too
deep to keep the size of the patch managable. We might reorganize things
here later.
For OpenGL we do two checks here:
One is a combination of GDI generic renderer or vendor microsoft
corporation and OpenGL version 1.1. This means the system does not
use GPU acceleration at all. We warn user to install a graphics
driver and of cases where this might happen (remote connection, using
blender through virtual machine)
The other one just checks if OpenGL version is less than 1.4 (we can
easily change that in the future of course) and warns that it is
deprecated.
Both cases will still let blender startup correctly but users should now
have a clear idea of the system being unsupported.
A user preference flag is provided to turn the warning off.
Now stop posting those bug reports without installing a driver first -
please?
Two issues in this report:
* Shift-F key conflict between painting and selecting mirrored bone
(moved select mirrored to ctrl-shift-F)
* It was possible to display texture overlay in weight painting, even
though the mode does not support textures yet.
Naming here is slightly misleading. We have:
* Number of elements (objects) that can be picked
* Buffer size
* Number of integers in buffer.
Interestingly enough, bufsize in OpenGL (as far as I could find in
examples on the web) and in most of the code refers to the latter and
actual buffer size is only used whenever we do allocations on the heap.
Added an extra defines here to make things a bit clearer:
* MAXPICKELEMS refers to the number of objects that can be picked
* MAXPICKBUF refers to the number of integers in the selection buffer
Also made all buffers use MAXPICKBUF where some used MAXPICKBUF * 4.
That means that some parts of blender will use less space for selection
now. MAXPICKBUF is set to 10000 for 2500 object selection, which can be
changed at any time, but I think 10000 integers on the stack touches the
borders of uglyland anyway.
