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).
Previously Blender would only match the existing curve slope when the
to-be-inserted key value was already very close to the curve. This check
is now removed, allowing for sliders in the graph editor to subtly
change the curve, and for keyframes added with ctrl+click to follow the
curve better.
`CustomData_bmesh_interp` use the same CustomData decryptor (in this case, `bm->ldata`) in both blocks.
So make sure that all CustomData layers match.
This commit also removes redundant `BM_elem_attrs_copy_ex` calls.
Maniphest Tasks: T81060
Differential Revision: https://developer.blender.org/D9159
This resolves a long list of linker warnings that is currently only showing up on macOS arm builds.
The warnings themselves are of this shape (one example):
```
ld: warning: direct access in function 'Manta::MeshDataImpl<Manta::Vector3D<float> >::_W_39(_object, object, object*)' from file '../../lib/libextern_mantaflow.a(mesh.h.reg.cpp.o)' to global weak symbol 'typeinfo for Manta::MeshDataImpl<Manta::Vector3D<float> >' from file '../../lib/libextern_mantaflow.a(mesh.cpp.o)' means the weak symbol cannot be overridden at runtime. This was likely caused by different translation units being compiled with different visibility settings.
```
Just would like to get your opinion to make sure this is an acceptable way to handle this on all platforms.
Reviewed By: LazyDodo
Differential Revision: https://developer.blender.org/D9002
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.
Clean up the code that handles mouse clicks on animation channels in the
non-NLA animation editors, by splitting into separate functions.
No functional changes.
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.
For multi-config generators, tests are in `bin/tests/<config>` folder.
and OpenMP cannot be found at `@executable_path/../Resources/lib`.
So create that folder and put the library there to be used by tests.
It is not ideal to copy the library around. When minimum CMake version
is changed to 3.12, FindOpenMP by CMake can be used for this whole
block of code. Then a nice rpath based solution can be used.
The "Apple" part is guaranteed by the platform file.
"Clang" is enough to differentiate it from other compilers.
Came across this due to the custom built LLVM toolchain I'm using.
The "Geometry start & End" panel was grayed when using an object
to create the curve bevel. It should only be grayed out in this case
when no object is chosen in the "Bevel" subpanel.
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
`targetIsDirectory` slipped through the code review of
{D6679}/{rBafb1a64ccb81}.
`BLI_is_dir` exists to check for directory status of a file.
Remove some `else-after-return`s.
Use `r_` prefix for return value arguments, and move it to the end
in the list of arguments.
The routine to find dissolvable vertices had a check to ensure
that the vertex was exactly in line with the two neighbors.
I have convinced myself that this check is unneccesary (it was
failing with only a 1e-9 difference from 0 on a cross check),
so have removed it.
After tests were bundled in a single executable and cycles and libmv
created their own tests, the warnings on macOS have gone over 800.
The reason is setting `*_LIBRARIES` to names of the libraries
and later using `link_directories` to link them properly.
https://cmake.org/cmake/help/latest/command/link_directories.html
> Note This command is rarely necessary and should be avoided where
> there are other choices. Prefer to pass full absolute paths to
> libraries where possible, since this ensures the correct library
> will always be linked. The find_library() command provides the
> full path, which can generally be used directly in calls to
> target_link_libraries().
Warnings like the following popup for every target/executable,
for every library it links to.
```
ld: warning: directory not found for option
'-L/Users/me/blender-build/blender/../lib/darwin/jpeg/lib/Debug'
```
The patch completes a step towards removing `link_directories` as
mentioned in TODO at several places.
The patch uses absolute paths to link libraries and removes
all `*_LIBPATH`s except `PYTHON_LIBPATH` from
`platform_apple.cmake` file. (The corner case where it's used seems
like dead code. Python is no longer shipped with that file structure.)
Also, unused code for LLVM-3.4 has been removed.
Also, guards to avoid searching libraries in system directories have
been added.
`APPLE` platform now no longer needs `setup_libdirs`,
`cycles_link_directories`, and `link_directories`.
The number of warnings now is less than 100, most of them being
deprecation ones in dependencies.
This patch depended on {rBb746179d0add}, {rB2fdbe4d05011},
{rB402a4cadba49} and {rBd7f482f88ecb}.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D8855
The real maximum was `GPU_SAMPLER_ICON`, not `GPU_SAMPLER_REPEAT`, my
bad. {rBa31a87f8943aa40}
Move `GPU_SAMPLER_MAX` out of the enum since it's used as an `int`
at many places.
Also, the macro `ENUM_OPERATORS` needs a maximum, and this enumerator
cannot be used as the argument of that macro. It creates wrong values
in the `~` NOT operator.
Thanks @deadpin for catching this.
Reviewed By: fclem
Differential Revision: https://developer.blender.org/D9157
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.
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
