A `BitGroupVector` is a compact data structure that allows storing multiple
bits per element, for example 5 bits per vertex. The implementation is
mostly just a wrapper around `BitVector`. There is some additional logic
to make sure that the bit span of every element is bounded (according
to the `is_bounded_span` function). This makes it more efficient to operate
on groups as a whole (e.g. `or` one group into another). In some sense,
this data structure can also be interpreted as a 2D bit array. Functions
like `append` can be added when they become necessary.
The new data structure is used to replace some `MultiValueMap` in
geometry nodes. This simplifies the code.
This is consistent with `Span`, and also allows returning a bounded
bit span when taking the front of an existing bounded span, which
can simplify using optimized bit processing.
Pull Request: https://projects.blender.org/blender/blender/pulls/107441
Most of this patch is by Jacques Lucke, from the simulation branch.
This commit adds generic expression evaluation for bit spans, helping
to generalize the optimizations that avoid processing a single bit
at a time. Operations like "for each 1 index", "or", and "and" are
already implemented in this pull request. Bits in full integers are
processed 64 at a time, then remaining bits are processed all at once.
The operations allow implementing a `copy_from` method for bit spans.
Currently this optimized evaluation is only implemented for simpler
bounded bit spans. Bounded bit spans have constraints on their bit
ranges that make them more efficient to process. Large spans must start
at the beginning of the first int, and small spans must start and end
within the first int.
Knowing these constraints at compile time reduces the number of edge
cases in the operations, but mainly allows skipping alignment between
multiple spans with different offsets.
Pull Request: https://projects.blender.org/blender/blender/pulls/107408
This simplifies the code that works with the `BLI_serialize.hh` header.
The various `lookup` methods do a linear search. If there are only a
few elements that can even be faster than building the map first.
In the future it might be nice to transparently build and cache the
map internally if necessary.
The main goal of these changes is to support checking if some data has
been changed over time. This is used by the WIP simulation nodes during
baking to detect which attributes have to be stored in every frame because
they have changed.
By using a combination of a weak user count and a version counter, it is
possible to detect that an attribute (or any data controlled by implicit
sharing) has not been changed with O(1) memory and time. It's still
possible that the data has been changed multiple times and is the same
in the end and beginning of course. That wouldn't be detected using this
mechanism.
The `ImplicitSharingInfo` struct has a new weak user count. A weak
reference is one that does not keep the referenced data alive, but makes sure
that the `ImplicitSharingInfo` itself is not deleted. If some piece of
data has one strong and multiple weak users, it is still mutable. If the
strong user count goes down to zero, the referenced data is freed.
Remaining weak users can check for this condition using `is_expired`.
This is a bit similar to `std::weak_ptr` but there is an important difference:
a weak user can not become a strong user while one can create a `shared_ptr`
from a `weak_ptr`. This restriction is necessary, because some code might
be changing the referenced data assuming that it is the only owner. If
another thread suddenly adds a new owner, the data would be shared again
and the first thread would not have been allowed to modify the data in
the first place.
There is also a new integer version counter in `ImplicitSharingInfo`.
It is incremented whenever some code wants to modify the referenced data.
Obviously, this can only be done when the data is not shared because then
it would be immutable. By comparing an old and new version number of the
same sharing info, one can check if the data has been modified. One has
to keep a weak reference to the sharing info together with the old version
number to ensure that the new sharing info is still the same as the old one.
Without this, it can happen that the sharing info was freed and a new
one was allocated at the same pointer address. Using a strong reference
for this purpose does not work, because then the data would never be
modified because it's shared.
- Avoid a separate memmove call for each `..`.
- Avoid ambiguous path stepping, where separator literals
needed to be checked to avoid fence post errors.
- Correct & update the doc-string.
This patch adds address sanitizer support to memory pools.
when ASAN is enabled the following happens:
* 32 byte red zones are inserted between pool elements.
* The BLI_mempool struct itself is marked as a red zone.
* Access to the pool goes through a thread mutex (except when compiling makesdna).
This is very useful for finding bugs in code that uses BMesh.
Pull Request: #104668
Keep these operations separate to simplify path handling logic & docs.
Many callers passed NULL and there were times paths were passed in which
didn't make any sense (where the paths had already been made absolute).
- Don't attempt to skip the WIN32 drive component on relative paths
it's possible this would have unexpected behavior but paths like
are already unlikely to work as expected, e.g. "//C:\".
- Remove early returns for empty paths as there is no need for special
handling.
- Add path normalize NOP tests
- Implement mesh creation in GeometrySet agnostic way, with less context
- Remove useless comments
- Use a field to clamp crease values instead of clamping when copying
- Small variable name tweaks
- Use `BKE_subdiv_new_from_mesh` instead of "update"
- Remove crease layers before writing, avoiding potential copy
Follow Python's os.path.normpath's handing on relative paths in more
situations.
- Leading './' is always stripped.
- Relative paths such as `//./a` & `///a` normalize to `//a`.
- Support for trailing `/..` on the end of paths.
- Avoid empty paths for relative paths that would otherwise
resolve to an empty string, e.g: `a/b/c/../../..` resolves to `.`.
- Calculate spans of redundant `//` & `/./` before calling `memmove`.
- Loop backwards when removing path elements for greater efficiency.
- When removing `/../` components, avoid continuously searching from
the start of the path and instead search from the last found '/../'.
The only WIN32 specific behavior the drive or UNC prefix is skipped
(except for it's slash), allowing WIN32 & Unix paths to share the same
code-path.
Note that this changes behavior for WIN32 when there are too many parent
directories, where ".." that move before the root directory are removed
instead of being left in the path. e.g:
`C:\a\..\..\b` resolved to `C:\..\b` whereas now the result is `C:\b`.
This matches Python's `os.path.normpath`.
The node outputs the index of the closest element to itself. See #102387
for the original design.
This is different from the Sample Nearest node in two important ways:
* It does not have a geometry input, instead the geometry is taken from the
field evaluation context.
* The node can exclude the "current" element from the search.
* The group id input can be used to build subsets of elements that only
consider each other as neighbors and ignore elements with other ids.
Pull Request: https://projects.blender.org/blender/blender/pulls/104619
The result of detecting if a quad should flip the default 0-2 split
when tessellated only used a pre-calculated normal when available,
since the method of detecting the flip was different, the check for a
concave face could change depending on the existence of polygon-normals.
In practice this meant cycles render preview could use a different
tessellation than the GPU display.
While [0] exposed the bug, it's an inherent problem with having 2
methods of detecting concave quads.
Remove is_quad_flip_v3_first_third_fast_with_normal(..) and always
use is_quad_flip_v3_first_third_fast(..), because having to calculate
the normal inline has significant overhead.
Note that "bow-tie" quads may now render with a subdivision in a
different direction although they must be very distorted with both
triangles along the 0-2 split pointing away from each other.
Thanks to @HooglyBoogly for investigating the issue.
[0]: 16fbadde36.
Generally, one does not know if the sharing info is currently shared
and should therefore be const. Better keep it const almost all the
time and only remove the constness when absolutely necessary
and the code has checked that it is valid.
Some callers that access the extension operated on the end of the path
even when there was no extension. Using this avoids having to assign
the end of the string using a separate check.
The file extension was copied into a buffer without checking it's size.
While large extensions aren't typical, some callers used small fixed
size buffers so an unusually named file could crash.
While replacing the extension with an empty string works,
it required a redundant string-size argument which took a dummy
value in some cases. Avoid having to pass in a redundant string size by
adding a function that strips the extension.
Finding the extension included hidden files (starting with a '.'),
now finding the extension matches Python's `os.path.splitext` behavior
which has the advantate a hidden file is not considered one long
extension - with an empty name part.
Also update code to use BLI_path_extension in cases which previously
in-lined this logic.
BLI_path_frame_get path argument is now const,
it was being manipulated unnecessarily.
