Corrects incorrect usage of contraction for 'it is', when possessive 'its' was required.
Differential Revision: https://developer.blender.org/D9250
Reviewed by Campbell Barton
Field time_base of video stream must be set for some containers,
otherwise avformat_write_header() will set it to default values.
Rendered file in such case won't be played at desired frame rate.
See init_muxer() in mux.c in ffpmeg sources.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9213
A general refactor / fix commit that should clear out the issues that have been reported on external forces and moving effectors (e.g. T79537, T81660, T80088).
Code could call CustomData_get_layer_index_n with a negative index (if
no active and/or render UV layers are found). This would assert since
rBe86785c51445.
Spotted while looking into T81398.
Differential Revision: https://developer.blender.org/D9212
The new parameter made so that previously keyed Alpha values were lost
and instead the new "Emission Strength" was keyed.
Issue introduced with the original commit of Emission Strength: b248ec9776
Note: Files created since the issue (September 17) that keyframed the
Emission Strength will have to fix their files manually.
Differential Revision: https://developer.blender.org/D9221
Restore the old `correct_bezpart()` (pre-rBda95d1d851b4) function as
`BKE_curve_correct_bezpart()`, and use that where the old behaviour was
desired (that is, curve maps like used by the RGB Curves shader node).
The new (post-rBda95d1d851b4) function is also renamed to
`BKE_fcurve_correct_bezpart()` to avoid confusion.
Previously, all Face Set visibility logic was using mvert flags directly
to store the visibility state on the vertices while sculpting. As Face
Sets are a poly attribute, it is much simpler to use mpoly flags and let
BKE_mesh_flush_hidden_from_polys handle the vertex visibility, even for
Multires.
Now all operators that update the Face Set visibility state will always
copy the visibility to the mesh (using poly flags) and the grids, all
using the same code.
This should fix a lot of visibility glitches and bugs like the following:
- Sculpt visibility reset when changing multires levels.
- Multires visibility not updating in edit mode.
- Single face visibible when surrounded by visibile face set, even when
the face set was hidden.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9175
ME_POLY_LOOP_NEXT and ME_POLY_LOOP_PREV expect the offset of
the loop in the poly as an argument, in other words, corner index of the poly.
This was violated in some places. It didn't cause issues when base mesh consists
of only quads due to the way how modulus worked inside of the macro. However,
if mesh had non-quad faces adjacency information was returning wrong vertex
indices. This was causing multiple brushes to work erratically, including brushes
like Face Set, Boundary automasking, mesh relax, and others.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9173
The voxel remesher was using the voxel size to limit the shrink-wrap
projection distance. Now that distance is increased to help preserving
more detail on hard surface edges.
Reviewed By: pablodp606
Differential Revision: https://developer.blender.org/D6204
Being in render 'context'was not taken into account in code evaluating
modifiers for meshes in Edit mode.
Reviewed By: #modeling, mont29
Differential Revision: https://developer.blender.org/D9217
When creating a particle system to display simulated particles, the phystype needs to be set to 'no physics' so that particle positions are just copied and not integrated.
This will make the "Reset to Default Value" operator in button right
click menus work for the fluid modifier. Before they always reset
the values to 0.
Differential Revision: https://developer.blender.org/D9206
With constructive + deform modifiers, loop-cut visualization
wasn't following the displayed mesh.
This now gets the coordinates from the cage when available.
When we override a whole collection, we want to add non-instantiated
objects to a hidden sub-collection at the end of the process.
However, this makes no sense when instantiating an object, if other
dependencies objects get also overridden on the process, we should just
add them to the same collection owning the root object.
- BKE_bezt_subdivide_handles -> BKE_fcurve_bezt_subdivide_handles
- binarysearch_bezt_index -> BKE_fcurve_bezt_binarysearch_index
These functions are specific to F-Curves and don't make sense for other
uses of BezTriple (curve-object data for e.g.)
Also:
- Move detailed doxygen comment above code, following code-style.
- Mark bezt_add_to_cfra_elem unused.
Check selection state in `BKE_fcurve_active_keyframe_index()`, and only
return the active keyframe index when that keyframe is actually selected.
This is now also asserted in the `BKE_fcurve_active_keyframe_set()` function,
which is now also used when inserting a keyframe.
The code that restored collection flags after they are rebuilt when
moving a collection didn't take into account collection children. The
flag for the active collection was properly restored, but all of its
children would take on the exclude flag of the collection the active
collection was dragged into.
This commit builds a temporary tree structure to store the flags for
the moving collection and its children. Then it reapplies these flags
after `BKE_main_collection_sync`.
Differential Revision: https://developer.blender.org/D9158
This is a follow up commit for rB309c919ee9.
Clearing hash tables is now parallelized as well. Surprisingly, most of
the time is actually spent in `free` (a couple of milliseconds per call
in my test).
Benchmark of individual functions:
reserve_hash_maps: 17%
add_polygon_edges_to_hash_maps: 49%
serialize_and_initialize_deduplicated_edges: 12%
update_edge_indices_in_poly_loops: 14%
clear_hash_tables: 5%
`BKE_mesh_calc_edges` was the main performance bottleneck in D9141.
While openvdb only needed ~115ms, calculating the edges afterwards
took ~960ms. Now with some parallelization this is reduced to ~210ms.
Parallelizing `BKE_mesh_calc_edges` is not entirely trivial, because it
has to perform deduplication and some other things that have to happen
in a certain order. Even though the multithreading improves performance
with more threads, there are diminishing returns when too many threads
are used in this function.
The speedup is mainly achieved by having multiple hash tables that are
filled in parallel. The distribution of the edges to hash tables is based on
a hash (that is different from the hash used in the actual hash tables).
I moved the function to C++, because that made it easier for me to
optimize it. Furthermore, I added `BLI_task.hh` which contains some
light tbb wrappers for parallelization.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D9151
- Move some security checks outside of `interp` callbacks.
Namely, that we do get interpolation weights, and have something to
interpolate.
Some callbacks where not checking on those anyway, safer to move that
up into calling code.
- Cleanup usage of sub-weights, lots of interpolation callbacks wher
actually using those completely wrong.
- Change default behavior when no weights are given to higher-level API
functions: prevriously, each callback was responsible to handle that
case (and one did not even do it!), they were switching to purely
additive behavior then.
Instead, we now default to expected simple average of source values.
Note that the only real important change here is defaulting to actual
average of source value when no inertpolation weights are given (afaik,
this only happens in Weld modifier code).
Differential Revision: https://developer.blender.org/D9114
Better use higher-level code from common ID management when possible.
Helps to de-duplicate logic, and reduces outside usages of more
'dangerous' functions.
Note that we could get rid of many of those `BKE_<id_type>_add`
functions now, but on the other hand several of those take extra
parameters and perform additional actions, so think we can keep them all
for now as 'non-standard ID specific creation functions'.
Generic ID management code can now do those local temp copy handling, so
no need for duplicated own code for that.
No behavioral changes expected here.
Those were only shallow wrappers around `BKE_id_copy`, barely used (even
fully unused in some cases), and we want to get rid of those ID-specific
helpers for the common ID management tasks. Also prevents weird custom
behaviors (like `BKE_object_copy`, who was the only basic ID copy
function to reset user count of the new copy to zero).
Part of 71219.
Note that possibility to pass the new ID pointer as parameter was kept,
as this is needed for some rather specific cases (like in depsgraph/COW,
when copying into already allocated memory).
Part of T71219.
Particularly useful now that we can dynamically generate volume using
modifiers. Not exposed in the user interface currently, but it can be used
by add-ons that need to export an entire scene including volumes.
In the graph editor there is a panel that says "Active Keyframe" for
numerically editing a keyframe's values, but in the code there is no
concept of the "active keyframe." Since this is a useful concept to
have for some other features anyway, this commit adds an active
keyframe index value to FCurves. It also displays it with a theme
color for the active vertex (which didn't exist before) if the
FCurve is active.
The active keyframe in the graph editor is treated similarly to the
active vertex in the 3D view. It is the keyframe most recently selected
with a single click, and it is always selected.
For now, the only real functional change is that the active keyframe
appears in white and it should be more predictable which keyframe is
being edited in the sidebar panel.
Differential Revision: https://developer.blender.org/D7737
