Rewrite the checks for determining if the solution is actually within
the triangle to fix stability issues when the correct solution is on
an edge, and step is very small, i.e. the solution is already very
close. Also, comment more clearly what is happening geometrically.
This should fix problems when vertices that should project exactly
onto an edge actually miss, resulting in weird spikes. This made
Target Normal Project unusable for the voxel remesher.
Currently the action channels are applied after the existing
transformation, as if the action controlled a child of the
bone. This is not very natural, but more importantly, the
transform tools are not designed to work conveniently with an
additional 'pseudo-child' transformation, resulting in effects
like an unexpected pivot location.
Implementing a Before mode that integrates the action channels
as if applied to a parent allows using the special transform
tool code intended for dealing with such constraints.
Note that in either mode, Action constraints should be added
in reverse order, putting a new constraint before the existing
ones that the Action was keyframed to work together.
In order to implement the option, extract a utility from
the Copy Transform constraint code for combining transforms
with special anti-shear scale handling that matches the
Aligned Inherit Scale mode.
The Before mode also requires switching the constraint to
the Local owner space, while the After mode can still use the
World space for efficiency as before. Since the constraint
doesn't have an Owner space option in the UI, this has to be
handled in an RNA setter.
For full backward compatibility, the original simple matrix
multiplication mode is preserved as the third option, but it
is not recommended due to creating shear.
Differential Revision: https://developer.blender.org/D6297
For no apparent reason, when building Alembic the script would always
re-download and re-extract the Alembic source code. This is no longer the
case, and it now only happens if the source directory is missing. Since the
source directory name contains the Alembic version, it will automatically
trigger a download+extract when the version changes.
Previously, when an unknown parameter was passed to `install_deps.sh`,
the script would just show "Wrong parameter!" without any context. This
can make it hard to figure out what's exactly going wrong. Now it prints
which parameter it thinks is wrong.
- Object/pose checks were performed in same loop,
so selected pose bones were moved instead of the object.
- Snap selected to cursor/active incorrectly used unique object-data.
The //Distance from Object// and //Distance from Camera// modifiers still used the old 2.79 matrix multiplication syntax.
Differential Revision: https://developer.blender.org/D6468
This was disabled as part of b66ae8259e which disabled
animation for display mode and other cases where it doesn't make sense.
However it's useful to be able to overwrite frame ranges,
adding this back.
This adds UDIM support to e.g. the Displacement modifier.
The implementation is straightforward: If the image is tiled, lookup the
tile based on UVs and shift the UVs into the tile's coordinates.
The problem is described in a comment in the change.
Short version: If a pass was used as a divide_type but also requested
explicitly (e.g. diffuse color), it was added to the passes list
twice because the names of the two requests didn't match.
Then, when searching for the pass to divide by, the wrong one (not
the one that the kernel was writing to) was picked.
A bug in llvm < 9.0.1 causes the compiler to crash when
openmp is enabled. Since mantaflow uses tbb we can safely
disable this flag temporarily for this module.
Reviewed By: sebbas
Differential Revision: https://developer.blender.org/D6446
Actually, to purge orphans datablock you need go to Outliner, enable Orphan mode and press Purge button (that sometimes is out of the view because the window is too narrow).
To have this option hidden make very difficult to users use and understand what means orphan data, so this patch just adds a new Clean Up menu to File menu with this option. This menu could be used in the future for more clean up options. To have a general Clean Up menu is common used in other softwares.
Reviewed By: billreynish, mont29
Differential Revision: https://developer.blender.org/D6445
This commit affects `id_sort_by_name()` and `check_for_dupid()` helper:
* Add a new parameter, `ID *id_sorting_hint`, to `id_sort_by_name()`,
and when non-NULL, check if we can insert `id` immediately before or
after it. This can dramatically reduce time spent in that function.
* Use loop over whole list in `check_for_dupid()` to also define the
likely ID pointer that will be neighbor with our new one.
This gives another decent speedup to all massive addition cases:
| Number and type of names of IDs | old code | new code | speed improvement |
| -------------------------------- | -------- | -------- | ----------------- |
| 40K, mixed (14k rand, 26k const) | 39s | 33s | 18% |
| 40K, fully random | 51s | 42s | 21% |
| 40K, fully constant | 40s | 34s | 18% |
Combined with the previous commits, this makes massive addition of IDs more
than twice as fast as previously.
This commit affects `check_for_dupid()` helper:
* Add a special, quicker code path dedicated to sequential addition of a
large number of IDs using the same base name.
This gives a significant speedup to adding 'randomly'-named IDs:
| Number and type of names of IDs | old code | new code | speed improvement |
| -------------------------------- | -------- | -------- | ----------------- |
| 40K, mixed (14k rand, 26k const) | 49s | 39s | 26% |
| 40K, fully random | 51s | 51s | 0% |
| 40K, fully constant | 71s | 40s | 78% |
Note that 'random' names give no improvement as expected, since this new code
path will never be used in such cases.
This commit affects `check_for_dupid()` helper:
* Further simplify the general logic of the code (we now typically only do
one loop over the list of data-blocks, instead of two).
This gives a significant speedup to adding 'randomly'-named IDs:
| Number and type of names of IDs | old code | new code | speed improvement |
| -------------------------------- | -------- | -------- | ----------------- |
| 40K, mixed (14k rand, 26k const) | 62s | 49s | 27% |
| 40K, fully random | 76s | 51s | 49% |
| 40K, fully constant | 77s | 71s | 8% |
Note that 'constant' names give little improvement, as in that case the first
loop over the list of IDs (checking whether base given name was already in use)
was aborting very quickly.
This commit affects `check_for_dupid()` helper:
* Fix (serious though rare) bug where several IDs could end up with
exact same name (happened with over 10k IDs with same very long name).
* Fix (relatively harmless) func reporting it did not change the given
name when it actually had truncated it.
* Sanitize handling of supported min/max number suffixes (it now handles
between 1 and 1 billion, which should be way more than enough).
* Sanitize general logic to (hopefully!) make it easier to follow.
* General cleanup (naming, comments, variables scope, remove dead code, etc.).
Note that general performances here remain the same, there is no
measurable gain or loss. Algorithm remain also the same globally.
Attempt to use a GHash to speed up checks of used names proved to be
much worse, just building the GHash would already take as much time as
the whole process with current code...
This alone can make e.g. adding 40k IDs with default name (i.e. 'fully
constant' case in table below) about 15-20% faster:
| Number and type of names of IDs | old code | new code | speed improvement |
| -------------------------------- | -------- | -------- | ----------------- |
| 40K, mixed (14k rand, 26k const) | 75s | 62s | 21% |
| 40K, fully random | 90s | 76s | 18% |
| 40K, fully constant | 94s | 77s | 22% |
Idea is to use a first pass, where we just check one item every nth ones,
until we have found the chunk in which we want to insert the new item,
then do a basic linear comparison with all items in that chunk as before.
Also, list is now walked backward, as in most common 'massive insertion'
cases new ID's names have higher number, hence ends up towards the end of
the list.
This new sorting function can be between a few percents and 50% quicker than
original code, depending on various factors (like length of common parts of
ID names, whether new IDs should be added towards the end or not, how high
in numbering we are, etc.).
Note: another, full bisecting approach was also tried, which gives a massive
reduction of comparisons (from n items to log2(n)), but it only gave minor
improvements of speed from original fully linear code, while adding a fair
amount of complexity to the logic. Only case it was shining was the unlikely
'very long, almost similar ID names' case (since `strcasecmp()` is rather
costly then).
Those tests are here mostsly to ensure ID name management is working as
expected (the code ensuring we never have two ilocal data-blocks of the
same type with the same name in a .blend file).
Note: Currently fails in some cases, fixes are incoming.
Note: Ideally this would be in C, but we already have too many tests
linking the whole Blender and its libraries, this is becoming a real
pain to link debug + ASAN + tests build these days... So until we find a
better way to handle those dependencies, sticking to simple python
scripts.
Since rB6bc6d016c5e7, outliner was not opening back up from the found
active element (but only its ID instead -- all occurances of this ID in
any collection).
Now expand from the active element as well (but only do this for the
first occurance of the corresponding ID)
Maniphest Tasks: T71844
Differential Revision: https://developer.blender.org/D6329
