The problem is related to the `use_index_order` option of `BLI_kdtree_3d_calc_duplicates_fast`.
With this option, the higher index is expected to be less than `tree->nodes_len`.
Before I was double confused about how openvdb stores its
transformation matrices. Now, I know they have the same layout
physically in memory, but are logically transposed (i.e. the translation
is in the last row instead of in the last column).
The strength has a high impact on performance. With the previous
step and default one could easily and accidentally make Blender unusably
slow, because of a too high displacement strength.
Using the diagonal has the benefit, that the adaptive voxel size changes
when the bounding box changes its shape in any way. Having a changing
voxel size looks bad when rendering an animation, therefore one should
usually use a fixed voxel size when rendering an animated volume.
This becomes apparent earlier, when the adaptive voxel size changes
when the bounding box changes in any way.
Otherwise this can easily go unnoticed when rendering only a few frames
of an animated volume.
The 0.1 limit was too large. The issue with making it smaller is that
one can easily crash blender by making it to small. To counteract this,
the step has been reduced as well.
A voxel size/amount of 0 disables the modifier.
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.
This modifier uses a 3D texture to displace a volume.
For now, this can only use the previously existing texture system,
because we do not have a better alternative yet. Still, the results
can be quite good and interesting. See D9075 for some examples.
Reviewers: brecht, simonthommes
Differential Revision: https://developer.blender.org/D9075
This has serious performance implications as the additional check makes
it O(N^2) when there are a lot of merged vertices.
The goal is to move the merging to the weld modifier where it would
be much easier to optimize.
Ref D8946
This commit to complex solidify swaps the side of the geometry which
is affected by the material offset when the normal flip option is
enabled. This matches simple solidify and is considered correct/useful.
Ref D8948
This reverts commit 66cd82a8d. This was based on a misunderstanding. We do want
to take into account transforms similar to other modifiers like booleans, to
support taking into account animated transforms, combining multiple meshes into
one volume, etc.
We have our own assert implementation, `BLI_assert()` that is prefered over the
C standard library one. Its output is more consistent across compilers and
makes termination on assert failure optional (through `WITH_ASSERT_ABORT`).
In many places we'd include the C library header without ever accessing it.
Followup for rB8398050695
This requires moving a few enum definitions to DNA instead of BKE, and
adding default definitions for the two structs the cloth modifier where
the cloth modifier stores its settings. The defaults are also reordered
to be consistent with the order of each item in the struct.
This removes `foreachObjectLink` from `ModifierTypeInfo`, `GpencilModifierTypeInfo`
and `ShaderFxTypeInfo`. There is no need to have both, `foreachObjectLink` and `foreachIDLink`.
There is not code that actually depends on `foreachObjectLink`.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D9078
Remove the workaround for T59395 that increases the minimal refinement to 2
to work around an OpenSubdiv bug. This bug appears to be fixed in the latest
OpenSubdiv version we are using.
Problem found by Piotr Ostrowski.
Ref D9076
As noted in T80164, there are quite a few area of Blender where the
"Reset to Default Value" operator in button context menus doesn't work.
Modifiers are one of them, because the DNA defaults system was never
set up for them.
Additionally, this should make modifier versioning easier. Whenever a
new field is added it should be automatically initialized to the
default value.
I had to make some ordering changes in the following modifiers to work
around an error with `-Wsign-conversion` in the macros:
- Solidify Modifier
- Corrective Smooth Modifier
- Screw Modifier
Some modifiers are special cases and are skipped in this commit:
- Data Transfer Modifier
- Cloth Modifier
- Fluid Modifier
- Softbody Modifier
Differential Revision: https://developer.blender.org/D8747
This adds the option to either smooth the entire boundary, or to keep
corners sharp, for the Subdivision Surface and Multiresolution modifiers.
This mainly helps with compatibility with other software. The default
behavior remains to smooth the entire boundary.
Differential Revision: https://developer.blender.org/D8485
This makes subdivision surfaces compatible with the old subdivision
surface modifier and other applications that do not use the limit surface.
This option is available on the Subdivision Surface modifier.
Differential Revision: https://developer.blender.org/D8413
Add an option to disable Alembic vertex interpolation.
Bump subversion from 5 to 6.
Alembic stores mesh samples at specific time keys; when a frame in
Blender maps to a timecode between two samples, Blender will interpolate
the mesh vertex positions. This interpolation only happens when the mesh
has a constant topology, but sometimes this was not detected properly
when the vertices change order, but the number of mesh elements remains
the same. This would result in a mesh with jumbled up vertices (T71981).
With this patch, users have the ability to disable vertex interpolation.
An alternative would be to have better detection of topology changes,
but that that'll cause a considerable slowdown.
Maniphest Tasks: T71981
Differential Revision: https://developer.blender.org/D9041
This modifier can only be added to Volume objects. It takes a mesh
as input and generates a "density" grid near the surface or in
the enclosed volume.
Ref T73201.
Reviewers: brecht
Differential Revision: https://developer.blender.org/D9032
This reduces the number of places that have to be modified
when a new modifier is added.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D9000
With this change `outliner_draw.c` does not have to be
edited anymore when a new modifier is added.
Reviewers: campbellbarton
Differential Revision: https://developer.blender.org/D8998
This commit replaces the BVH Tree currently used by the Weld Modifier
with the KD Tree used by `Merge > By Distance`.
This changes the result of the Weld Modifier to more closely match
`Merge > By Distance`.
There is also a big performance advantage.
Here is an overview (models in D8995):
| 2.90 (Duplicate Limit = 0) | 2.90 (Duplicate Limit = 1) | master (BVH) (Duplicate Limit = 1) | patch (KD) |
| 1.69s| 0.17s | 0.12s | 0.029s |
Differential Revision: https://developer.blender.org/D8995
target in certain situations
Regression from rBdeaff945d0b96.
mesh_ensure_looptri_data would overflow.
Crash would only happen if a Data Transfer modifier (transferring
UVs) follows, so exact reason for this is not yet entirely clear. Also
there are edit-mode versions of the following BVH lookup functions so it
could be avoided (since this is a expensive operation), marking as TODO.
Similar fix as
- rB0945a79ed1eafae444d3021a5912cb39801a7209
- rB56d7e39b92997768b3db8ce2dbc262f869994145
Reviewers: mont29, campbellbarton
Maniphest Tasks: T80996
Differential Revision: https://developer.blender.org/D8973
This commit contains the Performance improvement, that was originally
proposed in D8966.
It improves the performance of the Weld Modifier by a lot.
It had a loop with execution time O(N^2) which is now O(N*log(N)) at a
bare maximum.
This patch tries to sanitize the types of our size parameters across our read
and write code, which is currently fairly inconsistent (using `int`, `uint`,
`size_t`...), by using `size_t` everywhere. Since in Blender file themselves
we can only store chunk of size `MAX_INT`, added some asserts to ensure that
as well.
See {T79561} for details.
Differential Revision: https://developer.blender.org/D8672
Warp & weight vertex-group editing modifiers miscalculated vertex weight
inversion, the weights were multiplied before being subtracted from 1.
Ref D8241
Also added code so that exact solver does the whole collection at once.
This patch allows users to use a collection (as an alternative to Object)
for the boolean modifier operand, and therefore get rid of a long modifier stack.
This property was inadvertently removed from the modifier's panel and
it wasn't caught in time for the release of 2.90. Thanks to the user
"VermossomreV" for bringing this to my attention.
Differential Revision: https://developer.blender.org/D8790
With this option, self-intersections in either or both operands
will be handled properly (if both sides are piecewise winding
number constant, and maybe some other cases too).
In the Boolean tool, this flag was there already but the code
forced a unary operation in that case; this commit corrects it
to make a binary operation. This flag makes the code slower, which
is why it is an option and not an always-on thing.
