Improve safety and correctness of matrix multiplication by using
temporary storage if one of the inputs is also the output.
No functional changes.
Differential Revision: https://developer.blender.org/D16876
Reviewed By: Campbell Barton, Sergey Sharybin
Changes to overlay_shader.cc workaround a bug in GCC-12.2
(likely a duplicate of [0]). As the workaround involved removing
a local variable which most functions already didn't assign,
remove it for all functions.
An alternative is to add (otherwise redundant) parenthesis, e.g.
`&(e_data.sh_data[sh_cfg])`, but this would need to be noted in
code-comments, so opt for removing the intermediate variable.
[0]: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106247
This makes `GVArrayImpl` and `VArrayImpl` more similar.
Only passing the pointer instead of the span also increases
efficiency a little bit. The downside is that a few asserts had
to be removed as well. However, in practice the same asserts
are in place at a higher level as well (in `VArrayCommon`).
An apostrophe should not be used because it is not a mark of plural,
even for initialisms. This involves mostly comments, but a few UI
messages are affected as well.
Differential Revision: https://developer.blender.org/D16749
This refactors how devirtualization is done in general and how
multi-functions use it.
* The old `Devirtualizer` class has been removed in favor of a simpler
solution. It is also more general in the sense that it is not coupled
with `IndexMask` and `VArray`. Instead there is a function that has
inputs which control how different types are devirtualized. The
new implementation is currently less general with regard to the number
of parameters it supports. This can be changed in the future, but
does not seem necessary now and would make the code less obvious.
* Devirtualizers for different types are now defined in their respective
headers.
* The multi-function builder works with the `GVArray` stored in `MFParams`
directly now, instead of first converting it to a `VArray<T>`. This reduces
some constant overhead, which makes the multi-function slightly
faster. This is only noticable when very few elements are processed though.
No functional changes or performance regressions are expected.
This implement most of the functions provided by the BLI math library.
This is part of the effort to unify GLSL and C++ syntax. Ref T103026.
This also adds some infrastructure to make it possible to run GLSL shader unit
test.
Some code already present in other libs is being copied to the new libs.
This patch does not make use of the new libs outside of the tests.
Note that the test is still crashing when using metal.
This was limiting the use of the templates with other non internal types
like Ceres types, xithout defining thing like that:
`template<> inline constexpr bool is_math_float_type<mpq_class> = true;`
This patch implements the matrix types (i.e:float4x4) by making heavy
usage of templating. All matrix functions are now outside of the vector
classes (inside the blender::math namespace) and are not vector size
dependent for the most part.
###Motivations
The goal/motivations of this rewrite are the same as the Vector C++ API (D13791):
- Template everything for making it work with any types and avoid code duplication.
- Use functional style instead of Object Oriented function call to allow a simple compatibility layer with GLSL syntax (see T103026 for more details).
- Allow most convenient constructor syntax and accessors (array subscript `matrix[c][r]`, or component alias `matrix.y.z`).
- Make it cover all features the current C API supports for adoption.
- Keep compilation time and debug performance somehow acceptable.
###Consideration:
- The new `MatView` class can be generated by `my_float.view<NumCol, NumRow, StartCol, StartRow>()` (with the last 2 being optionnal). This one allows modifying parts of the source matrix in place. It isn't pretty and duplicates a lot of code, but it is needed mainly to replace `normalize_m4`. At least I think it is a good starting point that can refined further.
- An exhaustive list of missing `BLI_math_matrix.h` functions from the new API can be found here P3373.
- This adds new Rotation types in order to have a clean API. This will be extended when we port the full Rotation API. The types are made so that they don't allow implicit down-casting to their vector representation.
- Some functions make direct use of the Eigen library, bypassing the Eigen C API defined in `intern/eigen`. Its use is contained inside `math_matrix.cc`. There is conflicting opinion wether we should use it more so I contained its usage to almost the tasks as in the C API for now.
Reviewed By: sergey, JacquesLucke, HooglyBoogly, Severin, brecht
Differential Revision: https://developer.blender.org/D16625
Multiple improvements to UV Cylinder and UV Sphere projection including:
* New option "Pinch" or "Fan" to improve unwrap of faces at the poles.
* Support for "Polar ZY" option on "View On Equator" and "Align To Object"
* Better handling of inputs with round-off error.
* Improved handling of faces touching the unit square border.
* Improved handling of very wide quads spanning the right hand border.
* Improved accuracy near to (0, 0).
* Code cleanup and simplification.
Differential Revision: https://developer.blender.org/D16869
- Add parentheses to suppress an assertion on some compilers.
- It turns out cloth self-collision math is not precisely symmetric,
so sort the triangle index pair to restore behavior exactly identical
to the version before the new traversal.
Follow up to rB0796210c8df32
Previously cloth self-collision and other code that wants self-overlap
data was using an ordinary BVH overlap utility function. This works,
but is suboptimal because it fails to take advantage of the fact that
it is comparing two identical trees.
The standard traversal for self-collision essentially devolves into
enumerating all elements of the tree, and then matching them to the
tree starting at the root. However, the tree itself naturally partitions
the space, so overlapping elements are likely to be mostly placed nearby
in the tree structure as well.
Instead, self-overlap can be computed by recursively computing ordinary
overlap between siblings within each subtree. This only considers each
pair of leaves once, and provides significantly better locality.
It also avoids outputting every overlap pair twice in different order.
Differential Revision: https://developer.blender.org/D16915
Use the same `".selection"` attribute for both curve and point domains,
instead of a different name for each. The attribute can now have
either boolean or float type. Some tools create boolean selections.
Other tools create float selections. Some tools "upgrade" the attribute
from boolean to float.
Edit mode tools that create selections from scratch can create boolean
selections, but edit mode should generally be able to handle both
selection types. Sculpt mode should be able to read boolean selections,
but can also and write float values between zero and one.
Theoretically we could just always use floats to store selections,
but the type-agnosticism doesn't cost too much complexity given the
existing APIs for dealing with it, and being able to use booleans is
clearer in edit mode, and may allow future optimizations like more
efficient ways to store boolean attributes.
The attribute API is usually used directly for accessing the selection
attribute. We rely on implicit type conversion and domain interpolation
to simplify the rest of the code.
Differential Revision: https://developer.blender.org/D16057
On gcc 11.3, Ubuntu 22.04 the default constructor for
ColorSceneLinear4f did not zero the r,g,b,a member variables. Replacing
the empty constructor with a default constructor circumvents this
problem (compiler bug? ) even though it *should* be more or less
equivalent.
These functions were originally implemented because:
- Not all of them existed pre C++17, but now we are using C++17.
- The call stack depth is quite a bit deeper with the std functions, making
debugging slower and more annoying. I didn't find this to be a problem
anymore recently.
No functional changes are expected.
The following functions only supported back slashes on WIN32,
which can use both forward and back slashes.
- BLI_path_append
- BLI_path_append_dir
- BLI_path_slash_ensure
- BLI_path_slash_rstrip
Follow up to [0] which is a more limited bug-fix.
[0]: a16ef95ff6
Support both forward and back slashes on WIN32.
Forward slashes for paths in WIN32 was removed in [0] (for BLI_path_join)
& [1] (for BLI_path_name_at_index), this is correct on UNIX as back
slashes can be used in paths but not on WIN32 which can use both.
Note that other path functions such as BLI_path_append &
BLI_path_slash_ensure should be updated too, but this is out of scope
for a bug-fix.
Documenting and ensuring Windows path handling functions all handle
forward slashes can be done separately.
[0]: 8f7ab1bf46
[1]: 511ae22264
Reviewed By: harley
Ref D16700
