Commit Graph

8 Commits

Author SHA1 Message Date
Jacques Lucke
e1753900b7 BLI: improve UTF-8 safety when copying StringRef to char buffers
Previously, there was a `StringRef.copy` method which would copy the string into
the given buffer. However, it was not defined for the case when the buffer was
too small. It moved the responsibility of making sure the buffer is large enough
to the caller.

Unfortunately, in practice that easily hides bugs in builds without asserts
which don't come up in testing much. Now, the method is replaced with
`StringRef.copy_utf8_truncated` which has much more well defined semantics and
also makes sure that the string remains valid utf-8.

This also renames `unsafe_copy` to `copy_unsafe` to make the naming more similar
to `copy_utf8_truncated`.

Pull Request: https://projects.blender.org/blender/blender/pulls/133677
2025-01-29 12:12:27 +01:00
Campbell Barton
381898b6dc Refactor: move BLI_path_util header to C++, rename to BLI_path_utils
Move to a C++ header to allow C++ features to be used there,
use the "utils" suffix as it's preferred for new files.

Ref !128147
2024-09-26 21:13:39 +10:00
Jacques Lucke
3ccfa65245 Geometry Nodes: support packing bakes into .blend files
Previously, it was only possible to bake to disk with geometry nodes. This patch
adds support for storing the baked data directly in the .blend file.

By default, new bakes are stored in the .blend file now. Whether a new bake
should be packed or stored on disk can be configured in two places: in the
properties of the bake node and in the bake panel of the modifier. These
settings don't affect existing bakes, only the next bake.

To unpack or pack an individual bake, there is a new operator button next to the
bake button. The icon and the label below indicate where the bake is currently
stored. The label now also contains the size of the bake.

To unpack or pack all bakes, the `File > External Data > Pack Resources / Unpack
Resources` operators can be used. The unpack operator also has a new title that
mentions the number if individual files separate from the number of bakes. This
works better than just listing a number of files because a bake can consist of
many files.

Pull Request: https://projects.blender.org/blender/blender/pulls/124230
2024-09-20 16:18:12 +02:00
Campbell Barton
6297bbe931 License headers: attribute copyright to "Blender Authors"
See #110784, it seems that merging functionality reintroduced the old
convention.
2023-11-07 15:42:52 +11:00
Sergey Sharybin
85c557ffa2 Cleanup: Rename BLI_string_utils.h to BLI_string_utils.hh
All users of it are now C++, which opens doors to add C++ to the
public API.
2023-10-20 10:27:26 +02:00
Jacques Lucke
7f00cfeab4 Cleanup: move bake items code to separate namespace 2023-09-03 13:37:50 +02:00
Jacques Lucke
d1c2b45836 Geometry Nodes: rename bdata to blob
Blob stands for "binary large object" and is a known term. I used to use the term `bdata`
to mean "binary data", mainly because I didn't think of a better name. Blob is a much
better name as it captures the intend of those files much better.

This change breaks existing bakes, because I rename the folder from `bdata` to `blobs`.
I think that is ok, because I also just broke bakes two days ago in a larger refactor
(e92c59bc9b).

Pull Request: https://projects.blender.org/blender/blender/pulls/111822
2023-09-03 12:33:59 +02:00
Jacques Lucke
e92c59bc9b Geometry Nodes: refactor simulation storage and how simulation nodes access it
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
2023-08-31 16:28:03 +02:00