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
Mostly some minor renaming of parameters and variables, adding a few
comments...
The only actual behavior change is a more correct handling of the
`LIB_TAG_KEEP_ON_UNDO` on ID tag. This should not have any consequences
in current code though.
So no actual change in behavior is expected from this commit.
GCC documented FILENAME_MAX is the maximum length of a file that can
be opened, not to be used for allocation as it may be INT_MAX for e.g.
Even though this wasn't the case on supported systems,
prefer FILE_MAX which is used for full paths in most places.
The root of the issue was that while reading a new blendfile, the
current `G_MAIN` is still the old one, not the one in which new data is
being read.
Since the remapping callback taking care of UI data during ID remapping
is using `G_MAIN`, it is processing the wrong data, so when deleting the
invalid shapekey (from `BLO_main_validate_shapekeys`), the UI data of
the new bmain would not be properly remapped, causing invalid memory
access later when recomputing user counts (calls to
`BKE_main_id_refcount_recompute`).
This is fixed by adding a new `BKE_id_delete_ex` function that takes
extra remapping options parameter, and calling it from
`BLO_main_validate_shapekeys` with extra option to enforce handling of
UI data by remapping code.
NOTE: At some point we have to check if that whole UI-callback thing is
still needed, would be good to get rid of it and systematically process
UI-related ID pointers like any others. Current situation is... fragile
to say the least.
For realtime use cases, storing the geometry's state in memory at every
frame can be prohibitively expensive. This commit adds an option to
disable the caching, stored per object and accessible in the baking
panel. The default is still to enable caching.
Pull Request: https://projects.blender.org/blender/blender/pulls/107767
The new theme setting for the dope sheet (timeline) allows changing the
color of the bar that shows which frames are cached/baked. The
invalid/cached/baked status is differentiated by hardcoded transparency
values. In theory, those could be separate theme settings though.
Pull Request: https://projects.blender.org/blender/blender/pulls/107738
In some cases strips may end up with speed factor of 0 which causes
offsets and position to be invalid. The exact cause is unknown, but
most likely caused by `do_versions_sequencer_init_retiming_tool_data()`.
This could possibly happen if 3.6 file is saved with 3.5 version and
then opened again with 3.6 version.
To fix strips, retiming data is removed, start offset reset and speed
factor is set to 1. Previous versioning code is fixed, so speed factor
is never set to 0.
Pull Request: https://projects.blender.org/blender/blender/pulls/107798
This was added temporarily during development.
Loading files created in the geometry-nodes-simulation branch (3.5.4
and older) will remove links from simulation zones, which need to be
added back manually.
Pull Request: https://projects.blender.org/blender/blender/pulls/107781
When resyncing linked liboverride data, new IDs may be created that do
not exist in actual library file (since the lib file has not been resynced).
If such 'virtual linked liboverrides' data-blocks are used locally (e.g.
by adding such object to a local collection), on next file read they will be
detected as missing.
Now resync code will list such missing linked IDs that were
liboverrides, and try to re-use them when matching (by root name and
library) with newly generated virtual liboverrides.
The process may not be 100% perfect, especially a perfect one-to-one
remapping cannot be ensured if source data keep being changed over and
over (because of the order in which virtual linked liboverrides
generated by resync may change over time). However, in practice this
should fix the vast majority of issues, especially if sane naming
practices are used on IDs.
---------------
For the record, an attempt was made to write liboverride data together
with the placeholders for linked IDs in .blendfile. In theory, this
should ensure a perfect and fully valid re-usage of such IDs.
However, for this to work, not only the liboverride data of linked IDs need
to be written on disk, but also all ID references in this data has to be
considered as directly linked, to ensure that such liboverride data can
be re-read properly.
Otherwise, these placeholders would get a liboverride data with NULL ID
pointers, which is useless.
Such change feels way to intrusive for the very limited benefit, so for
now would consider current solution as the best option.
Pull Request: https://projects.blender.org/blender/blender/pulls/107144
This adds support for building simulations with geometry nodes. A new
`Simulation Input` and `Simulation Output` node allow maintaining a
simulation state across multiple frames. Together these two nodes form
a `simulation zone` which contains all the nodes that update the simulation
state from one frame to the next.
A new simulation zone can be added via the menu
(`Simulation > Simulation Zone`) or with the node add search.
The simulation state contains a geometry by default. However, it is possible
to add multiple geometry sockets as well as other socket types. Currently,
field inputs are evaluated and stored for the preceding geometry socket in
the order that the sockets are shown. Simulation state items can be added
by linking one of the empty sockets to something else. In the sidebar, there
is a new panel that allows adding, removing and reordering these sockets.
The simulation nodes behave as follows:
* On the first frame, the inputs of the `Simulation Input` node are evaluated
to initialize the simulation state. In later frames these sockets are not
evaluated anymore. The `Delta Time` at the first frame is zero, but the
simulation zone is still evaluated.
* On every next frame, the `Simulation Input` node outputs the simulation
state of the previous frame. Nodes in the simulation zone can edit that
data in arbitrary ways, also taking into account the `Delta Time`. The new
simulation state has to be passed to the `Simulation Output` node where it
is cached and forwarded.
* On a frame that is already cached or baked, the nodes in the simulation
zone are not evaluated, because the `Simulation Output` node can return
the previously cached data directly.
It is not allowed to connect sockets from inside the simulation zone to the
outside without going through the `Simulation Output` node. This is a necessary
restriction to make caching and sub-frame interpolation work. Links can go into
the simulation zone without problems though.
Anonymous attributes are not propagated by the simulation nodes unless they
are explicitly stored in the simulation state. This is unfortunate, but
currently there is no practical and reliable alternative. The core problem
is detecting which anonymous attributes will be required for the simulation
and afterwards. While we can detect this for the current evaluation, we can't
look into the future in time to see what data will be necessary. We intend to
make it easier to explicitly pass data through a simulation in the future,
even if the simulation is in a nested node group.
There is a new `Simulation Nodes` panel in the physics tab in the properties
editor. It allows baking all simulation zones on the selected objects. The
baking options are intentially kept at a minimum for this MVP. More features
for simulation baking as well as baking in general can be expected to be added
separately.
All baked data is stored on disk in a folder next to the .blend file. #106937
describes how baking is implemented in more detail. Volumes can not be baked
yet and materials are lost during baking for now. Packing the baked data into
the .blend file is not yet supported.
The timeline indicates which frames are currently cached, baked or cached but
invalidated by user-changes.
Simulation input and output nodes are internally linked together by their
`bNode.identifier` which stays the same even if the node name changes. They
are generally added and removed together. However, there are still cases where
"dangling" simulation nodes can be created currently. Those generally don't
cause harm, but would be nice to avoid this in more cases in the future.
Co-authored-by: Hans Goudey <h.goudey@me.com>
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/104924
- Rename name/filename/path to filepath when it's used for full paths.
- Rename name/path to dirpath when it refers to a directory.
- Rename file to filepath or path (when it may be a file or dir).
- Rename ImBuf::name & anim::name to filepath.
This change is required for 0001485365. File version bump was included
in PR but it was behind the main branch. In main, version was updated
by 5d0595fded.
Modifier name is being displayed as label in panel header which has restricted
the editing of it. This PR will allow to change the name of F-curve modifier
by exposing string property "name"
Included versioning code for modifier name. This will add suffix to the name if
multiple instances of same modifier exists in modifier stack.
Differential Revision: https://archive.blender.org/developer/D17142
Pull Request: https://projects.blender.org/blender/blender/pulls/104949
In some cases comments at the end of control statements were wrapped
onto new lines which made it read as if they applied to the next line
instead of the (now) previous line.
Relocate comments to the previous line or in some cases the end of the
line (before the brace) to avoid confusion.
Note that in quite a few cases these blocks didn't read well
even before MultiLine was used as comments after the brace caused
wrapping across multiple lines in a way that didn't follow
formatting used everywhere else.
BKE_image_ensure_tile_token took only the file name component but used
FILE_MAX to limit the input buffer.
Split this function in two, one that takes the full path as this is the
most common usage and another which takes only the filename.
Both now take a string size argument.
This option is true by default, but it can be changed for
any asset library (that may be using Link as import method).
This also fix "Reset to Default Value" for the Import Method
since this was originally not using the defaults.
Pull Request: https://projects.blender.org/blender/blender/pulls/107345
Fix#107297: Crash on undoing "Use Nodes" step.
Fix (unreported) crash on undoing certain type of data deletion (like
collections) in some specific cases.
Main serious issues were in new handling of embedded IDs in ID swap code
(#107297), and in general in lib_query remapping code from
`BKE_lib_id_swap_full` in readfile code in undo case which could access
other IDs data, when it is not guaranteed to be valid at this point in
code.
Added an option flag to lib_query code to forbid access to the original
ID pointers in such cases.
Keep these operations separate to simplify path handling logic & docs.
Many callers passed NULL and there were times paths were passed in which
didn't make any sense (where the paths had already been made absolute).
This patch adds several tools and options to the weight paint mode of Grease Pencil.
* Blur tool: smooths out vertex weights, by calculating a gaussian blur of adjacent vertices.
* Average tool: painting the average weight from all weights under the brush.
* Smear tool: smudges weights by grabbing the weights under the brush and 'dragging' them.
* With the + and - icons in the toolbar, the user can easily switch between adding and subtracting weight while drawing weights.
* With shortcut `D` you can toggle between these two.
* The auto-normalize options ensures that all bone-deforming vertex groups add up to 1.0 while weight painting.
* With `Ctrl-F` a radial control for weight is invoked (in addition to the radial controls for brush size and strength).
* With `Ctrl-RMB` the user can sample the weight. This sets the brush Weight from the weight under the cursor.
* When painting weights in vertex groups for bones, the user can quickly switch to another vertex group by clicking on a bone with `Ctrl-LMB`.
For this to work, follow these steps:
* Select the armature and switch to Pose Mode.
* Select your Grease Pencil object and switch immediately to Weight Paint Mode.
* Select a bone in the armature with `Ctrl-LMB`. The corresponding vertex group is automatically activated.
Pull Request: https://projects.blender.org/blender/blender/pulls/106663
While embedded IDs are usually considered as private local data of their
owner ID, some areas of code, like the depsgraph, can consider them as
regular IDs in some aspects.
So when swapping IDs, also properly 'counter-swap' their potential
embedded IDs, such that the pointers to the embedded IDs remain as before
swapping, even though the data of the embedded IDs is swapped.
The main target of this change is memfile undo code. There, newly read
IDs are swapped with their oldder version, so that the old address
contains the new data. This allows to avoid rebuilding some of the
depsgraph. Doing the same thing for embedded IDs should reduce even
further the needs for depsgrah rebuilds on undo steps.
This commit also gives more control over the remapping of 'self' ID
pointers inside themselves.
Pull Request: https://projects.blender.org/blender/blender/pulls/107044
Do not read IDs from types flagged as 'no undo', whether they are local
or linked.
This should have no effect currently, since all 'no undo' ID types
currently are supposedly only local data anyways (Screen, WindowManager
and WorkSpace).
These IDs kept their address, but their content has been replaced
(re-read from the memfile undo step). Add an ID tag to identify them.
As a further cleanup, systematically tag these IDs for despgraph COW,
since their data is effectively modified (though in practice all of
these IDs are expected to already have other update tags anyway).
No change in behavior is expected from this commit.
Implements #95966, as the final step of #95965.
This commit changes the storage of mesh edge vertex indices from the
`MEdge` type to the generic `int2` attribute type. This follows the
general design for geometry and the attribute system, where the data
storage type and the usage semantics are separated.
The main benefit of the change is reduced memory usage-- the
requirements of storing mesh edges is reduced by 1/3. For example,
this saves 8MB on a 1 million vertex grid. This also gives performance
benefits to any memory-bound mesh processing algorithm that uses edges.
Another benefit is that all of the edge's vertex indices are
contiguous. In a few cases, it's helpful to process all of them as
`Span<int>` rather than `Span<int2>`. Similarly, the type is more
likely to match a generic format used by a library, or code that
shouldn't know about specific Blender `Mesh` types.
Various Notes:
- The `.edge_verts` name is used to reflect a mapping between domains,
similar to `.corner_verts`, etc. The period means that it the data
shouldn't change arbitrarily by the user or procedural operations.
- `edge[0]` is now used instead of `edge.v1`
- Signed integers are used instead of unsigned to reduce the mixing
of signed-ness, which can be error prone.
- All of the previously used core mesh data types (`MVert`, `MEdge`,
`MLoop`, `MPoly` are now deprecated. Only generic types are used).
- The `vec2i` DNA type is used in the few C files where necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/106638
Re-organize ID tags in a more logical way, and keep their values
strictly increasing, splitting the free available ones in-between the
main groups (to avoid having to edit all tags values when adding a new
one).
Note that shuffling around these ID tags values should not be an issue
anymore, all of these are strictly run-time, and fully cleared in write
code when writing into a .blend file.
This also lead to the second cleanup, which is removing some asserts on
ID tag values in readcode, these are useless since the tag is cleared on
write.
Embedded IDs did not benefit from any of the recent optimizations
(especially for undo case) when writing regular IDs (cleaning up of some
pure runtime data that would generate a lot of fake 'changed on undo'
status).
Now factor out of `write_file_handle` this part of the code generating
temp ID copy with cleaned-up data for writing, and expose it in BLO API
such that IDs owning embedded ones can also use it.
