The goal is to make the search faster to use by dynamically adapting to the user.
This can be achieved using the simple but common approach of showing recently
selected items at the top. Note, that the "matching score" between the query and
each search item still has precedence when determining the order. So the last used
item is only at the top, if there is no other search item that matches the query better.
Besides making the search generally faster to use, my hope is that this can also
reduce the need for manually weighting search items in some places. This is
because while the ordering might not be perfect the first time, it will always be
once the user selected the element that should be at the top once.
This patch includes:
* Support for taking recent searches into account in string searching.
* Keep track of a global list of recent searches.
* Store recent searches on disk similar to recently opened files.
* A new setting in the user preferences that allows disabling the functionality.
This can be used if deterministic key strokes are required, e.g. for automated tests.
In the future this could be improved in different ways:
* Add some kind of separator in the search list to indicate which elements are at
the top because they have been used recently.
* Store the recent search items per search, instead of in a global list. This way
it could adapt to the user even better.
Pull Request: https://projects.blender.org/blender/blender/pulls/110828
Ensure the string isn't null terminated before len, if this happens
it's likely an error calculating the length argument. Since the length
is passed to memcpy it could result in reading outside `str` bounds.
There was one case where the string was duplicated then grew by 1 byte
afterwards. Replace this with an allocation since it's an uncommon
operation, not especially useful to support.
Make type conversions explicit so it's clear when char/char32_t/uint
values are being mixed, also use int instead of size_t for cursor
functions because the cursor is an int - which caused many int/size_t
comparisons.
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.
The functions used to calculate the UTF8 code-points already used the
safe versions (count_utf8_code_points & BLI_str_utf8_as_unicode_step).
So it makes sense to use safe accessors elsewhere too.
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.
Strings that include Latin1 encoding or corrupt UTF8 byte sequences
could read past the buffer bounds (stepping over the null terminator).
Resolve by passing in the string length.
Other changes to support non-UTF8 byte sequences:
- BLI_str_utf8_offset_{to/from}_index were accumulating
the UTF8 offset without accounting for non-UTF8 characters
which could cause a buffer underflow or enter an eternal loop.
- BLI_str_utf8_offset_to_index would read past the buffer bounds if the
offset passed in if it was in the middle of a UTF8 byte sequence.
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
BLI_str_utf8_char_width returns -1 for character without a known width.
This caused the right cursor motion to skip these characters.
While editable text should not contain control characters,
cursor motion should behave properly in cases when they do.
Since hiding symbols on Linux, in many cases only addresses are printed.
This utility can run run on the back-trace to replace addresses
with line & function information.
See: ./tools/utils/addr2line_backtrace.py --help for usage information.
Note that some examples online run addr2line directly and use the output
in the stack-trace, while convenient and acceptable in some cases, in my
tests addr2line can take over 20 seconds to complete for a single
address. Implement this as a post-process instead. Multi-processing to
prevent this taking too long (around ~23 seconds on my system).
Ref !111416.
This fixes#111767
`In Front` objects remain visible even if they are behind non
`In Front` objects.
It is to be expected then that the snap for them is not occluded as if
they were not `In Front`.
The f12e9f32b5 patch introduced a new improved method of blending
dual quaternion transformations to handle combined scale and rotation
better. However, the changes were not complete:
* The new math ignored crazyspace computations, which need to compute
a complete transformation matrix. As an optimization, the new method
avoided fully computing the scale component, so the matrix would
have no scale or shear.
* The Armature constraint is supposed to behave identically to the
modifier, and it was not updated. The constraint also requires
computing a complete matrix.
This change extracts the new math into a utility function, change
the optimization to be controlled by a parameter, and use the new
function in the constraint.
Pull Request: https://projects.blender.org/blender/blender/pulls/111759
The main goal here is to rename things in a way that makes sense for
simulation baking, but also for the upcoming bake node.
This also removes some versioning code from 3.6 which initialized the
default bake path. Baked data from back then can't be loaded anymore
anyway, and the way the default path is generated is different now as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/111845
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
Goals of the refactor:
* Internal support for baking individual simulation zones (not exposed in the UI yet).
* More well-defined access to simulation data in geometry nodes. Especially, it
should be more obvious where data is modified. A similar approach should also
work for the Bake node.
Previously, there were a bunch of simulation specific properties in `GeoNodesModifierData`
and then the simulation input and output nodes would have to figure out what to do with that
data. Now, there is a new `GeoNodesSimulationParams` which controls the behavior of
simulation zones. Contrary to before, different simulation zones can now be handled
independently, even if that is not really used yet. `GeoNodesSimulationParams` has to be
subclassed by a user of the geometry nodes API. The subclass controls what each simulation
input and output node does. This some of the logic that was part of the node before, into
the modifier.
The way we store simulation data is "transposed". Previously, we stored zone data per
frame, but now we store frame data per zone. This allows different zones to be more
independent. Consequently, the way the simulation cache is accessed changed. I kept
things simpler for now, avoiding many of the methods we had before, and directly
accessing the data more often which is often simple enough. This change also makes
it theoretically possible to store baked data for separate zones independently.
A downside of this is, that existing baked data can't be read anymore. We don't really
have compatibility guarantees for this format yet, so it's ok. Users will have to bake again.
The bake folder for the modifier now contains an extra subfolder for every zone.
Drawing the cached/baked frames in the timeline is less straight forward now. Currently,
it just draws the state of one of the zones, which usually is identical to that of all other
zones. This will change in the future though, and then the timeline drawing also needs
some new UI work.
Pull Request: https://projects.blender.org/blender/blender/pulls/111623
Since the normals are stored in a shared cache, tagging them dirty
recreated the cache from scratch when it was shared. Instead,
add a function that updates the cache in the same call as tagging
it dirty. This keeps the old state of the cache around even if it was
shared, and reflects the way that it's really the PBVH and sculpt
mode managing the dirty status of normals while sculpt mode
is active.
One consequence is that the BVH cache and the triangulation
cache need to be tagged dirty manually. I'd like to avoid abstracting
this more than necessary, because I'm hoping in the long term
different caching abstractions like a more global cache that takes
implicit sharing versions into account will make this complexity
unnecessary.
Fixes#111628, #111563
Pull Request: https://projects.blender.org/blender/blender/pulls/111641
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
Including <iostream> or similar headers is quite expensive, since it
also pulls in things like <locale> and so on. In many BLI headers,
iostreams are only used to implement some sort of "debug print",
or an operator<< for ostream.
Change some of the commonly used places to instead include <iosfwd>,
which is the standard way of forward-declaring iostreams related
classes, and move the actual debug-print / operator<< implementations
into .cc files.
This is not done for templated classes though (it would be possible
to provide explicit operator<< instantiations somewhere in the
source file, but that would lead to hard-to-figure-out linker error
whenever someone would add a different template type). There, where
possible, I changed from full <iostream> include to only the needed
<ostream> part.
For Span<T>, I just removed print_as_lines since it's not used by
anything. It could be moved into a .cc file using a similar approach
as above if needed.
Doing full blender build changes include counts this way:
- <iostream> 1986 -> 978
- <sstream> 2880 -> 925
It does not affect the total build time much though, mostly because
towards the end of it there's just several CPU cores finishing
compiling OpenVDB related source files.
Pull Request: https://projects.blender.org/blender/blender/pulls/111046
Fix an UBSAN warning about undefined behavior, by preventing additions
to `nullptr`:
```
blender/source/blender/blenlib/intern/BLI_memiter.c:136:42: runtime error:
applying non-zero offset 48 to null pointer
```
No functional changes.
This PR adds the Lacunarity and Normalize inputs to the Noise node
similar to the Voronoi node.
The Lacunarity input controls the scale factor by which each
successive Perlin noise octave is scaled. Which was previously hard
coded to a factor of 2.
The Noise node normalizes its output to the [0, 1] range by default.
The Normalize option makes it possible for the user to disable that.
To keep the behavior consistent with past versions it is enabled by
default.
To make the aforementioned normalization control easer to implement,
the fractal noise code now accumulates signed noise and remaps the
final sum, as opposed to accumulating positive [0, 1] noise.
Pull Request: https://projects.blender.org/blender/blender/pulls/110839
