In 4.1 we deprecate the `Rotate Euler` node in favor of the `Rotate Rotation`
node which uses the new rotation socket type. The node is not removed
(for now) because that would come with compatibility issues. More generally,
we'll likely run into the situation where nodes are deprecated more often in the
future, without actually removing them to keep compatibility. This patch improves
how such nodes are handled in the UI.
The patch does three things:
* Adds a new `Utilities > Deprecated` entry in the add node menu in geometry nodes.
* Moves search items which are deprecated to the bottom in the search results
(currently, this only works in English, can be fixed in bcon3).
* Adds a new `bNodeType->deprecation_notice` that will result in a deprecation
warning when the node is used.
Pull Request: https://projects.blender.org/blender/blender/pulls/117905
Previously, it was only possible to `find` a specific index in an `IndexMask`.
Now it's also possible to find the closest larger/smaller index if an exact
match doesn't exist. This could be used for slicing the mask so that it only
contains certain indices.
Pull Request: https://projects.blender.org/blender/blender/pulls/117852
isect_point_tri_v2 and isect_point_quad_v2 are handling tris/quads
in either clockwise or counter-clockwise vertex orderings. However,
for clockwise order it was considering points that lie on the edges
or vertices as "inside", whereas for counter-clockwise it was treating
them as "outside".
Visibly affected place is VSE: it has an optimization that checks
whether a fully opaque strip image fully covers the rendered area.
When the strip was scaled up to *exactly* cover the rendered area,
the check was failing since isect_point_quad_v2 was saying that a
point is outside the rect.
As far as I can tell, the functions have been "slightly wrong" in
this way for at least 15 years; harder to see through earlier
history in git.
Added a bunch of unit tests to cover this. Without the fix, "edge"
and "corner" cases against "cw" tri/quad were failing.
Performance (checked on clang15 on M1 Max):
- isect_point_tri_v2 is pretty much the same performance (assembly
several instructions shorter),
- isect_point_quad_v2 is about three times *faster* (assembly 2x
shorter), seemingly the compiler is able to use some SIMD now.
Pull Request: https://projects.blender.org/blender/blender/pulls/117786
Part of overall "improve image filtering situation" (#116980), this PR addresses
two issues:
- Bilinear (default) image filtering makes half a source pixel wide transparent
border around the image. This is very noticeable when scaling images/movies up
in VSE. However, when there is no scaling up but you have slightly rotated
image, this creates a "somewhat nice" anti-aliasing around the edge.
- The other filtering kinds (e.g. cubic) do not have this behavior. So they do
not create unexpected transparency when scaling up (yay), however for slightly
rotated images the edge is "jagged" (oh no).
More detail and images in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/117717
Part of overall "improve filtering situation" (#116980) task:
Add "Cubic Mitchell" filtering option to VSE strips. This is a cubic (4x4)
filter that generally looks better than bilinear, while not blurring the image
as much as the Cubic BSpline filter that exists elsewhere within Blender. It is
also default in many other apps.
Rename the (very recently added) VSE Bicubic filter option to Cubic BSpline.
Images in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/117517
There exist a bunch of "give me a (filtered) image pixel at this location"
functions, some with duplicated functionality, some with almost the same but
not quite, some that look similar but behave slightly differently, etc.
Some of them were in BLI, some were in ImBuf.
This commit tries to improve the situation by:
* Adding low level interpolation functions to `BLI_math_interp.hh`
- With documentation on their behavior,
- And with more unit tests.
* At `ImBuf` level, there are only convenience inline wrappers to the above BLI
functions (split off into a separate header `IMB_interp.hh`). However, since
these wrappers are inline, some things get a tiny bit faster as a side
effect. E.g. VSE image strip, scaling to 4K resolution (Windows/Ryzen5950X):
- Nearest filter: 2.33 -> 1.94ms
- Bilinear filter: 5.83 -> 5.69ms
- Subsampled3x3 filter: 28.6 -> 22.4ms
Details on the functions:
- All of them have `_byte` and `_fl` suffixes.
- They exist in 4-channel byte (uchar4) and float (float4), as well as
explicitly passed amount of channels for other float images.
- New functions in BLI `blender::math` namespace:
- `interpolate_nearest`
- `interpolate_bilinear`
- `interpolate_bilinear_wrap`. Note that unlike previous "wrap" function,
this one no longer requires the caller to do their own wrapping.
- `interpolate_cubic_bspline`. Previous similar function was called just
"bicubic" which could mean many different things.
- Same functions exist in `IMB_interp.hh`, they are just convenience that takes
ImBuf and uses data pointer, width, height from that.
Other bits:
- Renamed `mod_f_positive` to `floored_fmod` (better matches `safe_floored_modf`
and `floored_modulo` that exist elsewhere), made it branchless and added more
unit tests.
- `interpolate_bilinear_wrap_fl` no longer clamps result to 0..1 range. Instead,
moved the clamp to be outside of the call in `paint_image_proj.cc` and
`paint_utils.cc`. Though the need for clamping in there is also questionable.
Pull Request: https://projects.blender.org/blender/blender/pulls/117387
`UUID` generally stands for "universally unique identifier". The session identifier that
we use is neither universally unique, nor does it follow the standard. Therefor, the term
"session uuid" is confusing and should be replaced.
In #116888 we briefly talked about a better name and ended up with "session uid".
The reason for "uid" instead of "id" is that the latter is a very overloaded term in Blender
already.
This patch changes all uses of "uuid" to "uid" where it's used in the context of a
"session uid". It's not always trivial to see whether a specific mention of "uuid" refers
to an actual uuid or something else. Therefore, I might have missed some renames.
I can't think of an automated way to differentiate the case.
BMesh also uses the term "uuid" sometimes in a the wrong context (e.g. `UUIDFaceStepItem`)
but there it also does not mean "session uid", so it's *not* changed by this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/117350
The term `PIL` stands for "platform independent library." It exists since the `Initial Revision`
commit from 2002. Nowadays, we generally just use the `BLI` (blenlib) prefix for such code
and the `PIL` prefix feels more confusing then useful. Therefore, this patch renames the
`PIL` to `BLI`.
Pull Request: https://projects.blender.org/blender/blender/pulls/117325
Part of overall "improve filtering situation" (#116980) task:
* Add Bicubic filtering option to strip Transform "Filter" setting.
Previously this option only existed in Transform Effect "Interpolation"
setting.
- With this addition, it feels like the transform effect could
possibly be marked as legacy/deprecated, since the regular Transform
that is on all strips can do everything that Transform Effect did?
* Speed up bicubic filtering (used now in VSE, but also in CPU Compositor,
image paint, etc.) by slightly simplifying the code and using some SIMD.
Upscaling 96x54 image to 3840x2160 resolution, using Bicubic filtering:
- Windows (VS2022, Ryzen 5950X): 35.5ms -> 15.1ms
- Mac (clang 15, M1 Max): 29.6ms -> 24.4ms
* Add gtest coverage for bicubic functionality.
Pull Request: https://projects.blender.org/blender/blender/pulls/117100
- Move functions to C++ namespace
- Use two functions with simpler responsibilities instead
- Use C++ math functions
- Remove arguments structs left over from before C++ transition
- Return ray distance precalculation by value
Adds a header that defines the same constants as the C++ 20
<numbers> header.
Benefits:
- Decouple our C++ and C math APIs
- Avoid using macros everywhere, nicer syntax
- Less header parsing during compilation
- Can be replaced by `std::numbers` with C++ 20
Downsides:
- There are fewer numbers defined in the C++ standard header
- Maybe we should just wait until we can use C++ 20
Pull Request: https://projects.blender.org/blender/blender/pulls/116805
Converting a near-identity matrix to a euler could be off by over
4.5 degrees when the result of the hypotenuse calculated from the
matrix was small (around 2e-6).
Resolve by increasing the epsilon ~20x to 3.75e-05 which results
in ~1/20th the error.
This was tested against many generated near-identity matrices
(which tend to cause arithmetic error) to ensure this change doesn't
cause worse results in other cases (see report for details).
The delay is caused by `Shortcut->Resolve(0, SLR_NO_UI | SLR_UPDATE)`
to locate potentially moved or renamed paths.
The issue was resolved by adding the `SLR_NOSEARCH` flag.
This eliminates the delay without sacrificing functionality.
Pull Request: https://projects.blender.org/blender/blender/pulls/116692
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
There are some tragic design flaws with the Microsoft STL
implementation of `std::dequeue`. Unless we implement our
own similar data structure or use an implementation from
another library, the change isn't worth it.
This reverts commit b26cd6a4b9.
This reverts commit cc11ba33d9.
This reverts commit c929d75054.
This reverts commit bd3d5a750d.
GSQueue dates back over 21 years, past the initial git commit. Nowadays
we generally prefer to use data structures from the C++ standard library
or our own C++ data structures. Previous commits replaced this container
with `std::queue` in a few areas. Now it is unused and can be removed.
When aborting, the Global shared pointer for memory usage tracking
would be freed before Blender's temporary directory was purged.
Removing the temporary directory would then use MEM_* functions which
accessed the freed memory usage class.
Resolve by using malloc/free for the internal recursive_operation(..)
utility function.
Remove strip_last_slash utility function as it's a specific operation
which can be written in 2 lines & was only used once after this change.
