This commit affects:
* Reading undo steps from memfile (aka 'Global Undo');
* Handling of UI IDs (WindowManager, Workspaces and Screens) when
opening a .blend file.
While no major changes are expected from a user PoV, there may be some
unexpected changes in rare edge-cases. None has been identified so far.
Undo step loading should be marginally faster (`setup_app_data` itself
is 2-3 times faster, as it does not do remapping anymore, which makes the
whole 'read undo step' process about 20% faster - but the most
time-consuming step on undo is the depsgraph processing, which remains
unchanged here).
This commit also solves some bugs (crashes) in some relatively uncommon
cases, like e.g. if the WM had an IDProperty pointing at an object and
UI is not loaded when opening a new .blend file with the 'Load UI' option
enabled (as in previous code on file opening WM ID would never be
remapped).
From a more technical side, this commit aims mainly at cleaning things
up, in preparation for the introduction of new 'no undo, no readfile'
type of handling (as part of the Brush Assets project):
- Prevent WM code from doing (too much) horrible ID 'management' on
its WM when opening a new file. It used to remove current WM from
the Main database, store it in a temporary own list, and then free
it itself...
- Trying to make the complex logic behind WM handling on file reading a
bit more easy to follow, at least way more documented in code.
- Keep the handling of 'IDs being re-used from old Main' in a single
place, as much as possible:
-- Readfile code itself in undo case (because it's more efficient,
and undo case is in a way simpler than actual .blend file
reading case). The whole `blo_lib_link_restore` block of code
is also removed.
-- (Mostly) setup_app_data code in actual file reading case.
- Sanitize the usage of the 'libmap' in readfile code in undo case
(waaaaay too many pointers were added there, which was hiding some
other issues in the related code, and potentially causing (in
rare cases) memory addresses collisions.
Pull Request: https://projects.blender.org/blender/blender/pulls/108016
Because of how the Clip Editor managed region state for different view
modes before region polls were introduced (fa0f295b53), regions could be
written to files in a state that's not valid for displaying them. State
for clip editors written to files is corrected with versioning now.
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
2a56403cb0 changed the way bevel weights are stored in 4.0.
Add versioning for reading the new files that replaces the new generic
attributes with the old non-generic custom data layers. The code is
paranoid with lots fo checks I expect will typically not be necessary.
For emitter particle systems, these were never rendered anyways, Path is
kept for hair systems of course.
As a consequence, the new default for particle systems is:
- render as None (users have to explicitly set this to object/
collection)
- display as point
When changing to Hair type, this automatically gets set back to
- render as Path
- display as Render
Changing back to emitter, will use points as display again (and render
as None -- same here, users have to explicitly set this to object/
collection)
Not sure if this is still for 3.6, patch is for 4.0 for now.
"Fixes" #80197
Pull Request: https://projects.blender.org/blender/blender/pulls/108231
Adds the initial stage for the grease pencil 3.0 project.
This patch includes:
* New ID and new object type.
* New DNA structures.
* New drawing engine for grease pencil (gpencil-next).
* Tests for the new grease pencil data-type.
* A few operators for conversion, switching modes and (simple) drawing.
Exposed to the user:
* An experimental option to switch to the new grease pencil.
* This will switch the grease pencil render engine to gpencil-next which can only render the new object type.
Current grease pencil objects will no longer render.
* Changing this option currently requires a restart of blender (for the keymap to update).
* A conversion setting in the `Object` > `Convert To` operator.
* A drawing operator in `Draw Mode`.
Pull Request: https://projects.blender.org/blender/blender/pulls/106848
The in-line ends-with check could read before the string began, as it
happens this wouldn't have caused problem (based on the memory layout),
nevertheless, out of bounds buffer access is best avoided.
In readfile code, when looking up for an already existing Library ID
based on the filepath, the logic handling said file path was wrong.
NOTE: This probably does not have any effect in practice, but better be
safe than sorry.
Found while investigating issues when opening
`lib/tests/libraries_and_linking/libraries/main_scene.blend`.
Windows file associations using ProgID, needed because of the launcher.
This fixes "pin to taskbar" and Recent Documents lists, allow per-
version jump lists and an "Open with" list with multiple versions.
Pull Request: https://projects.blender.org/blender/blender/pulls/107013
The main issue was the fact that if a Scene is overridden, it's content
will be fully invalidated when updating the liboverride at the end of
the file reading process. Since the FileData keeps a pointer to the
active view layer, it needs to be udated then.
As a side consequence, the liblinking of global data also needs to
happen before liboverrides are updated.
This adds `char *simulation_bake_directory` to the nodes modifier. The path is automatically generated the first time the modifier is baked. It is _not_ automatically changed afterwards. The path is relative to the .blend file by default. For now, the path is not exposed in the UI or Python API.
This fixes issues where renaming objects/modifiers can cause the baked data to not work anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/108201
Mark `NlaStrip.frame_{start,end}` and `NlaStrip.frame_{start,end}_ui` as
to-be-ignored for the library override system, and add a new set of RNA
properties `frame_{start,end}_raw` that the library override system can
use.
Versioning code ensures that overrides on `frame_{start,end}` are
altered to be applied to the `..._raw` counterpart instead.
The override system uses RNA to update properties one-by-one, and the
RNA code trying its best to keep things consistent / valid. This is very
much desired behaviour while a human is editing the data.
However, when the library override system is doing this, it is not
replaying the individual steps (that each end in a valid configuration),
but just setting each property one by one. As a result, the intermediate
state can be invalid (for example moving one strip into another) even
when the end result is perfectly fine.
This is what the `..._raw` properties do -- they set the values without
doing any validation, so they allow the library overrides system to move
strips around.
This assumes that the result of the override is still valid. Logic to
detect invalid situations, and reshuffle the NLA strips if necessary, is
left for a future commit as it is related to #107990 (NLA Vertical
Reorder).
Additionally, this commit adds functions
`BKE_lib_override_library_property_rna_path_change()` and
`BKE_lib_override_library_property_search_and_delete()` to the library
override API. The former is used to change RNA paths of property
overrides, and the latter is used to remove a property override
identified by its RNA path.
Store bevel weights in two new named float attributes:
- `bevel_weight_vert`
- `bevel_weight_edge`
These attributes are naming conventions. Blender doesn't enforce
their data type or domain at all, but some editing features and
modifiers use the hard-coded name. Eventually those tools should
become more generic, but this is a simple change to allow more
flexibility in the meantime.
The largest user-visible changes are that the attributes populate the
attribute list, and are propagated by geometry nodes. The method of
removing this data is now the attribute list as well.
This is a breaking change. Forward compatibility is not preserved, and
the vertex and edge `bevel_weight` properties are removed. Python API
users are expected to use the attribute API to get and set the values.
Fixes#106949
Pull Request: https://projects.blender.org/blender/blender/pulls/108023
Used to be https://archive.blender.org/developer/D17123.
Internally these are already using the same code path anyways, there's no point in maintaining two distinct nodes.
The obvious approach would be to add Anisotropy controls to the Glossy BSDF node and remove the Anisotropic BSDF node. However, that would break forward compability, since older Blender versions don't know how to handle the Anisotropy input on the Glossy BSDF node.
Therefore, this commit technically removes the Glossy BSDF node, uses versioning to replace them with an Anisotropic BSDF node, and renames that node to "Glossy BSDF".
That way, when you open a new file in an older version, all the nodes show up as Anisotropic BSDF nodes and render correctly.
This is a bit ugly internally since we need to preserve the old `idname` which now no longer matches the UI name, but that's not too bad.
Also removes the "Sharp" distribution option and replaces it with GGX, sets Roughness to zero and disconnects any input to the Roughness socket.
Pull Request: https://projects.blender.org/blender/blender/pulls/104445
Since 44e4f077a9 and related commits, geometry nodes doesn't
try to hide the difference between real geometry data and instances from
the user. Other nodes were updated to only support real geometry, but
the "Mesh Boolean" node was never updated and still implicitly gathered
all the instances. This commit removes the special instance behavior in the
boolean node and adds realize instances nodes to keep existing behavior
in most cases. Typically this doesn't make a difference in the result,
though it could in the union mode for instance inputs. Shifting more of
the work to realizing instances should generally be better for
performance, since it's much faster.
Finish the transition from #95966 and fe38715600 by
writing files with the new format for meshes and some movie clip fields.
This removes overhead when saving files, and makes meshes saved in
files smaller (a file with a 1 million face grid changed from 32 to 28 MB).
3.6 can still read files saved with this format, but older versions will
crash. Older files are automatically converted by versioning code when
opened.
This also allows removing all the code that converts from the new
format to the legacy format, previously used when saving files.
Pull Request: https://projects.blender.org/blender/blender/pulls/108015
The usage of the lib pointer was cryptic to say the least, it was
essentialy used to allow or not local IDs results in the mapping
old_id_pointer -> new_id_pointer lookup result.
Now:
- Explicitely pass a boolean to allow or not local ID as result in
lower-level code.
- Pass the 'self ID' pointer instead of its library to the whole
liblinking code (that was already the case in a few places).
Note that naming of the 'self id' pointer is currently very inconsistent
throughout the readfile liblink code, this will have to be cleaned up in
a separate step later. For now, `self_id` has been chosen for new code
as it matches the terminology in lib_query code.
The later change can also allow finer handling of lookup on undo, based
on how it was re-read (or not), should the need for this arise.
Internal private struct was using `owner_id`/`self_id`, while the public
callback data struct was using `id_owner`/`id_self`.
Now using internal naming everywhere in lib_query related code, as
`owner_id` is already used in very low-level 'fundamental' part of the
code, e.g. in the `PointerRNA` struct, or in ID's 'loopback' pointers
for embedded data.
Note that this is only a very small first step toward proper naming
consistency for these type of data, the mismatch is currently spread all
over the code base.
We also need to document more formally the meaning and differences
between `self` and `owner` here.
Since a generic snap cursor was implemented (which can be used by Tools and by DragDrop), the Placement Settings are no longer a settings of the "VIEW3D_OT_interactive_add" Operator.
With that implementation, those properties started to be defined in a
static struct, filled in at runtime and accessed in the UI through
workarrounds.
As they are properties initialized at runtime, they are not saved in
the file.
The solution is to move the Placement Settings to `ToolSettings`.
Co-authored-by: Germano Cavalcante <germano.costa@ig.com.br>
Pull Request: https://projects.blender.org/blender/blender/pulls/107951
Include the term "overwrite" so users of this function are aware
this function will delete the destination file (unlike LIBC rename).
- Add BLI_rename_overwrite (previously called BLI_rename).
- BLI_rename is now a wrapper for rename.
Use BLI_rename when renaming in the file selector.
See: https://projects.blender.org/blender/blender/issues/103343
Changes:
1. Added `BKE_node.hh` file. New file includes old one.
2. Functions moved to new file. Redundant `(void)`, `struct` are removed.
3. All cpp includes replaced from `.h` on `.hh`.
4. Everything in `BKE_node.hh` is on `blender::bke` namespace.
5. All implementation functions moved in namespace.
6. Function names (`BKE_node_*`) changed to `blender::bke::node_*`.
7. `eNodeSizePreset` now is a class, with renamed items.
Pull Request: https://projects.blender.org/blender/blender/pulls/107790
Ensure the file path G.main->filepath is always absolute and normalized.
- It was possible to call WM_OT_open_mainfile with only a filename,
if this resolved from the CWD, Blender's internal filepath
would not be absolute as expected.
- It was possible to open files on UNIX with an additional forward slash
causing the blend file path it's self to contain a '//' prefix,
this is error prone as running BLI_path_abs(..) multiple times would
add the blend file prefix each time.
- Remove requirement for "filepath" to be an absolute path when saving.
Instead, expand the path - making it absolute, as this constraint
wasn't applied open opening files, prefer making save/open behave
consistently.
- Assert when BLI_path_abs/BLI_path_rel receive a basepath that has
a "//" (relative) prefix itself.
Add a new flag that determines whether root bones (i.e. bones without a
parent) should be translated to the armature object's origin. This can
be found in the Armature's IK properties panel.
By default this flag is disabled, so new rigs will not see this 'locking
to the origin' behaviour. Versioning code ensures that the flag is
enabled on older files, to preserve the behaviour of existing rigs.
This also bumps the Blender subversion and at the same time fixes an
incorrect bump in ee08b2ddff (where the
'minimum compatible version' was updated instead of the current Blender
version).
Pull request: https://projects.blender.org/blender/blender/pulls/107869
