This commit adds a new experimental node "Sample Volume".
It's purpose is to be able to sample values from a volume grid given
a position field.
The 'Grid' input accepts a named attribute input with the name
of the volume grid to sample. Values will be implicitly converted
from the grid type to the specified value type.
Pull Request: #107656
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.
Using the topology map gives a constant time lookup, since it has a map
of nodes per type. The collada code used the old function, but had been
ifdef'd for four years, so it's removed here.
Functions were moved as part of f7388e3be5, which was
unnecessarily noisy. Instead of reverting, move the definitions back
to their original place in node.cc. Also move a few more things to
the blender::bke namespace.
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
The issue was that in case an ID was only related to its liboverride
hierarchy through a 'to' pointer (e.g. the parent pointer of an object),
it would now be tagged as 'isolated' from its hierarchy, since nothing
in said hierarchy actually points to it. It would then be deleted during
resync process.
This is once again the infamous 'inverted dependency logic of object
parenting' case...
Note that this did not have any consequences on typical liboverride
usages (based on using a hierarchy of collections0, since all objects
would then be referenced by one or more collection.
Reported by @dr.sybren while investigating #102662.
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
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.
Making the custom data API const correct in 3a3d9488a1 caused
the issue, because it previously relied on non-threadsafe behavior. As a
workaround, just restore the thread-unsafety, and note the issue in a
new comment.
There was even one case in BLI ListBase tests!
Order was opposite of the one expected by the BLI ListBase code... Not
sure how, but this did not cause any issue apparently? But would expect
it to at least affect the order in which items in the list would be
iterated.
`BKE_library_id_can_use_filter_id` would not handle properly cases where
the ID is a liboverride - it's hierarchy root pointer can point back to
virtually any kind of ID (although typically a Collection or Object).
This was breaking liboverride resync process in some rare cases, by
failing to remap the 'hierarchy root' pointer of some liboverrides.
This makes the Blender binary 350 KB smaller. The largest change comes
from using `FunctionRef` instead of a template when gathering indices to
mix in the extrude node (which has no performance cost). The rest of the
change comes from consolidating uses of code generation for all
attribute types. This brings us a bit further in the direction of
unifying attribute propagation.
Pull Request: https://projects.blender.org/blender/blender/pulls/107823
Adds an input node Signed Distance that can
be used to refer to the distance-grid of an SDF volume.
Right now it's experimental and can be enabled by enabling
"New Volume Nodes" in the preferences.
It returns a float AttributeFieldInput called 'distance' which
can tell Volume nodes which grid to get.
See #103248.
LibOverride resync process would not properly 'make local' newly created
overrides (copied from their linked reference). The main consequence was
that some linked data used by these new liboverrides would not be
properly tagged as directly linked.
While this would not be an issue in current codebase, this was breaking
upcomming readfile undo refactor, since some linked data did not get
their local 'placeholder reference' data written in memfile blendfiles.
NOTE: this is more of a quick fix, whole handling of library data in
complex copying cases like that need some more general work, see #107848
and #107847.
Issue was that, when UI-related code _is_ requested in foreach_id
processing, `ID_SCR` screen ID type can actually use any kind of ID
(through e.g. the Outliner space).
So `BKE_library_id_can_use_filter_id` had to be updated with a new
parameter (whether UI-related data should be taken into account or not).
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
Caused by 2fb31f34af.
Since above commit, we are now calling `BKE_mesh_orco_verts_transform`
not only from `psys_face_mat` and `psys_mat_hair_to_orco`, but now also
from `psys_particle_on_dm` > `psys_interpolate_face`, so we get double
transforms with mirror.
Remove the "extra" call in `psys_mat_hair_to_orco`.
Should be backported to 3.3 LTS as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/107804
Avoid storing redundant and unnecessary data in temporary arrays during
face corner normal calculation with custom normals. Previously we used
96 bytes per normal space (`MLoopNorSpace` (64), `MLoopNorSpace *` (8),
`LinkData` (24)), now we use 36 (`CornerNormalSpace` (32), `int` (4)).
This is achieved with a few changes:
- Avoid sharing the data storage with the BMesh implementation
- Use indices to refer to normal fan spaces rather than pointers
- Only calculate indices of all corners in each fan when necessary
- Don't duplicate automatic normal in space storage
- Avoid storing redundant flags in space struct
Reducing memory usage gives a significant performance improvement in
my test files, which is consistent with findings from previous commits
(see 9fcfba4aae). In my test, the time used to calculate
normals for a character model with 196 thousand faces reduced from
20.2 ms to 14.0 ms, a 44% improvement.
Edit mode isn't affected by this change.
A note about the `reverse_index_array` function added here: this is the
same as the mesh mapping functions (for example for mapping from
vertices to face corners). I'm planning on working this area and hoping
to generalize/reuse the implementation in the near future.
Pull Request: https://projects.blender.org/blender/blender/pulls/107592
looptris were referred to as both tris & faces, sometimes polygons
were referred to as faces too. Was especially error prone with
callbacks that took both a tri and a tri_i arguments.
Sometimes tri_i represented a looptri index, other times the corner of
the triangle from 0-2. Causing expressions such as:
`args->mlooptri[tri].tri[tri_i]`
- Rename tri & tri_index -> looptri_i.
- Rename faces -> looptris.
- Rename face_index/poly_index/poly -> poly_i.
- Declare looptri_i at the start of the loop and reuse it,
in some cases it was declared with args->prim_indices[i] being
used as well.
Change PBVH normal calculation to also update vertices connected to
vertices with an update tag. This is necessary because vertex normals
are the mixed face normals, so changing any face's normal will change
the normals of all connected faces.
This change requires that the PBVH always have a vertex to face
topology map available. In the future this will likely be cached on
meshes though, which will reduce the delay it adds when entering sculpt
mode.
Now, first all face normals are updated, then the normals for
connected vertices are mixed from the face normals. This is a
significant simplification to the whole process, which previously
worked with atomics and normals at the triangle level. Similar changes
changes for regular non-sculpt normal calculation are being worked on
in #105920.
Pull Request: https://projects.blender.org/blender/blender/pulls/107458
The pose library blending code assumed that quaternions would be keyed
in order of `array_index`. This is normally the case when creating a
pose asset, but when manually editing a pose asset Action this
assumption may not hold.
The code still assumes that all FCurves of a single quaternion are
sequential, i.e. are not inter-mixed with other keyed properties. They
just no longer have to be ordered by array index.
Ref: blender-addons/issues#104591
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
Fixes crashes in timeline and spreadsheet editors during simulation
nodes baking:
* Timeline tries to access the `states_at_frames_` list of the cache to
determine which frames to draw as baked. This can collide with the
baking thread. Needs a mutex to safely access the cache state.
Note: the old point cache has a pre-allocated flag array
`cached_frames` which the baking thread writes into while timeline is
reading it concurrently - not thread-safe but harmless.
* Spreadsheet keeps a data pointer during drawing, which may become
deallocated when the cache is updated. Common approach here is to use
`G.is_rendering` to lock the editor while baking.
Pull Request: https://projects.blender.org/blender/blender/pulls/107621
