tmaq
/
tornavis
1
0
Fork 0
Code Issues 2 Pull Requests 29 Packages Projects 24 Releases Wiki Activity
tornavis/source/blender/blenkernel/BKE_bake_items_socket.hh

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

75 lines
2.6 KiB
C++
Raw Normal View History

License Headers: Set copyright to "Blender Authors", add AUTHORS Listing the "Blender Foundation" as copyright holder implied the Blender Foundation holds copyright to files which may include work from many developers. While keeping copyright on headers makes sense for isolated libraries, Blender's own code may be refactored or moved between files in a way that makes the per file copyright holders less meaningful. Copyright references to the "Blender Foundation" have been replaced with "Blender Authors", with the exception of `./extern/` since these this contains libraries which are more isolated, any changed to license headers there can be handled on a case-by-case basis. Some directories in `./intern/` have also been excluded: - `./intern/cycles/` it's own `AUTHORS` file is planned. - `./intern/opensubdiv/`. An "AUTHORS" file has been added, using the chromium projects authors file as a template. Design task: #110784 Ref !110783.
2023-08-15 16:20:26 +02:00
/* SPDX-FileCopyrightText: 2023 Blender Authors
Geometry Nodes: extract bake items from simulation baking The goal is to reuse the same bake items for simulation and normal baking (#110137). Previously, the bake data was tied to a simulation state which made it harder to reuse. Now the code for the following things can be reused easily: - Convert geometry node socket values into bake items and back. - Serialize and deserialize bake items. Pull Request: https://projects.blender.org/blender/blender/pulls/110577
2023-07-28 18:30:32 +02:00
*
* SPDX-License-Identifier: GPL-2.0-or-later */
#pragma once
#include "BLI_function_ref.hh"
#include "DNA_node_types.h"
#include "BKE_bake_items.hh"
#include "BKE_geometry_fields.hh"
Cleanup: move bake items code to separate namespace
2023-09-03 13:37:24 +02:00
namespace blender::bke::bake {
Geometry Nodes: extract bake items from simulation baking The goal is to reuse the same bake items for simulation and normal baking (#110137). Previously, the bake data was tied to a simulation state which made it harder to reuse. Now the code for the following things can be reused easily: - Convert geometry node socket values into bake items and back. - Serialize and deserialize bake items. Pull Request: https://projects.blender.org/blender/blender/pulls/110577
2023-07-28 18:30:32 +02:00
/**
* Describes how bake items should be mapped to sockets.
*/
struct BakeSocketConfig {
/** The type of every socket. */
Vector<eNodeSocketDatatype> types;
/**
* The domain on which an the attribute corresponding to the socket should be stored (only used
* for some socket types).
*/
Cleanup: Move attribute domain enum to C++ header, use enum class Each value is now out of the global namespace, so they can be shorter and easier to read. Most of this commit just adds the necessary casting and namespace specification. `enum class` can be forward declared since it has a specified size. We will make use of that in the next commit.
2023-12-20 19:13:16 +01:00
Vector<AttrDomain> domains;
Geometry Nodes: store bake item names on disk Bake items are generally identified by their (generated) identifier. This allows changing the name and reordering sockets without breaking baked data. In the future we want to have some kind of Import Bake node that ideally automatically creates its output sockets and names them correctly. For that to work, the baked data has to contain the user-defined names for each socket. Those names are not used yet.
2024-02-02 10:02:25 +01:00
/** User-defined name of every socket. */
Vector<StringRef> names;
Geometry Nodes: extract bake items from simulation baking The goal is to reuse the same bake items for simulation and normal baking (#110137). Previously, the bake data was tied to a simulation state which made it harder to reuse. Now the code for the following things can be reused easily: - Convert geometry node socket values into bake items and back. - Serialize and deserialize bake items. Pull Request: https://projects.blender.org/blender/blender/pulls/110577
2023-07-28 18:30:32 +02:00
/**
* Determines which geometries a field socket should be evaluated on. This can be used to
* implement rules like a field should only be evaluated on the preceding or on all geometries.
*/
Vector<Vector<int, 1>> geometries_by_attribute;
};
/**
* Create new bake items from the socket values. The socket values are not destructed, but they may
* be in a moved-from state afterwards.
*/
Geometry Nodes: support baking data block references With this patch, materials are kept intact in simulation zones and bake nodes without any additional user action. This implements the design proposed in #108410 to support referencing data-blocks (only materials for now) in the baked data. The task also describes why this is not a trivial issue. A previous attempt was implemented in #109703 but it didn't work well-enough. The solution is to have an explicit `name (+ library name) -> data-block` mapping that is stored in the modifier for each bake node and simulation zone. The `library name` is necessary for it to be unique within a .blend file. Note that this refers to the name of the `Library` data-block and not a file path. The baked data only contains the names of the used data-blocks. When the baked data is loaded, the correct material data-block is looked up from the mapping. ### Automatic Mapping Generation The most tricky aspect of this approach is to make it feel mostly automatic. From the user point-of-view, it should just work. Therefore, we don't want the user to have to create the mapping manually in the majority of cases. Creating the mapping automatically is difficult because the data-blocks that should become part of the mapping are only known during depsgraph evaluation. So we somehow have to gather the missing data blocks during evaluation and then write the new mappings back to the original data. While writing back to original data is something we do in some cases already, the situation here is different, because we are actually creating new relations between data-blocks. This also means that we'll have to do user-counting. Since user counts in data-blocks are *not* atomic, we can't do that from multiple threads at the same time. Also, under some circumstances, it may be necessary to trigger depsgraph evaluation again after the write-back because it actually affects the result. To solve this, a small new API is added in `DEG_depsgraph_writeback_sync.hh`. It allows gathering tasks which write back to original data in a synchronous way which may also require a reevaluation. ### Accessing the Mapping A new `BakeDataBlockMap` is passed to geometry nodes evaluation by the modifier. This map allows getting the `ID` pointer that should be used for a specific data-block name that is stored in baked data. It's also used to gather all the missing data mappings during evaluation. ### Weak ID References The baked/cached geometries may have references to other data-blocks (currently only materials, but in the future also e.g. instanced objects/collections). However, the pointers of these data-blocks are not stable over time. That is especially true when storing/loading the data from disk, but also just when playing back the animation. Therefore, the used data-blocks have to referenced in a different way at run-time. This is solved by adding `std::unique_ptr<bake::BakeMaterialsList>` to the run-time data of various geometry data-blocks. If the data-block is cached over a longer period of time (such that material pointers can't be used directly), it stores the material name (+ library name) used by each material slot. When the geometry is used again, the material pointers are restored using these weak name references and the `BakeDataBlockMap`. ### Manual Mapping Management There is a new `Data-Blocks` panel in the bake settings in the node editor sidebar that allows inspecting and modifying the data-blocks that are used when baking. The user can change what data-block a specific name is mapped to. Pull Request: https://projects.blender.org/blender/blender/pulls/117043
2024-02-01 09:21:55 +01:00
Array<std::unique_ptr<BakeItem>> move_socket_values_to_bake_items(
Span<void *> socket_values, const BakeSocketConfig &config, BakeDataBlockMap *data_block_map);
Geometry Nodes: extract bake items from simulation baking The goal is to reuse the same bake items for simulation and normal baking (#110137). Previously, the bake data was tied to a simulation state which made it harder to reuse. Now the code for the following things can be reused easily: - Convert geometry node socket values into bake items and back. - Serialize and deserialize bake items. Pull Request: https://projects.blender.org/blender/blender/pulls/110577
2023-07-28 18:30:32 +02:00
/**
* Create socket values from bake items.
* - The data stored in the bake items may be in a moved-from state afterwards. Therefore, this
* should only be used when the bake items are not needed afterwards anymore.
* - If a socket does not have a corresponding bake item, it's initialized to its default value.
*
* \param make_attribute_field: A function that creates a field input for any anonymous attributes
* being created for the baked data.
* \param r_socket_values: The caller is expected to allocate (but not construct) the output
* values. All socket values are constructed in this function.
*/
void move_bake_items_to_socket_values(
Span<BakeItem *> bake_items,
const BakeSocketConfig &config,
Geometry Nodes: support baking data block references With this patch, materials are kept intact in simulation zones and bake nodes without any additional user action. This implements the design proposed in #108410 to support referencing data-blocks (only materials for now) in the baked data. The task also describes why this is not a trivial issue. A previous attempt was implemented in #109703 but it didn't work well-enough. The solution is to have an explicit `name (+ library name) -> data-block` mapping that is stored in the modifier for each bake node and simulation zone. The `library name` is necessary for it to be unique within a .blend file. Note that this refers to the name of the `Library` data-block and not a file path. The baked data only contains the names of the used data-blocks. When the baked data is loaded, the correct material data-block is looked up from the mapping. ### Automatic Mapping Generation The most tricky aspect of this approach is to make it feel mostly automatic. From the user point-of-view, it should just work. Therefore, we don't want the user to have to create the mapping manually in the majority of cases. Creating the mapping automatically is difficult because the data-blocks that should become part of the mapping are only known during depsgraph evaluation. So we somehow have to gather the missing data blocks during evaluation and then write the new mappings back to the original data. While writing back to original data is something we do in some cases already, the situation here is different, because we are actually creating new relations between data-blocks. This also means that we'll have to do user-counting. Since user counts in data-blocks are *not* atomic, we can't do that from multiple threads at the same time. Also, under some circumstances, it may be necessary to trigger depsgraph evaluation again after the write-back because it actually affects the result. To solve this, a small new API is added in `DEG_depsgraph_writeback_sync.hh`. It allows gathering tasks which write back to original data in a synchronous way which may also require a reevaluation. ### Accessing the Mapping A new `BakeDataBlockMap` is passed to geometry nodes evaluation by the modifier. This map allows getting the `ID` pointer that should be used for a specific data-block name that is stored in baked data. It's also used to gather all the missing data mappings during evaluation. ### Weak ID References The baked/cached geometries may have references to other data-blocks (currently only materials, but in the future also e.g. instanced objects/collections). However, the pointers of these data-blocks are not stable over time. That is especially true when storing/loading the data from disk, but also just when playing back the animation. Therefore, the used data-blocks have to referenced in a different way at run-time. This is solved by adding `std::unique_ptr<bake::BakeMaterialsList>` to the run-time data of various geometry data-blocks. If the data-block is cached over a longer period of time (such that material pointers can't be used directly), it stores the material name (+ library name) used by each material slot. When the geometry is used again, the material pointers are restored using these weak name references and the `BakeDataBlockMap`. ### Manual Mapping Management There is a new `Data-Blocks` panel in the bake settings in the node editor sidebar that allows inspecting and modifying the data-blocks that are used when baking. The user can change what data-block a specific name is mapped to. Pull Request: https://projects.blender.org/blender/blender/pulls/117043
2024-02-01 09:21:55 +01:00
BakeDataBlockMap *data_block_map,
Geometry Nodes: extract bake items from simulation baking The goal is to reuse the same bake items for simulation and normal baking (#110137). Previously, the bake data was tied to a simulation state which made it harder to reuse. Now the code for the following things can be reused easily: - Convert geometry node socket values into bake items and back. - Serialize and deserialize bake items. Pull Request: https://projects.blender.org/blender/blender/pulls/110577
2023-07-28 18:30:32 +02:00
FunctionRef<std::shared_ptr<AnonymousAttributeFieldInput>(int socket_index, const CPPType &)>
make_attribute_field,
Span<void *> r_socket_values);
/**
* Similar to #move_bake_items_to_socket_values, but does not change the bake items. Hence, this
* should be used when the bake items are still used later on.
*/
void copy_bake_items_to_socket_values(
Span<const BakeItem *> bake_items,
const BakeSocketConfig &config,
Geometry Nodes: support baking data block references With this patch, materials are kept intact in simulation zones and bake nodes without any additional user action. This implements the design proposed in #108410 to support referencing data-blocks (only materials for now) in the baked data. The task also describes why this is not a trivial issue. A previous attempt was implemented in #109703 but it didn't work well-enough. The solution is to have an explicit `name (+ library name) -> data-block` mapping that is stored in the modifier for each bake node and simulation zone. The `library name` is necessary for it to be unique within a .blend file. Note that this refers to the name of the `Library` data-block and not a file path. The baked data only contains the names of the used data-blocks. When the baked data is loaded, the correct material data-block is looked up from the mapping. ### Automatic Mapping Generation The most tricky aspect of this approach is to make it feel mostly automatic. From the user point-of-view, it should just work. Therefore, we don't want the user to have to create the mapping manually in the majority of cases. Creating the mapping automatically is difficult because the data-blocks that should become part of the mapping are only known during depsgraph evaluation. So we somehow have to gather the missing data blocks during evaluation and then write the new mappings back to the original data. While writing back to original data is something we do in some cases already, the situation here is different, because we are actually creating new relations between data-blocks. This also means that we'll have to do user-counting. Since user counts in data-blocks are *not* atomic, we can't do that from multiple threads at the same time. Also, under some circumstances, it may be necessary to trigger depsgraph evaluation again after the write-back because it actually affects the result. To solve this, a small new API is added in `DEG_depsgraph_writeback_sync.hh`. It allows gathering tasks which write back to original data in a synchronous way which may also require a reevaluation. ### Accessing the Mapping A new `BakeDataBlockMap` is passed to geometry nodes evaluation by the modifier. This map allows getting the `ID` pointer that should be used for a specific data-block name that is stored in baked data. It's also used to gather all the missing data mappings during evaluation. ### Weak ID References The baked/cached geometries may have references to other data-blocks (currently only materials, but in the future also e.g. instanced objects/collections). However, the pointers of these data-blocks are not stable over time. That is especially true when storing/loading the data from disk, but also just when playing back the animation. Therefore, the used data-blocks have to referenced in a different way at run-time. This is solved by adding `std::unique_ptr<bake::BakeMaterialsList>` to the run-time data of various geometry data-blocks. If the data-block is cached over a longer period of time (such that material pointers can't be used directly), it stores the material name (+ library name) used by each material slot. When the geometry is used again, the material pointers are restored using these weak name references and the `BakeDataBlockMap`. ### Manual Mapping Management There is a new `Data-Blocks` panel in the bake settings in the node editor sidebar that allows inspecting and modifying the data-blocks that are used when baking. The user can change what data-block a specific name is mapped to. Pull Request: https://projects.blender.org/blender/blender/pulls/117043
2024-02-01 09:21:55 +01:00
BakeDataBlockMap *data_block_map,
Geometry Nodes: extract bake items from simulation baking The goal is to reuse the same bake items for simulation and normal baking (#110137). Previously, the bake data was tied to a simulation state which made it harder to reuse. Now the code for the following things can be reused easily: - Convert geometry node socket values into bake items and back. - Serialize and deserialize bake items. Pull Request: https://projects.blender.org/blender/blender/pulls/110577
2023-07-28 18:30:32 +02:00
FunctionRef<std::shared_ptr<AnonymousAttributeFieldInput>(int, const CPPType &)>
make_attribute_field,
Span<void *> r_socket_values);
Cleanup: move bake items code to separate namespace
2023-09-03 13:37:24 +02:00
} // namespace blender::bke::bake