Note this is only a workaround in fact, adding some precision in radians case.
Validating the field will still generate a precision loss (doing otherwise is
doable-ish, but likely to backfire and/or add too much complexity in an already
complex area).
Since the NLA was also using the standard transform mode by default, this meant that
no frame/second step-snapping was happening here (i.e. like for the Graph Editor).
The actual differences between doing true stepping vs nearest here are quite small
(and don't really make much sense with NLA Strips), so for now, it should be fine that
these are the same.
The previous behaviour for nearest second meant that transforming the strips often
caused their lengths to change (sometimes drastically), since strip lengths aren't
always uniformly x-seconds long. Now, it only snaps the start frame value, and adjusts
the end of the strip to follow.
This works well for most cases, apart from negatively scaling the strip, where it will
get "stuck" as a 0.001 frame long strip (and the viewport drawing will be a bit weird
during this time). Nevertheless, negative scaling of strips isn't something that's exactly
recommended.
This commit cleans up and fixes some problems related to how the auto-snapping
behaviour in the animation editors works, resolving the issues mentioned in T39819.
1) "Nearest Frame" no longer snaps to the nearest second when time is displayed in seconds.
Instead, there is now also a "Nearest Second" option, so that either can be used
as needed instead of only when a certain time display is used.
2) A similar change has been made for "Time Step" - This is now "Frame Step" and "Second Step"
respectively.
Notes:
* Removed the unneeded getAnimEdit_DrawTime()
* Time Step/Frame Step don't work for Graph Editor yet (and seem to not have worked at all)
* NLA Editor also seems to be showing some weirdness now. Will be checked on.
* Cancelling nearest-second snapping doesn't work nicely, due to another bug with GraphEdit transforms.
Making both keymap and menu values the same, and adding a (debug only) check in
IDP_EqualsProperties_ex() warning when comparing two floats with nearly the same value.
* The button icon for jumping to the Render Layers tab of the Properties context is
now RENDERLAYERS. Previous icon BUTS was too general.
* Thickness position options are grayed out if not applicable. These options are applied
only when plain chaining is used with the Same Object option enabled.
Sequencer preview was rendering all scenes with the context
resolution, which doesn't give proper result. Now made it so
sequencer scene preview uses scene's resolution.
After recently reading through Robert Penner's original descriptions of these
easing equations for some other work I've been doing, I realised that the
ordering I introduced earlier was slightly off (with regards to sine and circular
types). This commit recitifies these issues.
When the dopesheet was open, "keyframe edited" events from the graph editor
(i.e. fired whenever any properties on keyframes or FModifiers are changed)
would trigger the dopesheet to synchronise selection states of anim channels
and ensure that FCurve autocolours are initialised correctly.
This however was undesired when editing properties in the graph editor. Now,
made it so that keyframe adding/removing operators use different notifier flags
to specify that the channels might have changed + need colour syncing, and
adjusted the dopesheet updating logic to fit
* Moving the BlenderDebugDraw (derived from btIDebugDraw) from
KX_BlenderSceneConverter to CcdPhysicsEnvironment
* Moving CcdPhysicsEnvironment initialization to CcdPhysicsEnvironment
(this could probably be cleaned up some more with some sort of
factory, or at least moving code to CcdPhysicsEnvironment's
constructor)
* Simplifying physics environment initialization (went from two
switches to one)
As suggested by Campbell, bump subversion and reset all ui_previews data (so that any file that could
have been corrupted in past two weeks because of this bug is fixed and valid again).
More like a workaround, current depsgraph does not really allow for animated layers,
esp. when we alwys expect at least one to be enabled (same issue as with basic Scene layers).
So, turned out after all we need a foreachmapped helper for loops as well... :/
CDDM and EBDM were reasonably simple, but I fought hours with CCGDM (subsurf) to find only a
bad working solution (see D478). So I fallback to a code similar to CDDM one.
Probably not nice for performances, but loops and subsurf are not matching well...
Reviewers: campbellbarton
CC: brecht
Differential Revision: https://developer.blender.org/D478
Also refactor:
- Material property UI related to shadows
- Preparation of OR-ed mode flags (ma->mode_l) of render materials
Reviewers: brecht
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D313
Problem was introduced back in 2.70 during Project Pampa when the FCurve Normalisation
feature was introduced. The cause was that the normalised cursor value was always getting
passed to the KeyframeEditData context, even when it wasn't needed.
