tornavis/source/blender/blenkernel/BKE_bake_items_paths.hh

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

44 lines
1.1 KiB
C++
Raw Normal View History

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
/* SPDX-FileCopyrightText: 2023 Blender Authors
*
* SPDX-License-Identifier: GPL-2.0-or-later */
#pragma once
#include <optional>
#include <string>
#include "BLI_string_ref.hh"
#include "BLI_sub_frame.hh"
#include "BLI_vector.hh"
namespace blender::bke::bake {
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
struct MetaFile {
SubFrame frame;
std::string path;
};
struct BakePath {
/** Path to the directory containing the meta data per frame. */
std::string meta_dir;
/**
* Path to the directory that contains the binary data. Could be shared between multiple bakes
* to reduce memory consumption.
*/
std::string blobs_dir;
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
/**
* Folder that is allowed to be deleted when the bake is deleted and it doesn't contain anything
* else. Typically, this contains the meta and blob directories.
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
*/
std::optional<std::string> bake_dir;
static BakePath from_single_root(StringRefNull root_dir);
};
std::string frame_to_file_name(const SubFrame &frame);
std::optional<SubFrame> file_name_to_frame(const StringRefNull file_name);
Vector<MetaFile> find_sorted_meta_files(const StringRefNull meta_dir);
} // namespace blender::bke::bake