Python scripts can now define the reason it's poll function fails using:
`Operator.poll_message_set(message, ...)`
This supports both regular text as well as delaying message creation
using a callback which should be used in situations where constructing
detailed messages is too much overhead for a poll function.
Ref D11001
This adds the initial boilerplate code that is required to introduce
the new spreadsheet editor. The editor is still hidden from the ui.
It can be made visible by undoing the change in `rna_screen.c`.
This patch does not contain any business logic for the spreadsheet editor.
Differential Revision: https://developer.blender.org/D10645
Ref T86279.
This is similar to c4a2067130130d, but applies to the general UI and is only
about single data-blocks. Here there was a similar problem: How can buttons
pass the data they represent to operators? We currently resort to ugly ad-hoc
solutions like `UI_context_active_but_get_tab_ID()`. So the operator would need
to know that it is executed on a tab button that represents a data-block.
A single button can now hand operators a data-block to operate on. The operator
can request it via the "id" context member (`CTX_data_pointer_get_type(C, "id",
&RNA_ID)` in C, `bpy.context.id` in .py).
In this commit, it is already set in the following places:
* Generic RNA button code sets it to the pointed to data-block, if the button
represents a data-block RNA pointer property. (I.e for general data-block
search buttons.)
* Data-block selectors (`templateID`) set it to the currently active data-block.
* The material slot UI-List sets it for each slot to the material it represents.
The button context menu code is modified so its operators use the context set
for the layout of its parent button (i.e. `layout.context_pointer_set()`).
No user visible changes. This new design isn't actually used yet. It will be
soon for asset operators.
Reviewed as part of https://developer.blender.org/D9717.
Reviewed by: Brecht Van Lommel
The way the Outliner integrates operations on selected tree elements is known
to be quite problematic amongst developers. The context menu is generated in an
unusual way and doesn't use the normal operator system. Instead, changes are
applied via a recursive callback system. Things are quite ad-hoc, and the
callbacks often implement logic that should not be in the Outliner, but in
entirely different modules. Often these modules already contain the logic, but
as proper operators.
This commit is a step into a hopefully better direction that should allow us to
put actual operators into Outliner context menus. It starts solving the problem
of: How can the Outliner pass selected data to operators. It implements it for
data-blocks only, but other data could do it in the same way.
Idea is to keep doing what operators were initially designed to do: Operate on
context.
Operators can now query a "selected_ids" context member
(`CTX_data_selected_ids()` in C, `bpy.context.selected_ids` in .py). If an
Outliner is active, it will generate a list of selected data-blocks as a
response, via its `SpaceType.context` callback.
Any other editor could do the same.
No user visible changes. This new design isn't actually used yet. It will be
soon for asset operators.
Reviewed as part of https://developer.blender.org/D9717.
Reviewed by: Brecht Van Lommel
Define enum `eContextResult` and use its values for returns, instead of
just returning 1, 0, or -1 (and always having some comment that explains
what -1 means).
This also cleans up the mixup between returning `0` and `false`, and `1`
and `true`. An inconsistency was discovered during this cleanup, and
marked with `TODO(sybren)`. It's not fixed here, as it would consititute
a functional change.
The enum isn't used everywhere, as enums in C and C++ can have different
storage sizes. To prevent issues, callback functions are still declared
as returning`int`. To at least make things easier to understand for
humans, I marked those with `int /*eContextResult*/`.
This is a followup of D9090, and is intended to unify how context
callbacks return values. This will make it easier to extend the approach
in D9090 to those functions.
No functional changes.
Differential Revision: https://developer.blender.org/D9095
Using context overrides in Python caused problems for any operator that
changed the context and require these changes to be read back.
CTX_wm_area_set() for e.g. would set the struct member but future
calls to CTX_wm_area() would still return the value defined by Python
callers context overrides.
This also resolves a mismatch between polling and calling operators
from Python, where poll would override the Python context where calling
only overrode the context when a new context was passed in.
Split the depsgraph allocation into a separate function
`BKE_scene_ensure_depsgraph()`. Parameters are only passed to those
functions that actually need them. This removes the the "if that boolean
is `false` this pointer is allowed to be `NULL`" logic and more cleanly
decouples code.
No functional changes.
When the playhead drawing moved to an overlay, a check was added to keep
it from drawing with a locked interface. This is necessary for some overlays,
but not this one, so this removes the check, making it the responsibility of
the editor.
A context function is added to make that check easier in the future.
Differential Revision: https://developer.blender.org/D8313
Follow up of b2ee1770d4 and 10c2254d41, part of T74432.
Now the area and region naming conventions should be less confusing.
Mostly a careful batch rename but had to do few smaller fixes.
Also ran clang-format on affected files.
This commit is a full refactor of the grease pencil modules including Draw Engine, Modifiers, VFX, depsgraph update, improvements in operators and conversion of Sculpt and Weight paint tools to real brushes.
Also, a huge code cleanup has been done at all levels.
Thanks to @fclem for his work and yo @pepeland and @mendio for the testing and help in the development.
Differential Revision: https://developer.blender.org/D6293
The old convention was easy to confuse with ScrArea.
Part of https://developer.blender.org/T74432.
This is mostly a batch rename with some manual fixing. Only single word
variable names are changed, no prefixed/suffixed names.
Brecht van Lommel and Campbell Barton both gave me a green light for
this convention change.
Also ran clan clang format on affected files.
Rigify uses a property group to contain options of its rigs, so
currently it is impossible to use Alt-Click or Copy To Selected
to change a setting for multiple rigs at the same time.
The main problem here is that there is no efficient way to find
which bone the property group belongs to. To maintain performance,
implement this by checking the active bone if it is known. Copy
Data Path and related features still don't work, as data path
calculation can't use context.
Differential Revision: https://developer.blender.org/D6264
Currently unused, but will allow to keep of an owner of the depsgraph.
Could also simplify other APIs in the future by avoiding to pass bmain
explicitly to relation update functions and things like that.
This change ensures that operators which needs access to evaluated data
first makes sure there is a dependency graph.
Other accesses to the dependency graph made it more explicit about
whether they just need a valid dependency graph pointer or whether they
expect the graph to be already evaluated.
This replaces OPTYPE_USE_EVAL_DATA which is now removed.
Some general rules about usage of accessors:
- Drawing is expected to happen from a fully evaluated dependency graph.
There is now a function to access it, which will in the future control
that dependency graph is actually evaluated.
This check is not yet done because there are some things to be taken
care about first: for example, post-update hooks might leave scene in
a state where something is still tagged for update.
- All operators which needs to access evaluated state must use
CTX_data_ensure_evaluated_depsgraph().
This function replaces OPTYPE_USE_EVAL_DATA.
The call is generally to be done in the very beginning of the
operator, prior other logic (unless this is some comprehensive
operator which might or might not need access to an evaluated state).
This call is never to be used from a loop.
If some utility function requires evaluated state of dependency graph
the graph is to be passed as an explicit argument. This way it is
clear that no evaluation happens in a loop or something like this.
- All cases which needs to know dependency graph pointer, but which
doesn't want to actually evaluate it can use old-style function
CTX_data_depsgraph_pointer(), assuming that underlying code will
ensure dependency graph is evaluated prior to accessing it.
- The new functions are replacing OPTYPE_USE_EVAL_DATA, so now it is
explicit and local about where dependency graph is being ensured.
This commit also contains some fixes of wrong usage of evaluation
functions on original objects. Ideally should be split out, but in
reality with all the APIs being renamed is quite tricky.
Fixes T67454: Blender crash on rapid undo and select
Speculation here is that sometimes undo and selection operators are
sometimes handled in the same event loop iteration, which leaves
non-evaluated dependency graph.
Fixes T67973: Crash on Fix Deforms operator
Fixes T67902: Crash when undo a loop cut
Reviewers: brecht
Reviewed By: brecht
Subscribers: lichtwerk
Maniphest Tasks: T67454
Differential Revision: https://developer.blender.org/D5343
We are not exposing RNA_ObjectBase in the 2.80 API.
Thus we can't have operators relying on it (e.g, CTX_data_visible_bases,
CTX_data_active_base, ...). Otherwise users won't be able to override
context for these operators.
This commit keep the CTX_data_.*bases() functions around so we don't
need to change the operators and potentially break things that late into
2.80. However as far as the Python scripters are concerned there is no
base to be overriden, ever.
That also simplify the guessing game addon developers have to play when
trying to override an operatori context. They still need to find whether an
operator requires editables, visibles, selected, ... objects. But at
least they don't need to find out whether the operators need base or
object.
Main goal here is to make it obvious and predictable about
what is going on.
Summary of changes.
- Access to dependency graph is now only possible to a fully evaluated
graph. This is now done via context.evaluated_depsgraph_get().
The call will ensure both relations and datablocks are updated.
This way we don't allow access to some known bad state of the graph,
and also making explicit that getting update dependency graph is not
cheap.
- Access to evaluated ID is now possible via id.evaluated_get().
It was already possible to get evaluated ID via dependency graph,
but that was a bit confusing why access to original is done via ID
and to evaluated via depsgraph.
If datablock is not covered by dependency graph it will be returned
as-is.
- Similarly, request for original from an ID which is not evaluated
will return ID as-is.
- Removed scene.update().
This is very expensive to update all the view layers.
- Added depsgraph.update().
Now when temporary changes to objects are to be done, this is to
happen on original object and then dependency graph is to be
updated.
- Changed object.to_mesh() to behave the following way:
* When is used for original object modifiers are ignored.
For meshes this acts similar to mesh-copy, not very useful but
allows to keep code paths similar (i.e. for exporter which has
Apply Modifiers option it's only matter choosing between original
and evaluated object, the to_mesh() part can stay the same).
For curves this gives a mesh which is constructed from displist
without taking own modifiers and modifiers of bevel/taper objects
into account.
For metaballs this gives empty mesh.
Polygonization of metaball is not possible from a single object.
* When is used for evaluated object modifiers are always applied.
In fact, no evaluation is happening, the mesh is either copied
as-is, or constructed from current state of curve cache.
Arguments to apply modifiers and calculate original coordinates (ORCO,
aka undeformed coordinates) are removed. The ORCO is to be calculated
as part of dependency graph evaluation.
File used to regression-test (a packed Python script into .blend):
{F7033464}
Patch to make addons tests to pass:
{F7033466}
NOTE: I've included changes to FBX exporter, and those are addressing
report T63689.
NOTE: All the enabled-by-default addons are to be ported still, but
first want to have agreement on this part of changes.
NOTE: Also need to work on documentation for Python API, but, again,
better be done after having agreement on this work.
Reviewers: brecht, campbellbarton, mont29
Differential Revision: https://developer.blender.org/D4834
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
For now only `selected_pose_bones_from_active_object`, more options can
be added on demand.
Discussed this with Campbell Barton. We may need this only for selected
pose bones, time will tell.
This commit merge the full development done in greasepencil-object branch and include mainly the following features.
- New grease pencil object.
- New drawing engine.
- New grease pencil modes Draw/Sculpt/Edit and Weight Paint.
- New brushes for grease pencil.
- New modifiers for grease pencil.
- New shaders FX.
- New material system (replace old palettes and colors).
- Split of annotations (old grease pencil) and new grease pencil object.
- UI adapted to blender 2.8.
You can get more info here:
https://code.blender.org/2017/12/drawing-2d-animation-in-blender-2-8/https://code.blender.org/2018/07/grease-pencil-status-update/
This is the result of nearly two years of development and I want thanks firstly the other members of the grease pencil team: Daniel M. Lara, Matias Mendiola and Joshua Leung for their support, ideas and to keep working in the project all the time, without them this project had been impossible.
Also, I want thanks other Blender developers for their help, advices and to be there always to help me, and specially to Clément Foucault, Dalai Felinto, Pablo Vázquez and Campbell Barton.
