| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This should help examine the impact of different iteration limits,
threading grain sizes, etc.
|
|
|
|
|
|
The length constraints now work in both directions except for the first
segment, which avoids numerical stiffness close to the root.
Constraints now follow a stricter general recipe, which should make it
easier to implement future constraints with more intricate constraint
functions and gradients.
|
|
|
|
This method of finding and resolving contacts is recommended by the XPBD
author. It avoids continuous collision detection (CCD) with raycasts
in favor of using a number of substeps. The range of potential contacts
is limited by the size of the overall allowed step size and number of
substeps.
|
|
|
|
|
|
Make the update logic consistent with the case where the initial texture is
created. Also fixes a wrong assert.
Thanks Clément for spotting this.
|
|
openSubdiv_init() would detect available evaluators before any OpenGL context
exists, causing a crash with libepoxy. This test however is redundant as we
already check the requirements on the Blender side through the GPU API.
To simplify things, completely remove the device detection in the opensubdiv
module and reduce the evaluators to just CPU and GPU. The plan here is to move
to the GPU module abstraction over OpenGL/Metal/Vulkan and so all these
different backends no longer make sense.
This also removes the user preference for OpenSubdiv compute device, which was
not used for the new GPU subdivision implementation.
Ref D15291
Differential Revision: https://developer.blender.org/D15470
|
|
An increased number of vertices is not a stopper for the surface
deform modifier anymore. It might still be useful to expose the
message in the UI, but printing error message to the console on
every modifier evaluation makes real errors to become almost
invisible.
Differential Revision: https://developer.blender.org/D15468
|
|
overrides.
The outliner would tagg all existing local IDs (for remap from linked
reference data to newly created overrides) when creating a new override.
This would become critical issue in case there is several existing
copies of the same override hierarchy (leading to several hierarchies
using the same override).
Further more, BKE override creation code would not systematically
properly remapp linked usages to new overrides one whithin the affected
override hierarchy, leading to potential undesired remaining usages of
linked data.
|
|
This is useful when using an armature as a camera rig, to avoid creating and
targetting an empty object.
Differential Revision: https://developer.blender.org/D7012
|
|
Instead of duplicating logic many times.
|
|
Use const pointers to ImageSaveOptions and ImageFormatData for API
parameters where appropriate.
Differential Revision: https://developer.blender.org/D15400
|
|
Use const vars & make order of min/max checks consistent.
|
|
Also remove duplicate comments in bmesh_log.h, caused by automated
comment relocation in [0].
[0]: c4e041da23b9c45273fcd4874308c536b6a315d1
|
|
|
|
As part of a larger change (https://developer.blender.org/D14162),
adding more test coverage for existing functionality separately.
New tests:
- ids_sorted_by_default
- ids_sorted_by_default_with_libraries
- name_too_long_handling
- create_equivalent_numeric_suffixes
- zero_suffix_is_never_assigned
- remove_after_dup_get_original_name
- name_number_suffix_assignment
- renames_with_duplicates
- names_are_unique_per_id_type
|
|
This is a follow up for rB44e530e1b107fd0d91f472f9a58642ab59fd5422
which did not fix the function that interpolates boolean attributes.
|
|
Looks like this was wrong all the time.. Luckily, this conversion
is not very common.
Found when testing D15274.
|
|
Rename and refactor several F-curve key manipulation functions, and move
them from `editors` to `blenkernel`.
The functions formerly known as `delete_fcurve_key`,
`delete_fcurve_keys`, and `clear_fcurve_keys` have been moved from
`ED_keyframes_edit.h` to `BKE_fcurve.h` and have been renamed according
to hierarchical naming rules.
Below is a table of the naming changes.
| From | To |
| -- | -- |
| `delete_fcurve_key(fcu, index, do_recalc)` | `BKE_fcurve_delete_key(fcu, index)` |
| `delete_fcurve_keys(fcu)` | `BKE_fcurve_delete_keys_selected(fcu)` |
| `clear_fcurve_keys(fcu)` | `BKE_fcurve_delete_keys_all(fcu)` |
| `calchandles_fcurve()` | `BKE_fcurve_handles_recalc()` |
| `calchandles_fcurve_ex()`| `BKE_fcurve_handles_recalc_ex()` |
The function formerly known as `delete_fcurve_key` no longer takes a
`do_fast` parameter, which determined whether or not to call
`calchandles_fcurve`. Now, the responsibility is on the caller to run
the new `BKE_fcurve_handles_recalc` function if they have want to
recalculate the handles.
In addition, there is now a new static private function called
`fcurve_bezt_free` which sets the key count to zero and frees the key
array. This function is now used in couple of instances of functionally
equivalent code. Note that `BKE_fcurve_delete_keys_all` is just a
wrapper around `fcurve_bezt_free`.
This change was initially spurred by the fact that `delete_fcurve_keys`
was improperly named; this was a good opportunity to fix the location
and naming of a few of these functions.
Reviewed By: sybren
Differential Revision: https://developer.blender.org/D15282
|
|
New remapper code would also fail in some cases when remapping
libraries, similar to the issue yesterday, because ID_LI type had no
mask value.
That would fail to remap `parent` member of a library to NULL when
deleting that parent, leading to a crash e.g. in Outliner tree building
code.
Reported by @JulienKaspar from Blender studio.
|
|
Not clearing runtime remapping data for the new ID as well as the old
one can lead to false stale data there, wichi could e.g. make indirectly
linked data be tagged as directly linked.
This would generate an error report on file write when hapening on
ShapeKey ID, since that type is not allowed to be directly linked.
|
|
|
|
The values used for axes weren't in any meaningful order, use defines
to improve readability.
|
|
There were two bugs, a regression in [0] and the object-data wasn't
tagged for depsgraph updating.
[0]: 19df0e3cfd5b9fed891ed81dd1123b2351605a7d
|
|
Simplify interface, regularize implementation and some light cleanup.
See also: T79304 and D15419.
|
|
The operator bpy.ops.object.modifier_copy_to_selected()
does not work for the new Curves objects.
This is because it isn't added to BKE_object_supports_modifiers.
Differential Revision: https://developer.blender.org/D15439
|
|
A geometry component may reference read-only geometry.
In this case it has to be copied before making changes to it.
This was caused by rBb876ce2a4a4638142.
|
|
rB57097e9a8515 did not properly consider case where you have more than
one override for a same reference linked ID.
Also adds more security checks around shapekeys, since match between
override and its linked reference is never ensured either way (fixes a
crash reported by @Rik from Blender studio).
|
|
data.
When creating partial overrides, there may also be need to reamap usage
of linked data towards already existing overrides, in newly created
overrides.
|
|
A mesh wrapper might be being accessed for read-only from one thread
while another thread converts the wrapper type to something else.
The proposes solution is to defer assignment of the mesh wrapper
type until the wrapper is fully converted. The good thing about this
approach is that it does not introduce extra synchronization (and,
potentially, evaluation pipeline stalls). The downside is that it
might not work with all possible wrapper types in the future. If a
wrapper type which does not clear data separation is ever added in
the future we will re-consider the threading safety then.
Unfortunately, some changes outside of the mesh wrapper file are
to be made to allow "incremental" construction of the mesh prior
changing its wrapper type.
Unfortunately, there is no simplified file which demonstrates the
issue. It was investigated using Heist production file checked at
the revision 1228: `pro/lib/char/einar/einar.shading.blend`. The
repro case is simple: tab into edit mode, possibly few times.
The gist is that there several surface deform and shrinkwrap
modifiers which uses the same target. While one of them is building
BVH tree (which changes wrapper type) the other one accesses it for
read-only via `BKE_mesh_wrapper_vert_coords_copy_with_mat4()`.
Differential Revision: https://developer.blender.org/D15424
|
|
|
|
Some ID types did not have a filter value, even though they would be
used in remapping code, leading to missing remappings. In that specific
case, shape keys would actually never be properly remapped.
Reproducible in r1230 of
`Heist/pro/animation_test/einar/einar_new_expression_shapes2.blend`,
|
|
When dealing with 'embedded' IDs (and the like, e.g. shape keys),
liboverride code could fail in case the reference linked data (e.g. a
mesh) would not have a shapekey anymore, while the override mesh would
still have one.
Found while investigating another issue in Heist production file
`Heist/pro/animation_test/einar/einar_new_expression_shapes2.blend`,
r1230.
|
|
|
|
In some cases it is mandatory to be able to hide parts of the mesh
in order to paint certain areas. The Mask modifier doesn't work in
weight paint, and edit mode hiding requires using selection, which
is not always convenient.
This makes the weight and vertex paint modes always respect edit mode
hiding like sculpt mode. The change in behavior affects drawing and
building paint PBVH. Thus it affects brushes, but not menu operators
like Smooth or Normalize.
In addition, this makes the Alt-H shortcut available even without
any selection enabled, and implements Hide for vertex selection.
Differential Revision: https://developer.blender.org/D14163
|
|
|
|
In preparation of refactoring for texture nodes.
|
|
Currently, there are two attribute API. The first, defined in `BKE_attribute.h` is
accessible from RNA and C code. The second is implemented with `GeometryComponent`
and is only accessible in C++ code. The second is widely used, but only being
accessible through the `GeometrySet` API makes it awkward to use, and even impossible
for types that don't correspond directly to a geometry component like `CurvesGeometry`.
This patch adds a new attribute API, designed to replace the `GeometryComponent`
attribute API now, and to eventually replace or be the basis of the other one.
The basic idea is that there is an `AttributeAccessor` class that allows code to
interact with a set of attributes owned by some geometry. The accessor itself has
no ownership. `AttributeAccessor` is a simple type that can be passed around by
value. That makes it easy to return it from functions and to store it in containers.
For const-correctness, there is also a `MutableAttributeAccessor` that allows
changing individual and can add or remove attributes.
Currently, `AttributeAccessor` is composed of two pointers. The first is a pointer
to the owner of the attribute data. The second is a pointer to a struct with
function pointers, that is similar to a virtual function table. The functions
know how to access attributes on the owner.
The actual attribute access for geometries is still implemented with the `AttributeProvider`
pattern, which makes it easy to support different sources of attributes on a
geometry and simplifies dealing with built-in attributes.
There are different ways to get an attribute accessor for a geometry:
* `GeometryComponent.attributes()`
* `CurvesGeometry.attributes()`
* `bke::mesh_attributes(const Mesh &)`
* `bke::pointcloud_attributes(const PointCloud &)`
All of these also have a `_for_write` variant that returns a `MutabelAttributeAccessor`.
Differential Revision: https://developer.blender.org/D15280
|
|
|
|
Curves that are attached to a surface can now follow the surface when
it is modified using shape keys or modifiers (but not when the original
surface is deformed in edit or sculpt mode).
The surface is allowed to be changed in any way that keeps uv maps
intact. So deformation is allowed, but also some topology changes like
subdivision.
The following features are added:
* A new `Deform Curves on Surface` node, which deforms curves with
attachment information based on the surface object and uv map set
in the properties panel.
* A new `Add Rest Position` checkbox in the shape keys panel. When checked,
a new `rest_position` vector attribute is added to the mesh before shape
keys and modifiers are applied. This is necessary to support proper
deformation of the curves, but can also be used for other purposes.
* The `Add > Curve > Empty Hair` operator now sets up a simple geometry
nodes setup that deforms the hair. It also makes sure that the rest
position attribute is added to the surface.
* A new `Object (Attach Curves to Surface)` operator in the `Set Parent To`
(ctrl+P) menu, which attaches existing curves to the surface and sets the
surface object as parent.
Limitations:
* Sculpting the procedurally deformed curves will be implemented separately.
* The `Deform Curves on Surface` node is not generic and can only be used
for one specific purpose currently. We plan to generalize this more in the
future by adding support by exposing more inputs and/or by turning it into
a node group.
Differential Revision: https://developer.blender.org/D14864
|
|
Blender would crash when a file was saved where the tool settings is
set to paint on a single image (3d texture painting).
Reason is that the selected image memory address wasn't updated
when the new address.
|
|
It's helpful to make the separation of legacy data formats explicit,
because it declutters actively changed code and makes it clear which
areas do not follow Blender's current design. In this case I separated
the `MFace`/"tessface" conversion code into a separate blenkernel
.cc file and header. This also makes refactoring to remove these
functions simpler because they're easier to find.
In the future, conversions to the `MLoopUV` type and `MVert`
can be implemented here for the same reasons (see T95965).
Differential Revision: https://developer.blender.org/D15396
|
|
Regression in [0] which revealed an error in [1].
Logic for pose channel custom transform ignored ARM_NO_CUSTOM.
[0]: 3267c91b4d5caab7da8aef071a446dd2e86f86a9
[1]: c3fef001ee926fc183255b623f56da9fc5fcbb73
|
|
Also move mis-placed doc-string.
|
|
Adds a "Pin Scene" option to the workspace. When activated, the workspace will
remember the scene that was last activated in it, so that when switching back
to this workspace, the same scene will be reactivated. This is important for a
VSE workflow, so that users can switch between different workspaces displaying
a scene and thus a timeline for a specific task.
The option can be found in the Properties, Workspace tab. D11890 additionally
adds an icon for this to the scene switcher in the topbar.
The workspace data contains a pointer to the scene which is a UI to scene data
relation. When appending a workspace, the pointer is cleared.
Differential Revision: https://developer.blender.org/D9140
Reviewed by: Brecht Van Lommel, Bastien Montagne (no final accept, but was fine
with the general design earlier)
|
|
Revealed by rB43167a2c251b, but actuall issue is the
`rna_MetaBall_update_data` function expecting a never-NULL `scene`
pointer, which is not guaranteed.
This lead to refactoring the duo
`rna_MetaBall_update_data`/`BKE_mball_properties_copy`, since it was
doing a very sub-optimal O(n^2) process, new code is O(2n) now
(n being the number of Objects).
Not sure why the objects were processed through the existing bases of
the existing scene in the first place, this could miss a lot of affected
objects (e.g. in case said objects are in an excluded collection, etc.).
Also noticed that both old and new implementation can fail to fully propagate
changes to all affected meta-balls in some specific corner cases, added
a comment about it in the code.
Reviewed By: sergey
Maniphest Tasks: T99256
Differential Revision: https://developer.blender.org/D15338
|
