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.
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.
These were used in BL_CreatePhysicsObjectNew() in the converter. However, all
of the data put into KX_ObjectProperties was then copied again in
KX_ConvertBulletObject(). So, instead KX_ConvertBulletObject() now gathers the
information it needs itself, which avoid this odd double conversion step for
physics.
As a side-effect, the old code would result in static non-mesh objects with no bounds
set to still have triangle mesh bounds. This would result in no bounds for these objects.
If a bounds was set that required a mesh, non-mesh objects would become sphere bounds.
This is now true regardless of whether user bounds were set. In other words, static
non-mesh objects now use sphere bounds by default instead of mesh bounds. This might
slightly alter some games, but these objects should generally be set to No Collision
anyways.
