Before that depsgraph tagging was done from inside notifier listener in
viewport. This had the following issues:
- If there are no viewports, selection tag was not done. Causing possible
issues when object becomes visible.
- Required special trickery to detect which data to tag for update.
- Was causing crash when transforming/selecting markers in clip editor.
This is because selecting marker needed to poke viewport to redraw, since
selected bundles will be displayed differently in viewport.
This won't ever be used for this operator, as the "edit" operator should
only ever be used for dealign with a single driver - the one under the
cursor.
Previously, newly created drivers were set to "Scripted Expression"
mode and had their 'expression' field set to the pre-driver value of the
property, so that adding a driver didn't cause the property to immediately
lose its old value (and potentially causing havok in the scene).
However, this had the unintended consequence of making the driver setup
workflow more cumbersome, as you first had to replace that value with
the name of the driver variable before your driver would work.
This commit works around this issue by trying to combine the best of both
worlds (quite literally): Now, the driver expression for drivers created
using Ctrl-D will be "var + <old value>".
Thus, in the simplest case, the driver will do something as soon as you fill
out the driver variable settings (e.g. just filling out the Target Object field
will do it), meaning you get your drivers working faster. Of course, it may now
be necessary to edit out the old-value, and/or it might be a bit more confusing
what/why it's there for newbies. However, the improved ease of setup, and/or
a more tangible example of how an expression may be constructed outweigh the
downsides IMO.
This commit implements a new behaviour for the "Add Driver" functionality
(invoked from the RMB menu on a property, or by pressing Ctrl-D).
Instead of spawning a context menu asking you to pick the way
you want to create a driver, it will now just create a driver on the
property under the mouse and then show the "Edit Drivers" popover so
that you can immediately start editing the properties of this driver.
This way, the whole process is more visual and feels less blocking /
constrained, with less upfront decisions needed immediately.
Notes:
* The new behaviour is equivalent to choosing the "Manually Create (Single)"
and then doing a "Edit Driver" on the property
* Renamed the old "ANIM_OT_driver_button_add" operator to
"ANIM_OT_driver_button_add_menu". It will probably go away
in the near future, but it's better to keep it around for a
while longer still until the new workflow settles down.
Notes:
* Really need to address RNA setters case, end up adding way too much
G.main here these days... :/
* Added Main pointer into bAnimContext, helps a lot in anim code ;)
That bug was also likely affecting other cases - basically it was making
auto-keying always key from evaluated ('visual') values, never base,
data values... Added a flag, in some cases we do want evaluated values
here, obviously.
After more testing, I realised that bendy bone properties should also be grouped,
but probably all other per-bone settings too. Now, just group all of them, since
it's easier for everyone this way.
For many years, animators have been complaining about how keyframing a (transform)
property directly would leave them ungrouped, while keyframing them using a Keying Set
would put them into a group based on the name of the keyingset.
This commit attempts to improve (unify + make consistent) the default behaviour:
* All object transforms now get added to an "Object Transforms" group,
regardless of whether they were added individually via buttons or keyingset
* All bone transforms now get added to a group corresponding to the name of the bone
instead of only the ones added via keyingset
This commit adds a new menu entry - "Edit Driver" - the RMB menu that
will show a popover panel displaying the settings for the driver you
activated the menu item on. This shows the popover panel defined in
yesterday's commit (GRAPH_PT_drivers_popover).
It is possible to edit the driver settings from this panel now.
However, do be warned that the functionality presented is highly
WIP still. There are some unresolved issues, such as:
- The popover disappears too easily on any mouse movements/clicks
on anything, making the panel less useful right now than it should.
- The layout still needs refining. Currently the layout that's there
is a bit of a placeholder until we can play around with it a bit
more to see/feel what feels good/right or what is too much.
- The "Open Drivers Editor" on the bottom of the panel doesn't work.
There are some tricky context tricky things that need to happen here
to make that case work, since the operator button won't have the necessary
context info.
* Remove "Show Debug Info" option. Everyone has it turned on all the time,
since it's just useful to have
* Make the "Remove Driver" button less prominent. It doesn't happen that much,
so it shouldn't take up as much room
* Make "expressions" textbox wider (i.e. taking up the whole column width)
by separating the label and textbox on separate lines.
* Rename "Add Variable" button to make it clearer to users what "variables"
may be (i.e. they serve as a way to specify Inputs, just like adding a
"Source Data" node in a nodetree)
* Regroup buttons
When using copy on write, insert keyframe operators were reading from old
bmain data instead of COW data. This meant that inserting keyframes would
often read old/stale data, resulting in invalid keyframes getting created
(e.g. from last transform operation, instead of actual current state).
This commit makes it so that keyframing operators will ask depsgraph for
the evaluated copy of the data, so that it can read values from that. It
introduces a new function - `DEG_get_evaluated_rna_pointer()`, which when
working correctly/fully, should work just like the other `DEG_get_evaluated_*()`
functions, except it lets you pass in an RNA Pointer.
However, currently, this is only done for Pose Bones (as a dirty hack, since this
is an important/pivotal requirement for production) and/or datablock
properties directly (since we can just use the DEG_get_evaluated_id() directly).
on the datablock.
Committing to a branch for now as this all needs more testing. More work to come
later at a more sane time of day!
OVERVIEW
* In 2.7 terminology, all layers and groups are now collection datablocks.
* These collections are nestable, linkable, instanceable, overrideable, ..
which opens up new ways to set up scenes and link + override data.
* Viewport/render visibility and selectability are now a part of the collection
and shared across all view layers and linkable.
* View layers define which subset of the scene collection hierarchy is excluded
for each. For many workflows one view layer can be used, these are more of an
advanced feature now.
OUTLINER
* The outliner now has a "View Layer" display mode instead of "Collections",
which can display the collections and/or objects in the view layer.
* In this display mode, collections can be excluded with the right click menu.
These will then be greyed out and their objects will be excluded.
* To view collections not linked to any scene, the "Blender File" display mode
can be used, with the new filtering option to just see Colleciton datablocks.
* The outliner right click menus for collections and objects were reorganized.
* Drag and drop still needs to be improved. Like before, dragging the icon or
text gives different results, we'll unify this later.
LINKING AND OVERRIDES
* Collections can now be linked into the scene without creating an instance,
with the link/append operator or from the collections view in the outliner.
* Collections can get static overrides with the right click menu in the outliner,
but this is rather unreliable and not clearly communicated at the moment.
* We still need to improve the make override operator to turn collection instances
into collections with overrides directly in the scene.
PERFORMANCE
* We tried to make performance not worse than before and improve it in some
cases. The main thing that's still a bit slower is multiple scenes, we have to
change the layer syncing to only updated affected scenes.
* Collections keep a list of their parent collections for faster incremental
updates in syncing and caching.
* View layer bases are now in a object -> base hash to avoid quadratic time
lookups internally and in API functions like visible_get().
VERSIONING
* Compatibility with 2.7 files should be improved due to the new visibility
controls. Of course users may not want to set up their scenes differently
now to avoid having separate layers and groups.
* Compatibility with 2.8 is mostly there, and was tested on Eevee demo and Hero
files. There's a few things which are know to be not quite compatible, like
nested layer collections inside groups.
* The versioning code for 2.8 files is quite complicated, and isolated behind
#ifdef so it can be removed at the end of the release cycle.
KNOWN ISSUES
* The G-key group operators in the 3D viewport were left mostly as is, they
need to be modified still to fit better.
* Same for the groups panel in the object properties. This needs to be updated
still, or perhaps replaced by something better.
* Collections must all have a unique name. Less restrictive namespacing is to
be done later, we'll have to see how important this is as all objects within
the collections must also have a unique name anyway.
* Full scene copy and delete scene are exactly doing the right thing yet.
Differential Revision: https://developer.blender.org/D3383https://code.blender.org/2018/05/collections-and-groups/
Regression in recent undo system changes,
This caused T55048.
When each mode had its own undo stack it was important
to initialize it when entering edit-mode.
There are various values which depends on context in there, for example
current driver value and original DNA value f-curve is applied for.
This partially fixes issue with not being able to tweak keyed values
when material preview is open.
The material preview is not being currently updated against non-keyed
changes since every tweak of material property does full preview scene
depsgraph evaluation.
The Blender Internal removal (51b796ff15)
removed support for texture slots from Materials/Lamps/Worlds,
but didn't remove the relevant parts from the animation editor filtering
code that were responsible for adding the texture slots for those channels.
* Draw the frame/time number box over the scrollbar instead of above it,
to reduce the clutter/clashes with markers.
* Draw the box centered around the line instead of off to one side,
making it clearer that the frame shown is the one being affected.
* Make the box larger than the scrollbar + use white text to make it
stand out from the neighbouring frame numbers (otherwise, it's easy
to misread that it's just another one of those)
Based on discussions here in the office, this commit introduces a number of
changes to make the "Bind Camera to Markers" feature (introduced during Sintel
to facilitate camera switching, and now an integral part of the UI for doing this)
nicer to use.
Main changes:
* "Camera Markers" are now drawn using Camera icons, making it easier to
distinguish between them and other ("normal") markers
* "Camera Markers" will display the name of the bound marker, making it
easier to see what camera each marker uses. This will then also stay
in sync with the camera being used (though a manual refresh is needed
after renaming objects to make the timeline update), fixing the problem
where the marker's camera and the name get out of sync.
* Behaviour of Ctrl-B has been modified to make it easier to quickly add
these markers. Now, it will directly add a new marker on the current frame,
bound to the currently selected camera object. If there's an existing marker
on that frame, the existing marker's camera will be replaced instead of making
a new marker.
This commit removes all references to the old timeline editor.
Unfortuantely, the removal of the Timeline spacetype defining
functions has ended up breaking the version patching code I'd
been working on earlier (as now, the editor gets marked as
"unknown/info" before we get a chance to patch it!)
instead of using "black" curtains
With most editors now showing the start/end range by default, we need a way of
easily distinguishing when preview range is now enabled. By using a different color
(the exact color used is something we can change/adjust later), there is a more distinct
visual difference between them, making it easier to see what's happening.
This uses the global scene range, with styling matching the sequencer's start/end
frame drawing.
(The graph editor's "drivers" mode is exempt, as that doesn't really display time
in a linear way, so the start/end frames don't apply)
Eventually the idea is that they'll get remapped to some more global/generic hotkey
that can get used across all animation editors (see T54728). However, to facilitate
the removal of the timeline editor, it's better we do this now.
For many years, animators have been requesting the ability to edit keyframes in the
timeline. However, implementing such tools in the timeline quickly becomes a slippery
slope, where we'll eventually end up having to duplicate all the functionality from the
dopesheet editor.
Discussing with William and Pablo this morning, we realised that perhaps it might be possible
to just make the Timeline a mode of the Dopesheet Editor (and kill off the old standalone
Timeline), meaning that we essentially get all the Dopesheet Editor goodness for free!
Also, with some proposed UI updates (i.e. allowing "submodes" of editors to be part of the
the main editors selector), it might not even matter that there isn't an "actual" timeline
editor anymore.
This commit implements the following changes (which are actually sufficient for supporting
most basic workflows):
* Timeline mode in Dopesheet Editor
* Tweaks to UI code to make the Timeline header/menus show up in Dopesheet editor
TODO:
* Hide channels list when switching to timeline mode
* Port over cache-file indicators
* Add missing timeline-only settings that need a new home in the dopesheet
* Go through fixing all timeline editor operators (e.g. Bind to camera)
* Port over start/end frame shading (and adjust preview range rendering to make the
distinction between these clear)
* Remove old timeline editor, and transfer over any leftover code
Brecht authored this commit, but he gave me the honours to actually
do it. Here it goes; Blender Internal. Bye bye, you did great!
* Point density, voxel data, ocean, environment map textures were removed,
as these only worked within BI rendering. Note that the ocean modifier
and the Cycles point density shader node continue to work.
* Dynamic paint using material shading was removed, as this only worked
with BI. If we ever wanted to support this again probably it should go
through the baking API.
* GPU shader export through the Python API was removed. This only worked
for the old BI GLSL shaders, which no longer exists. Doing something
similar for Eevee would be significantly more complicated because it
uses a lot of multiplass rendering and logic outside the shader, it's
probably impractical.
* Collada material import / export code is mostly gone, as it only worked
for BI materials. We need to add Cycles / Eevee material support at some
point.
* The mesh noise operator was removed since it only worked with BI
material texture slots. A displacement modifier can be used instead.
* The delete texture paint slot operator was removed since it only worked
for BI material texture slots. Could be added back with node support.
* Not all legacy viewport features are supported in the new viewport, but
their code was removed. If we need to bring anything back we can look at
older git revisions.
* There is some legacy viewport code that I could not remove yet, and some
that I probably missed.
* Shader node execution code was left mostly intact, even though it is not
used anywhere now. We may eventually use this to replace the texture
nodes with Cycles / Eevee shader nodes.
* The Cycles Bake panel now includes settings for baking multires normal
and displacement maps. The underlying code needs to be merged properly,
and we plan to add back support for multires AO baking and add support
to Cycles baking for features like vertex color, displacement, and other
missing baking features.
* This commit removes DNA and the Python API for BI material, lamp, world
and scene settings. This breaks a lot of addons.
* There is more DNA that can be removed or renamed, where Cycles or Eevee
are reusing some old BI properties but the names are not really correct
anymore.
* Texture slots for materials, lamps and world were removed. They remain
for brushes, particles and freestyle linestyles.
* 'BLENDER_RENDER' remains in the COMPAT_ENGINES of UI panels. Cycles and
other renderers use this to find all panels to show, minus a few panels
that they have their own replacement for.
