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
The code checking whether old liboverrides which have been resynced into
new ones should be deleted was still assuming it was only working on
local liboverrides.
However, since recursive resync was implemented, this is not true
anymore, it can also handle resynced linked liboverrides.
This could have lead to missing deletion of some old linked liboverrides
after resyncing them.
This addresses an issue here at the Blender studio, where a root
collection of a set was removed by mistake from the set library .blend file.
Since all the other linked data (sub collections, actual objects etc.)
of the set were still available, the liboverride resync code went crazy
trying to resync all these scattered pieces of a set, finding new valid
root IDs for the hierarchies, and so on.
So from now on, do not attempt to resync anything that is part of a
liboverride hierarchy which root ID linked reference has gone missing.
`BKE_collection_object_cache_free` can be called from some points in
code (e.g. during ID remapping) where proper parenting relationships
between collections cannot be ensured.
Would be good to check if recursive cache cleanup is actually needed
from these points, it would almost certainly be better and safer to
instead tag parent collections as dirty too, but this will be for
another time.
For now, just add a NULL-check on the parent collection pointer.
This call should be recursive, only freeing cache of immediate parents
of the collection is not enough, the whole parenting chain needs to be
processed.
Make sure that function style, reinterpret_cast, and static_cast are
used for all type conversions, without of casting to void *. Some other
related minor changes: add temporal variables, lost space, asserts for
case to avoid type conversions by using `->id` way.
Pull Request: https://projects.blender.org/blender/blender/pulls/107097
This patch implements the Texture node for the realtime compositor. The
evaluation of the texture is not GPU accelerated, but is cached as a
form of temporary implementation since the Texture node is deprecated
and will be removed in the future. Furthermore, texture node evaluation
is not supported for now.
This patch also introduces the concept of an ID static cache, which
uses the DrawDataList mechanism to invalidate the cache as needed,
consequently, a DrawDataList was added to the Tex ID structure.
An improvement that should be implemented outside of this patch is to
implement support for proxy textures in results to avoid redundant
copies in the execute method of the texture node. This should be
straightforward bit will be implemented in a separate patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/107291
Fixes a warning on GCC 13 about `uint` being used in the declaration and
the proper enum type `eDupli_ID_Flags` being used in the definition for
`BKE_id_copy_for_duplicate`.
The coarse positions given to the evaluator are skipped if there are
vertices not attached to faces. Use the cache from 8e967cfeaf
to skip that topology query, or even to tell if there are no such vertices,
so we can skip a copy completely. I observed a 12x improvement for this
step, from 7.5 ms to 0.6 ms on a 1 million vertex grid.
Code was not handling properly the case where the new object that should
replace the old one in given collection is already in the collection. In
such case, remove the old object from the collection, but do not attempt
to add the new one again.
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.
Introduce `BKE_fcurve_deduplicate_keys()` to merge keys that are on the
same time, or within the time comparison threshold (1/100th of a frame).
When merging two consecutive keys, the last one 'wins' and determines
the final key *value*. The first key's *time* is retained, to ensure the
reference point for the next comparisons is stable. The only exception
here is when there is a key exactly on an integer frame number, in which
case that one is preferred.
The function is exposed in RNA as `fcurve.keyframe_points.deduplicate()`
This commit also introduces a new function `BKE_fcurve_bezt_shrink(fcu,
new_totvert);` that can reallocate the `bezt` array to ensure removed
keys no longer take up memory.
The RNA function `fcurve.update()` currently performs two steps, which
are now exposed to RNA as well, as `keyframe_points.sort()` and
`keyframe_points.handles_recalc()`. This is so that Python code can
sort, deduplicate, and then recalculate the handles only once (calling
`update` + `deduplicate` would do the latter twice).
In Blender 4.0 the deduplication will also be part of `fcurve.update()`,
see #107126.
Reviewed on https://projects.blender.org/blender/blender/pulls/107089
The `sort_time_fcurve()` function should be stable, i.e. not change the
relative order of keys that have the same X-coordinate. This is now
enforced by a unit test.
I want to build a new function that can deduplicate the keyframes after
sorting, for which it's important that the 'last key wins' to get reliable
results.
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).
- BLI_path_normalize ran BLI_path_abs on a path that had already
been made absolute.
- BLI_path_slash_ensure was called after BLI_path_normalize_dir
which already ensures a slash.
Avoid possible calculations of loose edges later on if the coarse mesh
doesn't have loose edges or vertices. We expect these counts to be
cached already since `BKE_subdiv_converter_init_for_mesh` calls
`verts_no_face()` and `loose_edges()` already.
Related commits:
- 63689e4756
- 8e967cfeaf
8e967cfeaf only meant to tag the "verts no face" cache
calculated eagerly if both loose edges and loose verts were already
calculated. Instead it caused the calculation of one of the caches.
Similar to the cache of loose edges added in 1ea169d90e,
cache the number of loose vertices and which are loose in a bit map.
This can save significant time when drawing large meshes in the
viewport, because recalculations can be avoided when the data doesn't
change, and because many geometry nodes set the loose geometry
caches eagerly when the meshes contain no loose elements.
There are two types of loose vertices:
1. Vertices not used by any edges or faces
`Mesh.loose_verts()`
2. Vertices not used by any faces (may be used by loose edges)
`Mesh.verts_no_face()`
Because both are used by Blender in various places, because the cost
is only a bit per vertex (or constant at best) and for design consistency,
we cache both types of loose elements. The bit maps will only be
allocated when they're actually used, but they are already accessed
in a few important places:
- Attribute domain interpolation
- Subdivision surface modifier
- Viewport drawing
Just skipping viewport drawing calculation after certain geometry
nodes setups can have a large impact. Here is the time taken by
viewport loose geometry extraction before and after the change:
- 4 million vertex grid node: 28 ms to 0 ms
- Large molecular nodes setup (curve to mesh node): 104 ms to 0 ms
- Realize instances with 1 million cubes: 131 ms to 0 ms
Pull Request: https://projects.blender.org/blender/blender/pulls/105567
The node outputs the index of the closest element to itself. See #102387
for the original design.
This is different from the Sample Nearest node in two important ways:
* It does not have a geometry input, instead the geometry is taken from the
field evaluation context.
* The node can exclude the "current" element from the search.
* The group id input can be used to build subsets of elements that only
consider each other as neighbors and ignore elements with other ids.
Pull Request: https://projects.blender.org/blender/blender/pulls/104619
An operator to allow interactive text selection for 3D Text Objects.
This is from the code of Yash Dabhade (yashdabhade) for GSoC 2022
with corrections and simplifications. Also includes double-click for
word selection.
Pull Request: https://projects.blender.org/blender/blender/pulls/106915
This patch contains changes needed for retiming sound strips.
`BKE_sound_set_scene_sound_pitch()` is replaced by
`BKE_sound_set_scene_sound_pitch_constant_range()` which uses new
Audaspace interface to set pitch in bulk.
This is done in `SEQ_retiming_sound_animation_data_set()` where retimed
sections are created for each strip. When strip is inside of meta
strip(s), the retimed sections of meta and actual strip are split where
they intersect and pitch is multiplied where they overlap. Each section
will have pitch value that is provided to audaspace.
Waveform overlay now represents retimed audio accurately.
Ref: #100337
Pull Request: https://projects.blender.org/blender/blender/pulls/105072
The result of detecting if a quad should flip the default 0-2 split
when tessellated only used a pre-calculated normal when available,
since the method of detecting the flip was different, the check for a
concave face could change depending on the existence of polygon-normals.
In practice this meant cycles render preview could use a different
tessellation than the GPU display.
While [0] exposed the bug, it's an inherent problem with having 2
methods of detecting concave quads.
Remove is_quad_flip_v3_first_third_fast_with_normal(..) and always
use is_quad_flip_v3_first_third_fast(..), because having to calculate
the normal inline has significant overhead.
Note that "bow-tie" quads may now render with a subdivision in a
different direction although they must be very distorted with both
triangles along the 0-2 split pointing away from each other.
Thanks to @HooglyBoogly for investigating the issue.
[0]: 16fbadde36.
Generally, one does not know if the sharing info is currently shared
and should therefore be const. Better keep it const almost all the
time and only remove the constness when absolutely necessary
and the code has checked that it is valid.
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
The comment didn't really make sense, since the removed code did the
same thing as the CustomData function anyway, and that's already done
in `mesh_init_data`.
The file extension was copied into a buffer without checking it's size.
While large extensions aren't typical, some callers used small fixed
size buffers so an unusually named file could crash.
Runtime this information is stored in the active_color_attribute and
default_color_attribute strings on the mesh, however when saving it
is still saved in the old format with flags on the CustomData layers.
When converting from the strings to the layers not all flags were
properly cleared from the CustomData layers, leading to multiple
layers having the CD_FLAG_COLOR_ACTIVE/RENDER flag.
