Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
|
|
|
|
|
|
a Stroke.
Add code preserving scene's toolsettings accross undo.
IDPointers are dealt with special care, we try to keep existing ones for
some (like brushes) when possible.
Note that this covers ToolSettings, Brushes and Palettes currently.
I'm not especially happy about how this new code mixes with existing
'foreach_id' one, in particular in scene. But cannot think of a better,
more generic way to do it currently.
Maniphest Tasks: T71759
Differential Revision: https://developer.blender.org/D9311
|
|
memfile undos
This is essentially adding that new callback, and using it only for already
existing Scene's 3DCursor.
Note that the place where this is called has been moved again, after all
have been lib-linked, such that those callbacks may also work on ID pointers.
Maniphest Tasks: T71759
Differential Revision: https://developer.blender.org/D9237
|
|
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9349
|
|
|
|
|
|
Corrects incorrect usages of the word 'loose' when 'lose' was required.
Differential Revision: https://developer.blender.org/D9243
Reviewed by Campbell Barton
|
|
Follow our code style guide by using C-comments for text descriptions.
|
|
Better use higher-level code from common ID management when possible.
Helps to de-duplicate logic, and reduces outside usages of more
'dangerous' functions.
Note that we could get rid of many of those `BKE_<id_type>_add`
functions now, but on the other hand several of those take extra
parameters and perform additional actions, so think we can keep them all
for now as 'non-standard ID specific creation functions'.
|
|
No reasons to keep the new ID pointer as parameter here.
Part of T71219.
|
|
Along some other typos in comments or variable names.
|
|
Allows scripters to store additional information in the marker itself instead
of using work-around approach based on marker names and such.
Differential Revision: https://developer.blender.org/D8944
|
|
This commit renames the functions in "BKE_unit.h` to be consistent
with the naming in the rest of blenkernel.
bUnit_AsString -> BKE_unit_value_as_string_adaptive
bUnit_AsString2 -> BKE_unit_value_as_string
bUnit_ReplaceString -> BKE_unit_replace_string
bUnit_ApplyPreferredUnit -> BKE_unit_apply_preferred_unit
bUnit_ToUnitAltName -> BKE_unit_name_to_alt
bUnit_ClosestScalar -> BKE_unit_closest_scalar
bUnit_BaseScalar -> BKE_unit_base_scalar
bUnit_IsValid -> BKE_unit_is_valid
bUnit_GetSystem -> BKE_unit_system_get
bUnit_GetBaseUnit -> BKE_unit_base_get
bUnit_GetBaseUnitOfType -> BKE_unit_base_of_type_get
bUnit_GetName -> BKE_unit_name_get
bUnit_GetNameDisplay -> BKE_unit_display_name_get
bUnit_GetIdentifier -> BKE_unit_identifier_get
bUnit_GetScaler -> BKE_unit_scalar_get
bUnit_IsSuppressed -> BKE_unit_is_suppressed
Differential Revision: https://developer.blender.org/D8828
|
|
Based on the original patch by Vaishnav S (@padthai), this adds
support for temperature units. Initially supported units are Celsius,
Kelvin, and Fahrenheit.
The units aren't used anywhere with this commit. Those changes should
happen in separate patches by adding PROP_TEMPERATURE to RNA property
definitions. But it should be ensured that the various solvers and
simulations actually properly use real units.
The complexity of some of the changes comes from the fact that these
units have offsets from each other as well as coefficients. This also
makes the implementation in the current unit system troublesome.
For example, entering 0C evaluates correctly to 273K, but 0C + 0C
doubles that result, because each unit value is evaluated separately.
This is quite hard to solve in the general case with Blender's current
unit system, though, so it is not handled in this commit.
Differential Revision: https://developer.blender.org/D4401
|
|
Indices referencing other orientations were not being updated,
|
|
|
|
This is part of T76372.
It adds the `blend_write`, `blend_read_data`, `blend_read_lib`
and `blend_read_expand` which correspond to the various
steps when reading and writing .blend files.
Having these callbacks allows us to decentralize the blenloader
code a lot more. This has the affect that code related to any
specific ID type is less scattered.
Reviewers: mont29
Differential Revision: https://developer.blender.org/D8670
|
|
No functional changes expected.
|
|
|
|
Since stone age of lib_query, the code would iterate over the current
list of active sequences (from a meta strip e.g.), and not over the
whole list of those.
This is a critical issue as it means in some cases (editing a meta strip
typically), some ID pointers would be missed/ignored by this foreach
looper, which is now at the center of most of our ID management code.
This caused a bug here at the studio, leading to loss of all sound IDs
used by sound strips when editing and undoing inside a meta strip, since
ID refcounting would not happen properly on strips using sounds outside
the meta-strip context during file reading of the undo steps.
To be backported to 2.83.
Differential Revision: https://developer.blender.org/D8671
|
|
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.
|
|
Reduce nesting by flipping conditions and returning early. It's now much
clearer that it's actually a linear function (rather than a nested one).
No functional changes.
|
|
For the sanity checks to work we don't actually need to check other
scenes. So this function can be simplified so that it does not require
a `Main *`.
Mistake in 5cc08510e0a6.
|
|
Users may input an invalid scene/view-layer combination via Python. We
can easily detect that and fail gracefully.
Besides checking input parameters in RNA, also assert the
scene/view-layer combination is valid in lower level Depsgraph lookup
function (called by statistics query).
|
|
This mainly removes the bmain argument, which can be
retrieved from the graph itself.
Also, I removed some outdated/unnecessary comments.
Reviewers: sergey, sybren
Differential Revision: https://developer.blender.org/D8614
|
|
Reviewers: sergey, sybren
Differential Revision: https://developer.blender.org/D8611
|
|
Reviewers: sergey
Differential Revision: https://developer.blender.org/D8613
|
|
|
|
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/blenkernel` module.
No functional changes.
|
|
The abbreviation 'init' is brief, unambiguous and already used
in thousands of places, also initialize is often accidentally
written with British spelling.
|
|
Note that this behavior is enforced on user level for now, but on code
side it is controlled with a flag, which should make it easy to refine
that behavior if needed.
Only exception is when we duplicate a linked ID directly (then we assume
user wants a local deep-copy of that linked data, and we always also
duplicate linked sub-data-blocks).
Note that this commit also slightly refactor the handling of actions of
animdata, by simplifying `BKE_animdata_copy_id_action()` and adding an
explicit new `BKE_animdata_duplicate_id_action()` to be used during ID
duplication (deep copy).
This also allows us to get rid of the special case for liboverrides.
|
|
Caused by recent own refactor of cache presevation handling in readfile,
EEVEE's lightcache are weird birds that can also be saved in .blend
files, need a special handling for those 'persistent' caches...
|
|
|
|
Using 'name' for the full path of a file reads badly,
especially when id.name is used in related code.
|
|
Now that we have a uniform consistent behavior in all our ID duplicate
funtions, we can easily factorize it greatly. Code gets cleaner,
smaller, and less error-prone.
Note that ultimately, this duplicate/deep copy behavior could be added
as a callback of IDTypeInfo.
We could also rethink the duplicate flags (some data, even some obdata,
like Lattice, are not coverred currently).
And so on. But at least code should now be much more easily maintainable
and extendable.
|
|
Previously, object (and sub-data) actions would be controlled by the
user preferences flag, collections actions would never be duplicted, and
scenes actions were always duplicated...
Now they all follow the user preferences settings.
|
|
Main change from user side, besides that all pointers should now be
properly remapped to new IDs, is that linked objects are no longer
preserved when doing a full copy of scenes.
Will open a task to check whether we actually still want that behavior
(and re-code it in a more correct way then).
This is the main part of work done here, it aims at uniformizing and
sanitizing that 'deep copy' process for supported IDs (currently scenes,
collections and objects).
Note that there will be more follow up commits after that one, but this
should be the most risky and changing one.
|
|
It makes no sense to deep-copy a collection and not also copy its
children collections... Parameter was not used anymore anyway.
So now this duplicate function will always at least deep-duplicate all
of its children collections, recursively.
|
|
Followup to rB74ec37b70cbc8dc2, also missed a case in collection
deepcopy then.
|
|
Matches other similar cases for collection and object, and general
naming rule (copy is for generic ID copying, duplicate is for more
involved and poweful behaviors specific to an ID type).
|
|
This greatly simplifies and unifies logic.
Also addresses T77255: full scene copy will now use same preferences
parameters as object or collection duplicate to choose which data-blocks
to copy along.
|
|
|
|
|
|
Mix up with imapaint.paintcursor & imapaint.paint.paint_cursor
Remove imapaint.paintcursor since it wasn't used.
Also rename paint_cursor_start_explicit() to paint_cursor_start(),
removing the existing paint_cursor_start() since it took the paint
struct from the context, a value that's known by all callers.
|
|
|