When using menu-search, only the last part of a search item is highlighted.
When sorting the search results, this should be taken into account and
the highlighted words should be prioritized.
This was already partially implemented in 56e98f8ba6. Now it's also
taken into account with prefix search. For example, `TC` now prefers
`Input > Texture Coordinate` over `Texture > Checker Texture`.
This replaces the older dynamic c arrays with blender::Vector as
appropriate. Many files required minimal changes and the before/after
are quite similar.
There's 3 remaining usages of the old machinery but those will require
more involved changes and design.
See #103343
Pull Request: https://projects.blender.org/blender/blender/pulls/110981
This add the possibility to create a
orthogonal basis around a given unit
vector.
The name was chosen to match the naming
convention already in place and match
the other matrix construction functions.
In other places (ex: renderers), this same
function is commonly named `make_orthonormal`
or `make_basis`.
The function is not given to have a fixed
implementation and might change overtime.
That's why the test only covers the
assumptions and not the raw values.
The implementation is borrowed from
Cycles and adapted to our math API.
Pull Request: https://projects.blender.org/blender/blender/pulls/113218
When using menu search, each search item has multiple segments. In the UI,
we only highlight last section, which is the actual node/operator name. The
menu path is grayed out. It seems reasonable to give greater weight to the
words in the search item that are highlighted.
See #112839 for an example of what effect this can have.
Pull Request: https://projects.blender.org/blender/blender/pulls/112839
This makes it clearer other "safe" functions should be used in
combination with the resulting offsets.
Also correct doc-string which wasn't updated from the "or_error()"
version of this function.
There were enough cases of callers ignoring a potential the error value,
using the column width for e.g. to calculate pixel sizes, or the size in
bytes to calculate buffer offsets.
Since text fields & labels can include characters that return an error
from BLI_str_utf8_as_unicode, add the suffix to make this explicit.
Change to handling of control characters in [0] caused tests to fail,
now the cursor no longer skips over control characters,
update test to account for this.
[0]: bc51449ff1
The hash tables and vector blenlib headers were pulling many more
headers than they actually need, including the C base math header,
our C string API header, and the StringRef header. All of this
potentially slows down compilation and polutes autocomplete
with unrelated information.
Also remove the `ListBase` constructor for `Vector`. It wasn't used
much, and making it easy to use `ListBase` isn't worth it for the
same reasons mentioned above.
It turns out a lot of files depended on indirect includes of
`BLI_string.h` and `BLI_listbase.h`, so those are fixed here.
Pull Request: https://projects.blender.org/blender/blender/pulls/111801
The `EdgeHash` and `EdgeSet` data structures are designed specifically
as a hash of an order agnostic pair of integers. This specialization can
be achieved much more easily with the templated C++ data structures,
which gives improved performance, readability, and type safety.
This PR removes the older data structures and replaces their use with
`Map`, `Set`, or `VectorSet` depending on the situation. The changes
are mostly straightforward, but there are a few places where the old
API made the goals of the code confusing.
The last time these removed data structures were significantly changed,
they were already moving closer to the implementation of the newer
C++ data structures (aa63a87d37).
Pull Request: https://projects.blender.org/blender/blender/pulls/111391
Include counts of some headers while making full blender build:
- BLI_color.hh 1771 -> 1718
- BLI_math_color.h 1828 -> 1783
- BLI_math_vector.hh 496 -> 405
- BLI_index_mask.hh 1341 -> 1267
- BLI_task.hh 958 -> 903
- BLI_generic_virtual_array.hh 509 -> 435
- IMB_colormanagement.h 437 -> 130
- GPU_texture.h 806 -> 780
- FN_multi_function.hh 331 -> 257
Note: DNA_node_tree_interface_types.h needs color include only
for the currently unused (but soon to be used) socket_color function.
Future step is to figure out how to include
DNA_node_tree_interface_types.h less.
Pull Request: #111113
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
The root cause was a classic fixed-size epsilon issue. The code that
checked if an fcurve was effectively flat, and thus shouldn't be
normalized, used a fixed-size epsilon that was reasonable for values
close-ish to zero, but didn't work well for values >= 1.0.
This patch addresses the issue by introducing a new function
`ulp_diff_ff()` that robustly computes the number of floating point
steps between two floats, and using that to ensure that a minimum
number of representable floats exist between the min/max values
of the curve. This approach scales appropriately up and down to
both huge and tiny values.
This patch also updates the existing `compare_ff_relative()` function
to use the new robust ulps code for the ulps-based part of its
comparison, resolving an issue documented in its unit tests where
it behaved poorly for values close to zero.
Pull Request: https://projects.blender.org/blender/blender/pulls/110796
This formats code that is disabled using `#if 0`. Formatting was achieved
by temporarily changing `#if 0` to `#if 1 /*something*/`, then formatting,
and then changing it back to `#if 0`.
There's quite a few libraries that depend on dna_type_offsets.h
but had gotten to it by just adding the folder that contains it to
their includes INC section without declaring a dependency to
bf_dna in the LIB section.
which occasionally lead to the lib building before bf_dna and the
header being missing, while this generally gets fixed in CMake by
adding bf_dna to the LIB section of the lib, however until last
week all libraries in the LIB section were linked as INTERFACE so
adding it in there did not resolve the build issue.
To make things still build, we sprinkled add_dependencies wherever
we needed it to force a build order.
This diff :
Declares public include folders for the bf_dna target so there's
no more fudging the INC section required to get to them.
Removes all dna related paths from the INC section for all
libraries.
Adds an alias target bf:dna to signify it has been updated to
modern cmake
Declares a dependency on bf::dna for all libraries that require it
Removes (almost) all calls to add_dependencies for bf_dna
Future work:
Because of the manual dependency management that was done, there is
now some "clutter" with libs depending on bf_dna that realistically
don't. Example bf_intern_opencolorio itself has no dependency on
bf_dna at all, doesn't need it, doesn't use it. However the
dna include folder had been added to it in the past since bf_blenlib
uses dna headers in some of its public headers and
bf_intern_opencolorio does use those blenlib headers.
Given bf_blenlib now correctly declares the dependency on bf_dna
as public bf_intern_opencolorio will get the dna header directory
automatically from CMake, hence some cleanup could be done for
bf_intern_opencolorio
Because 99% of the changes in this diff have been automated, this diff
does not seek to address these issues as there is no easy way to
determine why a certain dependency is in place. A developer will have
to make a pass a this at some later point in time. As I'd rather not
mix automated and manual labour.
There are a few libraries that could not be automatically processed
(ie bf_blendthumb) that also will need this manual look-over.
Pull Request: https://projects.blender.org/blender/blender/pulls/109835
This introduces an alias target `bf::intern::atomic` for
`bf_intern_atomic`. This has the following benefits:
- Any target name with `::` in it will be recognized as an actual
target by cmake, rather than a library name it may not know about.
and will be validated by cmake to exist. Which means if you make
a typo in the LIB section, CMake will error out telling you it
doesn't know about this specific target rather than passing it on
to the build system, where you'll either get build or linker errors
because of said typo.
- Given there is quite a cleanup still to do in the build system,
it won't always be obvious which targets have been updated to
modern targets and which still need to be done. Having a namespaced
target name is a good indicator there.
Pull Request: https://projects.blender.org/blender/blender/pulls/109784
String search & replace is a higher level function (unlike BLI_string.h)
which handlers lower level replacements for printing and string copying.
Also use BLI_string_* prefix (matching other utilities).
This makes it possible to use BLI_string in Blender's internal utilities
without depending on DynStr, MemArena... etc.
Is not visible on any of the officially platforms, as everywhere
SSE2 is available (on Apple Silicon via sse2neon).
Only got noticed by some intermittent issue during development
which made BLI_HAVE_SSE2 unaccessible.
Seems that transpose was done a bit wrong. Not sure if worth trying
to fold the equation into C++ types, as that requires extra memory
transfers for transpose. Opted for a more naive folding, which
avoids extra copies.
Added a regression test for it, verified against numpy, the BLI
SSE2 implementation.
This is the minimal change required to start using modern CMake in the
blender build system. This change is designed to allow small
incremental changes to the build system rather than doing it in one
big bang which would be unmaintainable (for me)
The biggest functional change is, previously all libraries in the
`LIB` section of a `blender_add_lib` call had the `INTERFACE` scope,
which is rarely, if ever the correct scope. This diff changes this to
`PRIVATE`
Concrete implications of this diff :
The `LIB`, `INC` and `INC_SYS` sections of an `blender_add_lib` call
now allow scoping keywords (`PUBLIC`, `PRIVATE,` `INTERFACE`) to
declare the scope of the dependency.
Right now the only library using any modern cmake is
`bf_intern_atomic` which is an header only interface library that will
just advertise its include directories.
This allows us to clean up any `CMakeLists.txt` that adds
`../../../intern/atomic` to its `INC` section to remove it in `INC` by
adding a `PRIVATE bf_intern_atomic` to the `LIB` section.
Pull Request: https://projects.blender.org/blender/blender/pulls/107858
- When string join truncates, break out of the outer loop too.
- Use BLI_string_len_array when calculating the array size for
BLI_string_join_array_by_sep_charN.
- Add tests.
This includes square root and reciprocal, and their safe versions.
For the reciprocal use name rcp, which matches Cycles and allows
to implement the same function for per-element operation on matrices.
Pull Request: https://projects.blender.org/blender/blender/pulls/108705
IndexMask::complement() is often used in geometry processing
algorithms when a selection needs to be inverted, mostly just in
curves code so far.
Instead of reusing `from_predicate` and lookup in the source mask,
scan the mask once, inserting segments between the original indices.
Theoretically this improves the performance from O(N*log(N)) to O(N).
But with the small constant offset of the former, the improvement is
generally just 3-4 times faster. However in some cases like empty
and full masks, the new code takes constant time.
Pull Request: https://projects.blender.org/blender/blender/pulls/108331
A lot of files were missing copyright field in the header and
the Blender Foundation contributed to them in a sense of bug
fixing and general maintenance.
This change makes it explicit that those files are at least
partially copyrighted by the Blender Foundation.
Note that this does not make it so the Blender Foundation is
the only holder of the copyright in those files, and developers
who do not have a signed contract with the foundation still
hold the copyright as well.
Another aspect of this change is using SPDX format for the
header. We already used it for the license specification,
and now we state it for the copyright as well, following the
FAQ:
https://reuse.software/faq/
