| Age | Commit message (Collapse) | Author |
|---|
|
This introduces object mode tagging for data which hasn't yet been
written back to the ID data.
Now when selecting other sculpt objects, the original objects data is
flushed back to the ID before writing a memfile undo step.
|
|
The goal is to make it possible to access evaluated datablocks at a
corresponding context. For example, be able to check evaluated state
if an object used for rendering.
Allows to write scripts in a safe manner for T63548 and T60094.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D5726
|
|
Preparing for the bigger changes which will be related on passing
dependency graph to various callbacks which need it.
Differential Revision: https://developer.blender.org/D5725
|
|
When the result isn't used, prefer post increment/decrement
(already used nearly everywhere in Blender).
|
|
Tags all outliner sync types on undo and redo operations.
|
|
T68035 by @luzpaz
|
|
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
|
|
This is needed step out of undo steps which accumulate changes,
larger changes could be made to handle this but better not
make them at this point.
|
|
Print the undo stack on undo/redo when ed.undo logging is enabled.
|
|
Changing the brush size for example,
was adding redundant undo steps in paint-modes.
For now, don't store undo steps for property changes
in paint & edit modes.
While not ideal, this is similar to 2.7x behavior.
|
|
Undo history also missed updating the tool system and
calling undo pre/post handlers.
|
|
|
|
|
|
This reverts part of commit b7eba20236ca6499a62a8ee2b0c852086bc46b8e. Polling
is causing issues in scripts, and the minor usability improvements are not worth
the extra work this may cause at this point in the release cycle.
Fixes T65149
|
|
This patch updates the polling that enable/disables Edit Menu items. Slight Undo History menu changes
Differential Revision: https://developer.blender.org/D4846
Reviewed by Brecht Van Lommel
|
|
|
|
|
|
|
|
|
|
Apply clang format as proposed in T53211.
For details on usage and instructions for migrating branches
without conflicts, see:
https://wiki.blender.org/wiki/Tools/ClangFormat
|
|
Tested to work on Linux and macOS.
This will be enabled once all platforms are verified.
See D4684
|
|
No functional change, this adds LIB definition and args to cmake files.
Without this it's difficult to migrate away from 'BLENDER_SORTED_LIBS'
since there are many platforms/configurations that could break when
changing linking order.
Manually add and enable WITHOUT_SORTED_LIBS to try building
without sorted libs (currently fails since all variables are empty).
This check will eventually be removed.
See T46725.
|
|
While \file doesn't need an argument, it can't have another doxy
command after it.
|
|
Some developers were using undo for their scripts, this allows for undo
pushes in background mode, however - as with 2.7x, undo isn't
initialized at startup in background mode.
See replies to T60934
|
|
Objects leaving edit-mode weren't restored by edit-mode undo steps.
|
|
|
|
Move \ingroup onto same line to be more compact and
make it clear the file is in the group.
|
|
This complicated handling of undo steps in a generic way
especially switching between undo systems that stored data to ones
that accumulated changes.
Now each undo system must treat it's steps as check-point,
internally it can apply/rewind changes.
This commit also fixes projection paint where the object mode wasn't
following the undo steps.
|
|
Following removal from C source code.
See: 8c68ed6df16d8893
|
|
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.
|
|
Show an error instead of crashing, see: T60934
|
|
|
|
Needed since we don't always have the context,
and avoids adding G_MAIN into undo callbacks.
|
|
Does not make sense to keep that with BLO_writefile.h, this can also be
used by read code, and some other parts of Blender (like ed_undo.c
currently)...
|
|
Memfile undo isn't compatible with sculpt or edit-mode.
This didn't work in 2.7x, so best disable memfile undo for now in
situations where it's going to loose data or crash.
|
|
|
|
Exiting modes shouldn't be needed since loading the new memfile
will free the old data.
Sculpt mode dynamic topology was adding undo data on exiting the mode
which isn't logical in this case and can be avoided altogether.
|
|
Undo and redo post were actually calling respective pre funcs...
|
|
|
|
Also (mostly in comments): behaviour -> behavior (we use American English).
|
|
Part of T59335.
|
|
|
|
Using operators to the object mode was resetting the tool.
See: T56865
|
|
Conflicts:
source/blender/blenkernel/BKE_global.h
source/blender/editors/undo/ed_undo.c
|
|
There are serious suspicions that weird corruptions faced by studio
artists may happen in undo/redo code, so let's see whether that's the
case.
With this, and when --debug-io arg is passed on startup, the whole lib
data are checked at every undo. This makes undo slower (from two to
three times slower), but it could help us spot better what happens...
|
|
|
|
This causes a feedback loop in 2.8x,
where gizmo redo caused fake mousemove that executed gizmo again.
Move the mousemove into the undo/redo operator.
|
|
|
|
While the crash is in 2.8, it's possible undo operates on data
which isn't only owned by the current scene (any object for eg).
Thanks to @mont29 for suggesting the fix.
|
|
For now, that flag is only used in redo code, since after undo step
depsgraph is totally empty... We *may* want to add at least an assert in
op calling code too, though?
|
