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
Remove the assumption that quaternions are always fully keyed in a pose
asset. Even though quaternions really should be fully keyed, better not
make Blender crash when this assumption doesn't hold.
If the quaternion is only partially keyed, the other components are taken
to be from the unit quaternion (`[1, 0, 0, 0]`) and the result is
normalized before blending into the existing pose.
This fixesblender/blender-addons#104591, which was reported against the
pose library add-on, but actually was caused by an issue in Blender.
- The official spelling of FFMPEG is FFmpeg (upper, then lower case).
- The normal vector copy and paste operators shoud be singular because
they can only be used on a single element.
- The "Parent File" file browser operator goes up one level in the
file hierarchy. It should be called "Parent Directory", like the
current description "Go to the parent directory".
- "Mass Vertex Group" used to define the mass, but was reused at some
point and now actually defines cloth pinning so it should be called
"Pin Vertex Group", as in the UI.
- The Transformation constraint's Map To Type suffered from a
typo (probably of -> on).
- "Fall-off" is more commonly spelled "Falloff".
- "Effected" should really be "Affected" in this case.
- Rephrase the descriptions for the curve painting tools drawing
plane, which did not seem to match what the settings do. Namely,
they allow selecting in which plane to draw curves using the Curve
Draw tool.
Reported by @Joan-Pujolar in #43295:
- Force exporting animation on every objects [objects singular]
- Color of the interface widgets text insertion cursor (caret) [delete
interface widgets]
- Index of active aov [AOV in uppercase everywhere else]
- Does this tool use an painting canvas [an]
- This script was written Blender version %d.%d.%d ["for" missing
before "Blender"]
- [fcurve -> F-curve]
- unknown error stating file [statting]
- Offset into each stroke before the beginning of the dashed segment
generation [Two spaces between of and the]
- Find the nearest element in the a group. [either "the" or "a"]
Pull Request: https://projects.blender.org/blender/blender/pulls/107699
Only use the term len & maxlen when they represent the length & maximum
length of a string. Instead of the available bytes to use.
Also include the data they're referencing as a suffix, otherwise it's
not always clear what the length is in reference to.
This addresses the 'liboverrides still tagged for resync after resync
process' error reports.
Turns out, this situation is (unfortunately) normal in some rare cases,
hwne the hierarchies in the liboverride and the reference data have
drastically diverged.Since the detection of liboverrides to resync, and
which one are valid partial resync roots, happens on the 'old' override
hierarchy, it may not match the actual hierarchy recreated from the
reference data, leading to some part of it being ignored by the resync
code.
There is no real way to avoid this situation, the only thing that can be
done is detect it, and re-process the resync code again when it happens.
From quick limited tests in (extremely dirty/outdated) Pets production files,
most of the time only one resync process is needed. Worst case so far
required 5 reprocessing of the same set of data.
There is no error messages from resync anymore in these tests, so at the
very least resync process should now be significantly more reliable than
before...
This issue tackled here is essentially the same as in ac1ac6be9a
(recursive Purge of unused IDs could delete actually used IDs): handling
of dependency loops is extremely delicate...
This commit essentially rewrites from scratch the code that ensures that
all liboverrides and their dependencies that need it are tagged for resync,
and identifies the partial resync roots.
Dependency loops whitin a hierarchy make this process very complex, as
they can lead to having to recursively process more than once some IDs.
Partial resync roots are also a source of complexity, since some IDs may
be detected a potential roots, and later as dependencies of another
partial resync hierarchy.
This new code generates waaaaaayyyyy less error messages when resyncing
nightmare-like production files (i.e. production files which libraries
have been _heavily_ modified). There are still a few error reports in
some cases though, which are the synptoms of another issue that will be
fixed in the next commit.
While in practice this was probably not a big issue (since usually e.g.
objects used by a nodetree would also be used by other objects or
collections in the liboverride hierarchy), in some corner cases it could
have caused missing 'tag for resync' and improper partial resync roots
detection.
Previously accessing the extension needed to ensure an extension
on an empty path.
This conflicted with DEBUG_STRSIZE as it was assumed the input was
FILE_MAX, where as it was a small buffer with RNA, see: !107602.
Resolve by separating the function that ensures the extension
with the function that finds valid extensions for a format.
Also pass the size of the filepath to functions that ensure the
extension.
Erik Abrahamsson
Bastien Montagne
Chris Blackbourn
Iliya Katueshenock
Hans Goudey
Philipp Oeser
Jacques Lucke
Campbell Barton
Sybren A. Stüvel
Lukas Tönne
Lukas Stockner
Damien Picard
Joseph Eagar
Sergey Sharybin