tornavis/source/blender/blenkernel/BKE_bake_geometry_nodes_mod...

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

129 lines
3.8 KiB
C++
Raw Normal View History

/* SPDX-FileCopyrightText: 2023 Blender Authors
*
* SPDX-License-Identifier: GPL-2.0-or-later */
#pragma once
#include "BLI_sub_frame.hh"
#include "BKE_bake_items.hh"
#include "BKE_bake_items_paths.hh"
#include "BKE_bake_items_serialize.hh"
struct NodesModifierData;
struct Main;
struct Object;
struct Scene;
namespace blender::bke::bake {
enum class CacheStatus {
/** The cache is up-to-date with the inputs. */
Valid,
/**
* Nodes or input values have changed since the cache was created, i.e. the output would be
* different if the simulation was run again.
*/
Invalid,
/** The cache has been baked and will not be invalidated by changing inputs. */
Baked,
};
/**
* Stores the state for a specific frame.
*/
struct FrameCache {
SubFrame frame;
BakeState state;
/** Used when the baked data is loaded lazily. */
std::optional<std::string> meta_path;
};
/**
* Stores the state after the previous simulation step. This is only used, when the frame-cache is
* not used.
*/
struct PrevCache {
BakeState state;
SubFrame frame;
};
/**
Geometry Nodes: new Bake node This adds a new `Bake` node which allows saving and loading intermediate geometries. Typical use cases we want address with this currently are: * Bake some data for use with a render engine. * Bake parts of the node tree explicitly for better performance. For now, the format that is written to disk is not considered to be an import/export format. It's not guaranteed that data written with one Blender version can be read by another Blender version. For that it's better to use proper interchange formats. Better support for those will be added eventually as well. We also plan an `Import Bake` node that allows reading the blender-specific baked data independent of the Bake node and at different frames. The baking works very similar to the baking in the simulation zone (UI and implementation wise). Major differences are: * The Bake node has a `Bake Still` and `Bake Animation` mode. * The Bake node doesn't do automatic caching. Implementation details: * Refactored how we create the Python operators for moving socket items so that it also makes sense for non-zones. * The `ModifierCache` stores an independent map of `SimulationNodeCache` and `BakeNodeCache`, but both share a common data structure for the actually baked data. * For baking, the `Bake` node is added as a side-effect-node in the modifier. This will make sure that the node is baked even if it's currently not connected to the output. * Had to add a new `DEG_id_tag_update_for_side_effect_request` function that is used during baking. It's necessary because I want to evaluate the object again even though none of its inputs changed. The reevaluation is necessary to create the baked data. Using `DEG_id_tag_update` technically works as well, but has the problem that it also uses the `DEG_UPDATE_SOURCE_USER_EDIT` flag which (rightly) invalidates simulation caches which shouldn't happen here. * Slightly refactored the timeline drawing so that it can also show the baked ranges of Bake nodes. It does not show anything for baked nodes with a in Still mode though. * The bake operator is refactored to bake a list of `NodeBakeRequest` which makes the code easier to follow compared to the previous nested `ObjectBakeData > ModifierBakeData > NodeBakeData` data structure. * The bake operators are disabled when the .blend file is not yet saved. This is technically only necessary when the bake path depends on the .blend file path but seems ok to force the user anyway (otherwise the bake path may be lost as well if it's set explicitly). * The same operators are used to bake and delete single bakes in `Bake` nodes and `Simulation Zones`. On top of that, there are separate operators of baking and deleting all simulation bakes (those ignore bake nodes). * The `Bake` node remembers which inputs have been fields and thus may be baked as attributes. For that it uses an `Is Attribute` flag on the socket item. This is needed because the baked data may still contain attribute data, even if the inputs to the bake node are disconnected. * Similar to simulation zones, the behavior of `Bake` nodes is passed into the geometry nodes evaluation from the outside (from the modifier only currently). This is done by providing the new `GeoNodesBakeParams` in `GeoNodesCallData` when executing geometry nodes. Next Steps (mostly because they also involve simulations): * Visualize nodes that have not been evaluated in the last evaluation. * Fix issue with seemingly loosing baked data after undo. * Improve error handling when baked data is not found. * Show bake node in link drag search. * Higher level tools for managing bakes. Pull Request: https://projects.blender.org/blender/blender/pulls/115466
2023-12-18 13:01:06 +01:00
* Baked data that corresponds to either a Simulation Output or Bake node.
*/
Geometry Nodes: new Bake node This adds a new `Bake` node which allows saving and loading intermediate geometries. Typical use cases we want address with this currently are: * Bake some data for use with a render engine. * Bake parts of the node tree explicitly for better performance. For now, the format that is written to disk is not considered to be an import/export format. It's not guaranteed that data written with one Blender version can be read by another Blender version. For that it's better to use proper interchange formats. Better support for those will be added eventually as well. We also plan an `Import Bake` node that allows reading the blender-specific baked data independent of the Bake node and at different frames. The baking works very similar to the baking in the simulation zone (UI and implementation wise). Major differences are: * The Bake node has a `Bake Still` and `Bake Animation` mode. * The Bake node doesn't do automatic caching. Implementation details: * Refactored how we create the Python operators for moving socket items so that it also makes sense for non-zones. * The `ModifierCache` stores an independent map of `SimulationNodeCache` and `BakeNodeCache`, but both share a common data structure for the actually baked data. * For baking, the `Bake` node is added as a side-effect-node in the modifier. This will make sure that the node is baked even if it's currently not connected to the output. * Had to add a new `DEG_id_tag_update_for_side_effect_request` function that is used during baking. It's necessary because I want to evaluate the object again even though none of its inputs changed. The reevaluation is necessary to create the baked data. Using `DEG_id_tag_update` technically works as well, but has the problem that it also uses the `DEG_UPDATE_SOURCE_USER_EDIT` flag which (rightly) invalidates simulation caches which shouldn't happen here. * Slightly refactored the timeline drawing so that it can also show the baked ranges of Bake nodes. It does not show anything for baked nodes with a in Still mode though. * The bake operator is refactored to bake a list of `NodeBakeRequest` which makes the code easier to follow compared to the previous nested `ObjectBakeData > ModifierBakeData > NodeBakeData` data structure. * The bake operators are disabled when the .blend file is not yet saved. This is technically only necessary when the bake path depends on the .blend file path but seems ok to force the user anyway (otherwise the bake path may be lost as well if it's set explicitly). * The same operators are used to bake and delete single bakes in `Bake` nodes and `Simulation Zones`. On top of that, there are separate operators of baking and deleting all simulation bakes (those ignore bake nodes). * The `Bake` node remembers which inputs have been fields and thus may be baked as attributes. For that it uses an `Is Attribute` flag on the socket item. This is needed because the baked data may still contain attribute data, even if the inputs to the bake node are disconnected. * Similar to simulation zones, the behavior of `Bake` nodes is passed into the geometry nodes evaluation from the outside (from the modifier only currently). This is done by providing the new `GeoNodesBakeParams` in `GeoNodesCallData` when executing geometry nodes. Next Steps (mostly because they also involve simulations): * Visualize nodes that have not been evaluated in the last evaluation. * Fix issue with seemingly loosing baked data after undo. * Improve error handling when baked data is not found. * Show bake node in link drag search. * Higher level tools for managing bakes. Pull Request: https://projects.blender.org/blender/blender/pulls/115466
2023-12-18 13:01:06 +01:00
struct NodeBakeCache {
/** All cached frames sorted by frame. */
Vector<std::unique_ptr<FrameCache>> frames;
/** Where to load blobs from disk when loading the baked data lazily. */
std::optional<std::string> blobs_dir;
/** Used to avoid reading blobs multiple times for different frames. */
std::unique_ptr<BlobReadSharing> blob_sharing;
/** Used to avoid checking if a bake exists many times. */
bool failed_finding_bake = false;
Geometry Nodes: new Bake node This adds a new `Bake` node which allows saving and loading intermediate geometries. Typical use cases we want address with this currently are: * Bake some data for use with a render engine. * Bake parts of the node tree explicitly for better performance. For now, the format that is written to disk is not considered to be an import/export format. It's not guaranteed that data written with one Blender version can be read by another Blender version. For that it's better to use proper interchange formats. Better support for those will be added eventually as well. We also plan an `Import Bake` node that allows reading the blender-specific baked data independent of the Bake node and at different frames. The baking works very similar to the baking in the simulation zone (UI and implementation wise). Major differences are: * The Bake node has a `Bake Still` and `Bake Animation` mode. * The Bake node doesn't do automatic caching. Implementation details: * Refactored how we create the Python operators for moving socket items so that it also makes sense for non-zones. * The `ModifierCache` stores an independent map of `SimulationNodeCache` and `BakeNodeCache`, but both share a common data structure for the actually baked data. * For baking, the `Bake` node is added as a side-effect-node in the modifier. This will make sure that the node is baked even if it's currently not connected to the output. * Had to add a new `DEG_id_tag_update_for_side_effect_request` function that is used during baking. It's necessary because I want to evaluate the object again even though none of its inputs changed. The reevaluation is necessary to create the baked data. Using `DEG_id_tag_update` technically works as well, but has the problem that it also uses the `DEG_UPDATE_SOURCE_USER_EDIT` flag which (rightly) invalidates simulation caches which shouldn't happen here. * Slightly refactored the timeline drawing so that it can also show the baked ranges of Bake nodes. It does not show anything for baked nodes with a in Still mode though. * The bake operator is refactored to bake a list of `NodeBakeRequest` which makes the code easier to follow compared to the previous nested `ObjectBakeData > ModifierBakeData > NodeBakeData` data structure. * The bake operators are disabled when the .blend file is not yet saved. This is technically only necessary when the bake path depends on the .blend file path but seems ok to force the user anyway (otherwise the bake path may be lost as well if it's set explicitly). * The same operators are used to bake and delete single bakes in `Bake` nodes and `Simulation Zones`. On top of that, there are separate operators of baking and deleting all simulation bakes (those ignore bake nodes). * The `Bake` node remembers which inputs have been fields and thus may be baked as attributes. For that it uses an `Is Attribute` flag on the socket item. This is needed because the baked data may still contain attribute data, even if the inputs to the bake node are disconnected. * Similar to simulation zones, the behavior of `Bake` nodes is passed into the geometry nodes evaluation from the outside (from the modifier only currently). This is done by providing the new `GeoNodesBakeParams` in `GeoNodesCallData` when executing geometry nodes. Next Steps (mostly because they also involve simulations): * Visualize nodes that have not been evaluated in the last evaluation. * Fix issue with seemingly loosing baked data after undo. * Improve error handling when baked data is not found. * Show bake node in link drag search. * Higher level tools for managing bakes. Pull Request: https://projects.blender.org/blender/blender/pulls/115466
2023-12-18 13:01:06 +01:00
/** Range spanning from the first to the last baked frame. */
IndexRange frame_range() const;
void reset();
};
struct SimulationNodeCache {
NodeBakeCache bake;
CacheStatus cache_status = CacheStatus::Valid;
/** Previous simulation state when only that is stored (instead of the state for every frame). */
std::optional<PrevCache> prev_cache;
void reset();
};
struct BakeNodeCache {
NodeBakeCache bake;
void reset();
};
struct ModifierCache {
mutable std::mutex mutex;
Geometry Nodes: new Bake node This adds a new `Bake` node which allows saving and loading intermediate geometries. Typical use cases we want address with this currently are: * Bake some data for use with a render engine. * Bake parts of the node tree explicitly for better performance. For now, the format that is written to disk is not considered to be an import/export format. It's not guaranteed that data written with one Blender version can be read by another Blender version. For that it's better to use proper interchange formats. Better support for those will be added eventually as well. We also plan an `Import Bake` node that allows reading the blender-specific baked data independent of the Bake node and at different frames. The baking works very similar to the baking in the simulation zone (UI and implementation wise). Major differences are: * The Bake node has a `Bake Still` and `Bake Animation` mode. * The Bake node doesn't do automatic caching. Implementation details: * Refactored how we create the Python operators for moving socket items so that it also makes sense for non-zones. * The `ModifierCache` stores an independent map of `SimulationNodeCache` and `BakeNodeCache`, but both share a common data structure for the actually baked data. * For baking, the `Bake` node is added as a side-effect-node in the modifier. This will make sure that the node is baked even if it's currently not connected to the output. * Had to add a new `DEG_id_tag_update_for_side_effect_request` function that is used during baking. It's necessary because I want to evaluate the object again even though none of its inputs changed. The reevaluation is necessary to create the baked data. Using `DEG_id_tag_update` technically works as well, but has the problem that it also uses the `DEG_UPDATE_SOURCE_USER_EDIT` flag which (rightly) invalidates simulation caches which shouldn't happen here. * Slightly refactored the timeline drawing so that it can also show the baked ranges of Bake nodes. It does not show anything for baked nodes with a in Still mode though. * The bake operator is refactored to bake a list of `NodeBakeRequest` which makes the code easier to follow compared to the previous nested `ObjectBakeData > ModifierBakeData > NodeBakeData` data structure. * The bake operators are disabled when the .blend file is not yet saved. This is technically only necessary when the bake path depends on the .blend file path but seems ok to force the user anyway (otherwise the bake path may be lost as well if it's set explicitly). * The same operators are used to bake and delete single bakes in `Bake` nodes and `Simulation Zones`. On top of that, there are separate operators of baking and deleting all simulation bakes (those ignore bake nodes). * The `Bake` node remembers which inputs have been fields and thus may be baked as attributes. For that it uses an `Is Attribute` flag on the socket item. This is needed because the baked data may still contain attribute data, even if the inputs to the bake node are disconnected. * Similar to simulation zones, the behavior of `Bake` nodes is passed into the geometry nodes evaluation from the outside (from the modifier only currently). This is done by providing the new `GeoNodesBakeParams` in `GeoNodesCallData` when executing geometry nodes. Next Steps (mostly because they also involve simulations): * Visualize nodes that have not been evaluated in the last evaluation. * Fix issue with seemingly loosing baked data after undo. * Improve error handling when baked data is not found. * Show bake node in link drag search. * Higher level tools for managing bakes. Pull Request: https://projects.blender.org/blender/blender/pulls/115466
2023-12-18 13:01:06 +01:00
/**
* Set of nested node IDs (see #bNestedNodeRef) that is expected to be baked in the next
* evaluation. This is filled and cleared by the bake operator.
*/
Set<int> requested_bakes;
Map<int, std::unique_ptr<SimulationNodeCache>> simulation_cache_by_id;
Geometry Nodes: new Bake node This adds a new `Bake` node which allows saving and loading intermediate geometries. Typical use cases we want address with this currently are: * Bake some data for use with a render engine. * Bake parts of the node tree explicitly for better performance. For now, the format that is written to disk is not considered to be an import/export format. It's not guaranteed that data written with one Blender version can be read by another Blender version. For that it's better to use proper interchange formats. Better support for those will be added eventually as well. We also plan an `Import Bake` node that allows reading the blender-specific baked data independent of the Bake node and at different frames. The baking works very similar to the baking in the simulation zone (UI and implementation wise). Major differences are: * The Bake node has a `Bake Still` and `Bake Animation` mode. * The Bake node doesn't do automatic caching. Implementation details: * Refactored how we create the Python operators for moving socket items so that it also makes sense for non-zones. * The `ModifierCache` stores an independent map of `SimulationNodeCache` and `BakeNodeCache`, but both share a common data structure for the actually baked data. * For baking, the `Bake` node is added as a side-effect-node in the modifier. This will make sure that the node is baked even if it's currently not connected to the output. * Had to add a new `DEG_id_tag_update_for_side_effect_request` function that is used during baking. It's necessary because I want to evaluate the object again even though none of its inputs changed. The reevaluation is necessary to create the baked data. Using `DEG_id_tag_update` technically works as well, but has the problem that it also uses the `DEG_UPDATE_SOURCE_USER_EDIT` flag which (rightly) invalidates simulation caches which shouldn't happen here. * Slightly refactored the timeline drawing so that it can also show the baked ranges of Bake nodes. It does not show anything for baked nodes with a in Still mode though. * The bake operator is refactored to bake a list of `NodeBakeRequest` which makes the code easier to follow compared to the previous nested `ObjectBakeData > ModifierBakeData > NodeBakeData` data structure. * The bake operators are disabled when the .blend file is not yet saved. This is technically only necessary when the bake path depends on the .blend file path but seems ok to force the user anyway (otherwise the bake path may be lost as well if it's set explicitly). * The same operators are used to bake and delete single bakes in `Bake` nodes and `Simulation Zones`. On top of that, there are separate operators of baking and deleting all simulation bakes (those ignore bake nodes). * The `Bake` node remembers which inputs have been fields and thus may be baked as attributes. For that it uses an `Is Attribute` flag on the socket item. This is needed because the baked data may still contain attribute data, even if the inputs to the bake node are disconnected. * Similar to simulation zones, the behavior of `Bake` nodes is passed into the geometry nodes evaluation from the outside (from the modifier only currently). This is done by providing the new `GeoNodesBakeParams` in `GeoNodesCallData` when executing geometry nodes. Next Steps (mostly because they also involve simulations): * Visualize nodes that have not been evaluated in the last evaluation. * Fix issue with seemingly loosing baked data after undo. * Improve error handling when baked data is not found. * Show bake node in link drag search. * Higher level tools for managing bakes. Pull Request: https://projects.blender.org/blender/blender/pulls/115466
2023-12-18 13:01:06 +01:00
Map<int, std::unique_ptr<BakeNodeCache>> bake_cache_by_id;
SimulationNodeCache *get_simulation_node_cache(const int id);
BakeNodeCache *get_bake_node_cache(const int id);
NodeBakeCache *get_node_bake_cache(const int id);
};
/**
* Reset all simulation caches in the scene, for use when some fundamental change made them
* impossible to reuse.
*/
void scene_simulation_states_reset(Scene &scene);
std::optional<BakePath> get_node_bake_path(const Main &bmain,
const Object &object,
const NodesModifierData &nmd,
int node_id);
std::optional<IndexRange> get_node_bake_frame_range(const Scene &scene,
const Object &object,
const NodesModifierData &nmd,
int node_id);
std::optional<std::string> get_modifier_bake_path(const Main &bmain,
const Object &object,
const NodesModifierData &nmd);
/**
* Get the directory that contains all baked data for the given modifier by default.
*/
std::string get_default_modifier_bake_directory(const Main &bmain,
const Object &object,
const NodesModifierData &nmd);
} // namespace blender::bke::bake