BLI_strncpy_utf8 didn't check for null bytes within bytes stepped
over by the variable length UTF8 encoding.
While a valid UTF8 string wont include these, it's possible Latin1
encoding or a truncated string includes such characters.
In this case, the entire string is copied as it's not the purpose of
this function to correct or strip invalid/truncated encoding,
only to prevent it from happening in the first place.
Avoid instantiating the templates separately in every translation unit.
This saves 20 KB in my Blender binary. Also remove a timer mistakenly
committed.
Replace MAXPATHLEN with FILE_MAX, always allocate if the buffer isn't
big enough since creating a truncated directory isn't useful.
Having some code-paths only run in an ifdef complicated the code
and made it more difficult to follow.
Also assert the path doesn't contain ".." directories as they aren't
supported.
- Don't duplicate/allocate the path on each recursion,
instead make a single copy which is modified in-place.
- Move slash-stepping to a BLI_path utility function that accesses
the end position of the parent directory, handles multiple slashes
and '/./'.
Only use the term len & maxlen when they represent the length & maximum
length of a string. Instead of the available bytes to use.
Also include the data they're referencing as a suffix, otherwise it's
not always clear what the length is in reference to.
Reserve the term `len` for string length, some functions used this for
an string/array length, others a destination buffer size
(even within a single function declaration).
Also improve naming consistency across different functions.
`sinf(float_angle)` is sometimes producing different results on
x86_64 cpus and apple silicon cpus. Convert to double precision
to increase accuracy and consistency.
Partial fix for #104513. More to come.
There is no advantage in using BLI_strncpy/BLI_strncpy_utf8 when the
destination string has been allocated and won't be concatenated.
Also no need to calloc memory which is filled by strcpy afterwards.
- Names ending with len sometimes referred to the buffer size.
The same names were used for both buffer size and string length
depending on the function in some cases.
- Rename str/string to path for generic path functions.
- Rename BLI_path_rel arguments (file, relfile) to (path, basename)
as it wasn't so clear which is being made relative, `file` can be a
directory so rename to `path` (matches naming for BLI_path_abs).
- Avoid inline ifdef checks for DEBUG_STRSIZE
- Add BLI_string_debug_size_after_nil to ensure strings to manipulate
have the expected buffer size after the nil terminator.
- Add checks to more string manipulation functions.
Further changes are required for this to be enabled during regular
development as the RNA currently allocates the strings length but
passes in the buffer size as a limit which conflicts with DEBUG_STRSIZE.
This adds support for building simulations with geometry nodes. A new
`Simulation Input` and `Simulation Output` node allow maintaining a
simulation state across multiple frames. Together these two nodes form
a `simulation zone` which contains all the nodes that update the simulation
state from one frame to the next.
A new simulation zone can be added via the menu
(`Simulation > Simulation Zone`) or with the node add search.
The simulation state contains a geometry by default. However, it is possible
to add multiple geometry sockets as well as other socket types. Currently,
field inputs are evaluated and stored for the preceding geometry socket in
the order that the sockets are shown. Simulation state items can be added
by linking one of the empty sockets to something else. In the sidebar, there
is a new panel that allows adding, removing and reordering these sockets.
The simulation nodes behave as follows:
* On the first frame, the inputs of the `Simulation Input` node are evaluated
to initialize the simulation state. In later frames these sockets are not
evaluated anymore. The `Delta Time` at the first frame is zero, but the
simulation zone is still evaluated.
* On every next frame, the `Simulation Input` node outputs the simulation
state of the previous frame. Nodes in the simulation zone can edit that
data in arbitrary ways, also taking into account the `Delta Time`. The new
simulation state has to be passed to the `Simulation Output` node where it
is cached and forwarded.
* On a frame that is already cached or baked, the nodes in the simulation
zone are not evaluated, because the `Simulation Output` node can return
the previously cached data directly.
It is not allowed to connect sockets from inside the simulation zone to the
outside without going through the `Simulation Output` node. This is a necessary
restriction to make caching and sub-frame interpolation work. Links can go into
the simulation zone without problems though.
Anonymous attributes are not propagated by the simulation nodes unless they
are explicitly stored in the simulation state. This is unfortunate, but
currently there is no practical and reliable alternative. The core problem
is detecting which anonymous attributes will be required for the simulation
and afterwards. While we can detect this for the current evaluation, we can't
look into the future in time to see what data will be necessary. We intend to
make it easier to explicitly pass data through a simulation in the future,
even if the simulation is in a nested node group.
There is a new `Simulation Nodes` panel in the physics tab in the properties
editor. It allows baking all simulation zones on the selected objects. The
baking options are intentially kept at a minimum for this MVP. More features
for simulation baking as well as baking in general can be expected to be added
separately.
All baked data is stored on disk in a folder next to the .blend file. #106937
describes how baking is implemented in more detail. Volumes can not be baked
yet and materials are lost during baking for now. Packing the baked data into
the .blend file is not yet supported.
The timeline indicates which frames are currently cached, baked or cached but
invalidated by user-changes.
Simulation input and output nodes are internally linked together by their
`bNode.identifier` which stays the same even if the node name changes. They
are generally added and removed together. However, there are still cases where
"dangling" simulation nodes can be created currently. Those generally don't
cause harm, but would be nice to avoid this in more cases in the future.
Co-authored-by: Hans Goudey <h.goudey@me.com>
Co-authored-by: Lukas Tönne <lukas@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/104924
- Rename name/filename/path to filepath when it's used for full paths.
- Rename name/path to dirpath when it refers to a directory.
- Rename file to filepath or path (when it may be a file or dir).
- Rename ImBuf::name & anim::name to filepath.
Rename BLI_make_existing_file to BLI_file_ensure_parent_dir_exists.
The previous name read as if it would make (touch) the file,
where as it ensures the directory component of the path exists.
Move from BLI_path to BLI_fileops as path utilities should only
manipulate paths and not deal with file IO creation
(this has more in common with BLI_file_touch for e.g.).
A NULL defname would early exit (doing nothing) this isn't good behavior
as this function should always make the name unique and a NULL defname
is likely an error in the code which would allow duplicate names.
This is also inconsistent with BLI_uniquename_cb which always
wrote the defname into the name if it was empty.
Mark this argument as never-NULL.
Explicitly list ATTR_NONNULL indices in most cases so it's explicit
that arguments aren't NULL (and adding new arguments that can be NULL
isn't such a hassle).
This fixes a crash where merging vertices by distance leads to a crash since
0652945dbd. The change did not cause
the bug though, it just made the underlying issue visible.
The issue was that `kdtree_order` assumed that the `KDTreeNode.index` didn't
have gaps, i.e. every index in a certain range is used. However, that is not the
case when only a subset of the vertices of a mesh are added to the kdtree.
Pull Request: https://projects.blender.org/blender/blender/pulls/107535
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
