griefith/test2
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
fdfd1de9a856461c22834d5efdd393e24756f9d5
test2/source/blender/modifiers/intern/MOD_nodes.cc

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

3107 lines
115 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-16 00:20:26 +10:00
/* SPDX-FileCopyrightText: 2005 Blender Authors
Cleanup: Add a copyright notice to files and use SPDX format A lot of files were missing copyright field in the header and the Blender Foundation contributed to them in a sense of bug fixing and general maintenance. This change makes it explicit that those files are at least partially copyrighted by the Blender Foundation. Note that this does not make it so the Blender Foundation is the only holder of the copyright in those files, and developers who do not have a signed contract with the foundation still hold the copyright as well. Another aspect of this change is using SPDX format for the header. We already used it for the license specification, and now we state it for the copyright as well, following the FAQ: https://reuse.software/faq/
2023-05-31 16:19:06 +02:00
*
* SPDX-License-Identifier: GPL-2.0-or-later */
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
/** \file
* \ingroup modifiers
*/
#include <cstring>
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
#include <fmt/format.h>
Cleanup: fewer iostreams related includes from BLI/BKE headers Including <iostream> or similar headers is quite expensive, since it also pulls in things like <locale> and so on. In many BLI headers, iostreams are only used to implement some sort of "debug print", or an operator<< for ostream. Change some of the commonly used places to instead include <iosfwd>, which is the standard way of forward-declaring iostreams related classes, and move the actual debug-print / operator<< implementations into .cc files. This is not done for templated classes though (it would be possible to provide explicit operator<< instantiations somewhere in the source file, but that would lead to hard-to-figure-out linker error whenever someone would add a different template type). There, where possible, I changed from full <iostream> include to only the needed <ostream> part. For Span<T>, I just removed print_as_lines since it's not used by anything. It could be moved into a .cc file using a similar approach as above if needed. Doing full blender build changes include counts this way: - <iostream> 1986 -> 978 - <sstream> 2880 -> 925 It does not affect the total build time much though, mostly because towards the end of it there's just several CPU cores finishing compiling OpenVDB related source files. Pull Request: https://projects.blender.org/blender/blender/pulls/111046
2023-08-11 12:27:56 +03:00
#include <sstream>
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
#include <string>
#include "MEM_guardedalloc.h"
#include "BLI_listbase.h"
Spreadsheet: breadcrumbs and node pinning This introduces a context path to the spreadsheet editor, which contains information about what data is shown in the spreadsheet. The context path (breadcrumbs) can reference a specific node in a node group hierarchy. During object evaluation, the geometry nodes modifier checks what data is currently requested by visible spreadsheets and stores the corresponding geometry sets separately for later access. The context path can be updated by the user explicitely, by clicking on the new icon in the header of nodes. Under some circumstances, the context path is updated automatically based on Blender's context. This patch also consolidates the "Node" and "Final" object evaluation mode to just "Evaluated". Based on the current context path, either the final geometry set of an object will be displayed, or the data at a specific node. The new preview icon in geometry nodes now behaves more like a toggle. It can be clicked again to clear the context path in an open spreadsheet editor. Previously, only an object could be pinned in the spreadsheet editor. Now it is possible to pin the entire context path. That allows two different spreadsheets to display geometry data from two different nodes. The breadcrumbs in the spreadsheet header can be collapsed by clicking on the arrow icons. It's not ideal but works well for now. This might be changed again, if we get a data set region on the left. Differential Revision: https://developer.blender.org/D10931
2021-04-15 08:57:10 +02:00
#include "BLI_multi_value_map.hh"
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
#include "BLI_set.hh"
#include "BLI_string.h"
#include "BLI_utildefines.h"
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
#include "DNA_array_utils.hh"
Cleanup: reduce indirect DNA header inclusion Remove DNA headers, using forward declarations where possible. Also removed duplicate header, header including it's self and unnecessary inclusion of libc system headers from BKE header.
2020-12-15 10:47:58 +11:00
#include "DNA_collection_types.h"
Curves: support deforming curves on surface Curves that are attached to a surface can now follow the surface when it is modified using shape keys or modifiers (but not when the original surface is deformed in edit or sculpt mode). The surface is allowed to be changed in any way that keeps uv maps intact. So deformation is allowed, but also some topology changes like subdivision. The following features are added: * A new `Deform Curves on Surface` node, which deforms curves with attachment information based on the surface object and uv map set in the properties panel. * A new `Add Rest Position` checkbox in the shape keys panel. When checked, a new `rest_position` vector attribute is added to the mesh before shape keys and modifiers are applied. This is necessary to support proper deformation of the curves, but can also be used for other purposes. * The `Add > Curve > Empty Hair` operator now sets up a simple geometry nodes setup that deforms the hair. It also makes sure that the rest position attribute is added to the surface. * A new `Object (Attach Curves to Surface)` operator in the `Set Parent To` (ctrl+P) menu, which attaches existing curves to the surface and sets the surface object as parent. Limitations: * Sculpting the procedurally deformed curves will be implemented separately. * The `Deform Curves on Surface` node is not generic and can only be used for one specific purpose currently. We plan to generalize this more in the future by adding support by exposing more inputs and/or by turning it into a node group. Differential Revision: https://developer.blender.org/D14864
2022-07-08 14:45:48 +02:00
#include "DNA_curves_types.h"
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
#include "DNA_defaults.h"
Geometry Nodes: Expose texture and material inputs to modifier This allows choosing material and texture sockets for the group input node in the modifier. Note that currently grease pencil materials are displayed in the list, even though grease pencil data is not supported yet by geometry nodes. That is more complicated to fix in this case, since we use IDProperties to store the dynamic exposed inputs. Differential Revision: https://developer.blender.org/D11393
2021-05-27 11:06:08 -04:00
#include "DNA_material_types.h"
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
#include "DNA_mesh_types.h"
#include "DNA_modifier_types.h"
#include "DNA_node_types.h"
#include "DNA_object_types.h"
#include "DNA_pointcloud_types.h"
#include "DNA_scene_types.h"
#include "DNA_screen_types.h"
Spreadsheet: support showing data of specific node Previously, the spreadsheet editor could only show data of the original and of the final evaluated object. Now it is possible to show the data at some intermediate stages too. For that the mode has to be set to "Node" in the spreadsheet editor. Furthermore, the preview of a specific node has to be activated by clicking the new icon in the header of geometry nodes. The exact ui of this feature might be refined in upcoming commits. It is already very useful for debugging node groups in it's current state though. Differential Revision: https://developer.blender.org/D10875
2021-04-08 17:35:06 +02:00
#include "DNA_space_types.h"
Geometry Nodes: viewport preview This adds support for showing geometry passed to the Viewer in the 3d viewport (instead of just in the spreadsheet). The "viewer geometry" bypasses the group output. So it is not necessary to change the final output of the node group to be able to see the intermediate geometry. **Activation and deactivation of a viewer node** * A viewer node is activated by clicking on it. * Ctrl+shift+click on any node/socket connects it to the viewer and makes it active. * Ctrl+shift+click in empty space deactivates the active viewer. * When the active viewer is not visible anymore (e.g. another object is selected, or the current node group is exit), it is deactivated. * Clicking on the icon in the header of the Viewer node toggles whether its active or not. **Pinning** * The spreadsheet still allows pinning the active viewer as before. When pinned, the spreadsheet still references the viewer node even when it becomes inactive. * The viewport does not support pinning at the moment. It always shows the active viewer. **Attribute** * When a field is linked to the second input of the viewer node it is displayed as an overlay in the viewport. * When possible the correct domain for the attribute is determined automatically. This does not work in all cases. It falls back to the face corner domain on meshes and the point domain on curves. When necessary, the domain can be picked manually. * The spreadsheet now only shows the "Viewer" column for the domain that is selected in the Viewer node. * Instance attributes are visualized as a constant color per instance. **Viewport Options** * The attribute overlay opacity can be controlled with the "Viewer Node" setting in the overlays popover. * A viewport can be configured not to show intermediate viewer-geometry by disabling the "Viewer Node" option in the "View" menu. **Implementation Details** * The "spreadsheet context path" was generalized to a "viewer path" that is used in more places now. * The viewer node itself determines the attribute domain, evaluates the field and stores the result in a `.viewer` attribute. * A new "viewer attribute' overlay displays the data from the `.viewer` attribute. * The ground truth for the active viewer node is stored in the workspace now. Node editors, spreadsheets and viewports retrieve the active viewer from there unless they are pinned. * The depsgraph object iterator has a new "viewer path" setting. When set, the viewed geometry of the corresponding object is part of the iterator instead of the final evaluated geometry. * To support the instance attribute overlay `DupliObject` was extended to contain the information necessary for drawing the overlay. * The ctrl+shift+click operator has been refactored so that it can make existing links to viewers active again. * The auto-domain-detection in the Viewer node works by checking the "preferred domain" for every field input. If there is not exactly one preferred domain, the fallback is used. Known limitations: * Loose edges of meshes don't have the attribute overlay. This could be added separately if necessary. * Some attributes are hard to visualize as a color directly. For example, the values might have to be normalized or some should be drawn as arrays. For now, we encourage users to build node groups that generate appropriate viewer-geometry. We might include some of that functionality in future versions. Support for displaying attribute values as text in the viewport is planned as well. * There seems to be an issue with the attribute overlay for pointclouds on nvidia gpus, to be investigated. Differential Revision: https://developer.blender.org/D15954
2022-09-28 17:54:59 +02:00
#include "DNA_view3d_types.h"
Spreadsheet: support showing data of specific node Previously, the spreadsheet editor could only show data of the original and of the final evaluated object. Now it is possible to show the data at some intermediate stages too. For that the mode has to be set to "Node" in the spreadsheet editor. Furthermore, the preview of a specific node has to be activated by clicking the new icon in the header of geometry nodes. The exact ui of this feature might be refined in upcoming commits. It is already very useful for debugging node groups in it's current state though. Differential Revision: https://developer.blender.org/D10875
2021-04-08 17:35:06 +02:00
#include "DNA_windowmanager_types.h"
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
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
#include "BKE_bake_data_block_map.hh"
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
#include "BKE_bake_geometry_nodes_modifier.hh"
Refactor: Geometry Nodes: replace ComputeContextBuilder with ComputeContextCache While `ComputeContextBuilder` worked well for building simple linear compute contexts, it was fairly limiting for all the slightly more complex cases where an entire tree of compute contexts is built. Using `ComputeContextCache` that is easier to do more explicitly. There were only very few cases where using `ComputeContextBuilder` would have still helped a bit, but it's not really worth keeping that abstraction around just for those few cases. Pull Request: https://projects.blender.org/blender/blender/pulls/137370
2025-04-14 17:47:56 +02:00
#include "BKE_compute_context_cache.hh"
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
#include "BKE_compute_contexts.hh"
Cleanup: Move several blenkernel headers to C++ Mostly focus on areas where we're already using C++ features, where combining C and C++ APIs is getting in the way. Pull Request: https://projects.blender.org/blender/blender/pulls/114972
2023-11-16 11:41:55 +01:00
#include "BKE_customdata.hh"
Cleanup: Make `BKE_global.h` a Cpp header.
2024-02-10 18:25:14 +01:00
#include "BKE_global.hh"
Cleanup: Move BKE_idprop.h to C++
2024-03-26 12:57:30 -04:00
#include "BKE_idprop.hh"
Cleanup: Move BKE_lib_id.h to C++
2024-01-15 12:44:04 -05:00
#include "BKE_lib_id.hh"
Cleanup: Move `BKE_lib_query` header to Cpp era.
2024-01-18 12:20:42 +01:00
#include "BKE_lib_query.hh"
BKE_main: move header to be a fully CPP one. Pull Request: https://projects.blender.org/blender/blender/pulls/115681
2023-12-01 19:43:16 +01:00
#include "BKE_main.hh"
Mesh: Move functions to C++ header Refactoring mesh code, it has become clear that local cleanups and simplifications are limited by the need to keep a C public API for mesh functions. This change makes code more obvious and makes further refactoring much easier. - Add a new `BKE_mesh.hh` header for a C++ only mesh API - Introduce a new `blender::bke::mesh` namespace, documented here: https://wiki.blender.org/wiki/Source/Objects/Mesh#Namespaces - Move some functions to the new namespace, cleaning up their arguments - Move code to `Array` and `float3` where necessary to use the new API - Define existing inline mesh data access functions to the new header - Keep some C API functions where necessary because of RNA - Move all C++ files to use the new header, which includes the old one In the future it may make sense to split up `BKE_mesh.hh` more, but for now keeping the same name as the existing header keeps things simple. Pull Request: https://projects.blender.org/blender/blender/pulls/105416
2023-03-12 22:29:15 +01:00
#include "BKE_mesh.hh"
Cleanup: Move BKE_modifier.h to C++
2023-11-14 09:30:40 +01:00
#include "BKE_modifier.hh"
Cleanup: Move legacy node integer types defines to separate header Moving these defines to a separate header makes their "legacy" status more obvious. This commit just adds the include wherever necessary. Followup to 971c96a92cfc46c8f1e9137f1812863fdc392096. Pull Request: https://projects.blender.org/blender/blender/pulls/132875
2025-01-09 20:03:08 +01:00
#include "BKE_node_legacy_types.hh"
Nodes: add separately allocated run-time data for bNodeTree `bNodeTree` has a lot of run-time embedded in it currently. Having a separately allocated run-time struct has some benefits: * Run-time data is not stored in files. * Makes it easy to use c++ types as run-time data. * More clear distinction between what data only exists at run-time and which doesn't. This commit doesn't move all run-time data to the new struct yet, only the data where I know for sure how it is used. The remaining data can be moved separately. Differential Revision: https://developer.blender.org/D15033
2022-05-30 12:54:07 +02:00
#include "BKE_node_runtime.hh"
Cleanup: Move several blenkernel headers to C++ Mostly focus on areas where we're already using C++ features, where combining C and C++ APIs is getting in the way. Pull Request: https://projects.blender.org/blender/blender/pulls/114972
2023-11-16 11:41:55 +01:00
#include "BKE_node_tree_update.hh"
Cleanup: Move BKE_object.hh to C++ Simplifies the fix to #111120, where the object bounds functions may return a C++ type instead of `BoundBox`. Pull Request: https://projects.blender.org/blender/blender/pulls/113462
2023-10-09 23:41:53 +02:00
#include "BKE_object.hh"
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
#include "BKE_packedFile.hh"
Cleanup: move BKE_pointcloud.h to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/116990
2024-01-11 10:54:47 +01:00
#include "BKE_pointcloud.hh"
Cleanup: Move BKE_screen.h to C++ See #103343
2023-09-25 17:48:21 -04:00
#include "BKE_screen.hh"
Cleanup: Move BKE_workspace.h to C++
2024-04-12 17:03:18 -04:00
#include "BKE_workspace.hh"
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
Cleanup: Move BLO headers to C++ Except for BLO_readfile.h, which is still included by C files. Pull Request: https://projects.blender.org/blender/blender/pulls/111610
2023-08-28 15:01:05 +02:00
#include "BLO_read_write.hh"
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
#include "UI_interface.hh"
Cleanup: Move editors headers to C++ See #103343 Pull Request: https://projects.blender.org/blender/blender/pulls/110820
2023-08-05 02:57:52 +02:00
#include "UI_resources.hh"
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
Clenup: Move BLT headers to Cpp. Noisy but fairly straight forward.
2024-02-09 18:59:42 +01:00
#include "BLT_translation.hh"
Geometry Nodes: Add legacy warning and "View Legacy" operator This commit adds warning messages to "legacy" nodes that will be removed in the future. The warning is shown in the node header, but it is not printed in the terminal or displayed in the modifier. It is also not propogated to node groups, but that is a more general task. If the modifier's node tree has executed a deprecated node, it will display a warning and a "Search" button that will select the nodes and pan to them in the node editor. This doesn't open child node trees and select nodes in there, because I want to keep this operator simple and avoid wasting a lot of time perfecting this behavior. Differential Revision: https://developer.blender.org/D12454
2021-09-21 17:17:40 -05:00
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
#include "WM_api.hh"
Cleanup: Move WM headers to C++ Also move a few more headers that included WM headers. Pull Request: https://projects.blender.org/blender/blender/pulls/110815
2023-08-04 23:11:22 +02:00
#include "WM_types.hh"
Geometry Nodes: Add a toggle to use attributes as input values This adds a toggle to node group inputs exposed in the modifier to use an attribute instead of a single value. When the toggle is pressed, the button switches to a text button to choose an attribute name. Attribute search isn't implemented here yet. One confusing thing is that some values can't be driven by attributes at all, like the size of a primitive node. In that case, we should have a node warning, but that will be separate since it's more general. We can also have an option to turn off this toggle in node group input settings. The two new properties for each input are stored with the same name as the value, but with `"_use_attribute"` and `"_attribute_name"`` suffixes. The properties are not added for socket types that don't support attribute input, like object sockets. Differential Revision: https://developer.blender.org/D12504
2021-09-16 20:49:10 -05:00
RNA: move headers to C++ Also see #103343. Pull Request: https://projects.blender.org/blender/blender/pulls/111022
2023-08-10 22:40:27 +02:00
#include "RNA_access.hh"
#include "RNA_enum_types.hh"
Refactor: Makesrna: move generated code further in C++. This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and `RNA_blender_cpp.h` headers to become C++ header files. It also removes the now useless `RNA_EXTERN_C` defines, and just directly use the `extern` keyword. We do not need anymore `extern "C"` declarations here. Pull Request: https://projects.blender.org/blender/blender/pulls/124469
2024-07-10 18:30:02 +02:00
#include "RNA_prototypes.hh"
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
Cleanup: Move depsgraph headers to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/110816
2023-09-22 03:18:17 +02:00
#include "DEG_depsgraph_build.hh"
#include "DEG_depsgraph_query.hh"
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
#include "DEG_depsgraph_writeback_sync.hh"
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
Cleanup: Move remaining modifier files to C++ See #103343 Pull Request: https://projects.blender.org/blender/blender/pulls/107626
2023-05-04 18:35:37 +02:00
#include "MOD_modifiertypes.hh"
Cleanup: move MOD_nodes.h to C++ All files that use it are in C++ now.
2023-07-10 13:14:15 +02:00
#include "MOD_nodes.hh"
Cleanup: Move remaining modifier files to C++ See #103343 Pull Request: https://projects.blender.org/blender/blender/pulls/107626
2023-05-04 18:35:37 +02:00
#include "MOD_ui_common.hh"
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
Refactor: Geometry Nodes: simplify getting compute context for edittree This adds a simple `compute_context_for_edittree` function that returns the "active" compute context for the given node editor. This is used in various places, but previously one had to construct the compute context in multiple steps (first find the root context (modifier/operator), then handle the tree path). Since the edittree already has a specific active context, there should be an easy way to retrieve that. This also adds a few extra check that avoid redundant work that was done before. Pull Request: https://projects.blender.org/blender/blender/pulls/137525
2025-04-15 15:24:29 +02:00
#include "ED_node.hh"
Cleanup: Move editors headers to C++ See #103343 Pull Request: https://projects.blender.org/blender/blender/pulls/110820
2023-08-05 02:57:52 +02:00
#include "ED_object.hh"
Cleanup: Move WM headers to C++ Also move a few more headers that included WM headers. Pull Request: https://projects.blender.org/blender/blender/pulls/110815
2023-08-04 23:11:22 +02:00
#include "ED_screen.hh"
Cleanup: Move editors headers to C++ See #103343 Pull Request: https://projects.blender.org/blender/blender/pulls/110820
2023-08-05 02:57:52 +02:00
#include "ED_undo.hh"
Geometry Nodes: viewport preview This adds support for showing geometry passed to the Viewer in the 3d viewport (instead of just in the spreadsheet). The "viewer geometry" bypasses the group output. So it is not necessary to change the final output of the node group to be able to see the intermediate geometry. **Activation and deactivation of a viewer node** * A viewer node is activated by clicking on it. * Ctrl+shift+click on any node/socket connects it to the viewer and makes it active. * Ctrl+shift+click in empty space deactivates the active viewer. * When the active viewer is not visible anymore (e.g. another object is selected, or the current node group is exit), it is deactivated. * Clicking on the icon in the header of the Viewer node toggles whether its active or not. **Pinning** * The spreadsheet still allows pinning the active viewer as before. When pinned, the spreadsheet still references the viewer node even when it becomes inactive. * The viewport does not support pinning at the moment. It always shows the active viewer. **Attribute** * When a field is linked to the second input of the viewer node it is displayed as an overlay in the viewport. * When possible the correct domain for the attribute is determined automatically. This does not work in all cases. It falls back to the face corner domain on meshes and the point domain on curves. When necessary, the domain can be picked manually. * The spreadsheet now only shows the "Viewer" column for the domain that is selected in the Viewer node. * Instance attributes are visualized as a constant color per instance. **Viewport Options** * The attribute overlay opacity can be controlled with the "Viewer Node" setting in the overlays popover. * A viewport can be configured not to show intermediate viewer-geometry by disabling the "Viewer Node" option in the "View" menu. **Implementation Details** * The "spreadsheet context path" was generalized to a "viewer path" that is used in more places now. * The viewer node itself determines the attribute domain, evaluates the field and stores the result in a `.viewer` attribute. * A new "viewer attribute' overlay displays the data from the `.viewer` attribute. * The ground truth for the active viewer node is stored in the workspace now. Node editors, spreadsheets and viewports retrieve the active viewer from there unless they are pinned. * The depsgraph object iterator has a new "viewer path" setting. When set, the viewed geometry of the corresponding object is part of the iterator instead of the final evaluated geometry. * To support the instance attribute overlay `DupliObject` was extended to contain the information necessary for drawing the overlay. * The ctrl+shift+click operator has been refactored so that it can make existing links to viewers active again. * The auto-domain-detection in the Viewer node works by checking the "preferred domain" for every field input. If there is not exactly one preferred domain, the fallback is used. Known limitations: * Loose edges of meshes don't have the attribute overlay. This could be added separately if necessary. * Some attributes are hard to visualize as a color directly. For example, the values might have to be normalized or some should be drawn as arrays. For now, we encourage users to build node groups that generate appropriate viewer-geometry. We might include some of that functionality in future versions. Support for displaying attribute values as text in the viewport is planned as well. * There seems to be an issue with the attribute overlay for pointclouds on nvidia gpus, to be investigated. Differential Revision: https://developer.blender.org/D15954
2022-09-28 17:54:59 +02:00
#include "ED_viewer_path.hh"
Spreadsheet: breadcrumbs and node pinning This introduces a context path to the spreadsheet editor, which contains information about what data is shown in the spreadsheet. The context path (breadcrumbs) can reference a specific node in a node group hierarchy. During object evaluation, the geometry nodes modifier checks what data is currently requested by visible spreadsheets and stores the corresponding geometry sets separately for later access. The context path can be updated by the user explicitely, by clicking on the new icon in the header of nodes. Under some circumstances, the context path is updated automatically based on Blender's context. This patch also consolidates the "Node" and "Final" object evaluation mode to just "Evaluated". Based on the current context path, either the final geometry set of an object will be displayed, or the data at a specific node. The new preview icon in geometry nodes now behaves more like a toggle. It can be clicked again to clear the context path in an open spreadsheet editor. Previously, only an object could be pinned in the spreadsheet editor. Now it is possible to pin the entire context path. That allows two different spreadsheets to display geometry data from two different nodes. The breadcrumbs in the spreadsheet header can be collapsed by clicking on the arrow icons. It's not ideal but works well for now. This might be changed again, if we get a data set region on the left. Differential Revision: https://developer.blender.org/D10931
2021-04-15 08:57:10 +02:00
Cleanup: Move NOD_geometry.h to C++ Pull Request: https://projects.blender.org/blender/blender/pulls/109306
2023-06-23 22:15:42 +02:00
#include "NOD_geometry.hh"
Geometry Nodes: improve detecting data-block dependencies Previously, the data-block dependencies were always detected in `update_depsgraph` in `MOD_nodes.cc`. This would only be called when something called `DEG_relations_tag_update` before. We don't want to trigger a depsgraph rebuild after each operation in the node editor, as that would be expensive. However, that also meant that we often had to add data-block dependencies that are not actually used, but might be used if the user changed e.g. a link. A typical example for that is a object socket that has a default value, but the socket is also linked. Now, the dependencies referenced by the node tree are collected by the node tree update code which runs after all changes. This way we can detect whether the dependencies have changed. Only if they have changed, a depsgraph rebuild is triggered. This now allows also taking into account the mute status of nodes and whether an input is linked. There are still more things that could be taken into account. Most obviously whether a node is connected to an output. This can be done later. The most tricky aspect here is probably that we also have to consider all viewer nodes as output, because at the time the node runs, it's not known which viewer will actually be used (which depends on other editors). This also cleans up some special cases we had for e.g. the scene time node where we always had to trigger a depsgraph rebuild when it was added/removed because of its time dependence. This is now part of a more general system. This fixes #109219. Pull Request: https://projects.blender.org/blender/blender/pulls/131446
2024-12-05 18:02:14 +01:00
#include "NOD_geometry_nodes_dependencies.hh"
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
#include "NOD_geometry_nodes_execute.hh"
Geometry Nodes: support attaching gizmos to input values This adds support for attaching gizmos for input values. The goal is to make it easier for users to set input values intuitively in the 3D viewport. We went through multiple different possible designs until we settled on the one implemented here. We picked it for it's flexibility and ease of use when using geometry node assets. The core principle in the design is that **gizmos are attached to existing input values instead of being the input value themselves**. This actually fits the existing concept of gizmos in Blender well, but may be a bit unintutitive in a node setup at first. The attachment is done using links in the node editor. The most basic usage of the node is to link a Value node to the new Linear Gizmo node. This attaches the gizmo to the input value and allows you to change it from the 3D view. The attachment is indicated by the gizmo icon in the sockets which are controlled by a gizmo as well as the back-link (notice the double link) when the gizmo is active. The core principle makes it straight forward to control the same node setup from the 3D view with gizmos, or by manually changing input values, or by driving the input values procedurally. If the input value is controlled indirectly by other inputs, it's often possible to **automatically propagate** the gizmo to the actual input. Backpropagation does not work for all nodes, although more nodes can be supported over time. This patch adds the first three gizmo nodes which cover common use cases: * **Linear Gizmo**: Creates a gizmo that controls a float or integer value using a linear movement of e.g. an arrow in the 3D viewport. * **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be rotated to change the attached angle input. * **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale. In the future, more built-in gizmos and potentially the ability for custom gizmos could be added. All gizmo nodes have a **Transform** geometry output. Using it is optional but it is recommended when the gizmo is used to control inputs that affect a geometry. When it is used, Blender will automatically transform the gizmos together with the geometry that they control. To achieve this, the output should be merged with the generated geometry using the *Join Geometry* node. The data contained in *Transform* output is not visible geometry, but just internal information that helps Blender to give a better user experience when using gizmos. The gizmo nodes have a multi-input socket. This allows **controlling multiple values** with the same gizmo. Only a small set of **gizmo shapes** is supported initially. It might be extended in the future but one goal is to give the gizmos used by different node group assets a familiar look and feel. A similar constraint exists for **colors**. Currently, one can choose from a fixed set of colors which can be modified in the theme settings. The set of **visible gizmos** is determined by a multiple factors because it's not really feasible to show all possible gizmos at all times. To see any of the geometry nodes gizmos, the "Active Modifier" option has to be enabled in the "Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of the following is true: * The gizmo controls an input of the active modifier of the active object. * The gizmo controls a value in a selected node in an open node editor. * The gizmo controls a pinned value in an open node editor. Pinning works by clicking the gizmo icon next to the value. Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
#include "NOD_geometry_nodes_gizmos.hh"
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
#include "NOD_geometry_nodes_lazy_function.hh"
Geometry Nodes: Only show attribute toggle for field inputs Change the toggle to switch between an attribute and a single value to only display for inputs that are fields, as determined statically by the field inferencing added in rB61f3d4eb7c7db7. This means the field inferencing must be calculated on file load, since it's used in the UI. Differential Revision: https://developer.blender.org/D12623
2021-09-28 12:05:42 -05:00
#include "NOD_node_declaration.hh"
Nodes: automatically gray out input values that don't affect the output This patch automatically grays out input values which can't affect the output currently. It works with inputs of group nodes, geometry nodes modifiers and node tools. To achieve this, it analyses the node tree and partially evaluates it to figure out which group inputs are currently not linked to an output or are disabled by e.g. some switch node. Original proposal: https://devtalk.blender.org/t/dynamic-socket-visibility/31874 Related info in blog post: https://code.blender.org/2023/11/geometry-nodes-workshop-november-2023/#dynamic-socket-visibility Follow up task for designing a UI that allows hiding sockets: #132706 Limitations: * The inferencing does not update correctly when a socket starts being animated/driven. I haven't found a good way to invalidate the cache in a good way reliably yet. It's only a very short term problem though. It fixes itself after the next modification of the node tree and is only noticeable when animating some specific sockets such as the switch node condition. * Whether a socket is grayed out is not exposed in the Python API yet. That will be done separately. * Only a partial evaluation is done to determine if an input affects an output. There should be no cases where a socket is found to be unused when it can actually affect the output. However, there can be cases where a socket is inferenced to be used even if it is not due to some complex condition. Depending on the exact circumstances, this can either be improved or the condition in the node tree should be simplified. Pull Request: https://projects.blender.org/blender/blender/pulls/132219
2025-01-21 12:53:24 +01:00
#include "NOD_socket_usage_inference.hh"
Functions: remove multi-function network The multi-function network system was able to compose multiple multi-functions into a new one and to evaluate that efficiently. This functionality was heavily used by the particle nodes prototype a year ago. However, since then we only used multi-functions without the need to compose them in geometry nodes. The upcoming "fields" in geometry nodes will need a way to compose multi-functions again. Unfortunately, the code removed in this commit was not ideal for this different kind of function composition. I've been working on an alternative that will be added separately when it becomes needed. I've had to update all the function nodes, because their interface depended on the multi-function network data structure a bit. The actual multi-function implementations are still the same though.
2021-08-20 13:14:39 +02:00
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
namespace lf = blender::fn::lazy_function;
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
namespace geo_log = blender::nodes::geo_eval_log;
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
namespace bake = blender::bke::bake;
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
namespace blender {
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
static void init_data(ModifierData *md)
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
{
NodesModifierData *nmd = (NodesModifierData *)md;
BLI_assert(MEMCMP_STRUCT_AFTER_IS_ZERO(nmd, modifier));
Geometry Nodes: improve display of node warnings in modifier This does the following changes: * Show info "warnings" in modifier too. Previously those were skipped. The different behavior of info/warning/error messages causes confusion. * Add a new `Warnings` panel that only shows when there are warnings. In its title, it shows how many warnings there are. * In the panel, warnings are sorted by severity and alphabetically. Pull Request: https://projects.blender.org/blender/blender/pulls/128395
2024-10-01 15:31:50 +02:00
nmd->modifier.layout_panel_open_flag |= 1 << NODES_MODIFIER_PANEL_WARNINGS;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
MEMCPY_STRUCT_AFTER(nmd, DNA_struct_default_get(NodesModifierData), modifier);
Geometry Nodes: add run-time data to geometry nodes modifier This adds a single run-time field and moves the existing run-time data into a new struct. This approach makes it much easier to add new run-time data. Pull Request: https://projects.blender.org/blender/blender/pulls/109905
2023-07-11 12:55:57 +02:00
nmd->runtime = MEM_new<NodesModifierRuntime>(__func__);
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
nmd->runtime->cache = std::make_shared<bake::ModifierCache>();
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
}
Geometry Nodes: improve detecting data-block dependencies Previously, the data-block dependencies were always detected in `update_depsgraph` in `MOD_nodes.cc`. This would only be called when something called `DEG_relations_tag_update` before. We don't want to trigger a depsgraph rebuild after each operation in the node editor, as that would be expensive. However, that also meant that we often had to add data-block dependencies that are not actually used, but might be used if the user changed e.g. a link. A typical example for that is a object socket that has a default value, but the socket is also linked. Now, the dependencies referenced by the node tree are collected by the node tree update code which runs after all changes. This way we can detect whether the dependencies have changed. Only if they have changed, a depsgraph rebuild is triggered. This now allows also taking into account the mute status of nodes and whether an input is linked. There are still more things that could be taken into account. Most obviously whether a node is connected to an output. This can be done later. The most tricky aspect here is probably that we also have to consider all viewer nodes as output, because at the time the node runs, it's not known which viewer will actually be used (which depends on other editors). This also cleans up some special cases we had for e.g. the scene time node where we always had to trigger a depsgraph rebuild when it was added/removed because of its time dependence. This is now part of a more general system. This fixes #109219. Pull Request: https://projects.blender.org/blender/blender/pulls/131446
2024-12-05 18:02:14 +01:00
static void find_dependencies_from_settings(const NodesModifierSettings &settings,
nodes::GeometryNodesEvalDependencies &deps)
Geometry Nodes: Enable exposing object and collection sockets This patch allows connecting wires for object and collection socket types to the "Group Input" node, which exposes them to be adjusted in the modifier. Thanks to @angavrilov's recent work in rB8964c02348f6, it is now possible to edit pointer IDProperties in the interface when they are drawn with `uiItemPointerR`. This patch is composed of a few changes: - Add code to create pointer properties in the modifier settings for object and collection sockets, and also to draw them in the UI. - Also search through the modifier's `IDProperty` settings to find IDs used by the modifier. - Change the setting's UI layout to support the change. Differential Revision: https://developer.blender.org/D10056
2021-01-13 08:13:57 -06:00
{
Cleanup: Use FunctionRef for IDProperty iteration callback Avoid the need for a seaprate user_data argument.
2024-03-26 13:36:30 -04:00
IDP_foreach_property(settings.properties, IDP_TYPE_FILTER_ID, [&](IDProperty *property) {
if (ID *id = IDP_Id(property)) {
Geometry Nodes: improve detecting data-block dependencies Previously, the data-block dependencies were always detected in `update_depsgraph` in `MOD_nodes.cc`. This would only be called when something called `DEG_relations_tag_update` before. We don't want to trigger a depsgraph rebuild after each operation in the node editor, as that would be expensive. However, that also meant that we often had to add data-block dependencies that are not actually used, but might be used if the user changed e.g. a link. A typical example for that is a object socket that has a default value, but the socket is also linked. Now, the dependencies referenced by the node tree are collected by the node tree update code which runs after all changes. This way we can detect whether the dependencies have changed. Only if they have changed, a depsgraph rebuild is triggered. This now allows also taking into account the mute status of nodes and whether an input is linked. There are still more things that could be taken into account. Most obviously whether a node is connected to an output. This can be done later. The most tricky aspect here is probably that we also have to consider all viewer nodes as output, because at the time the node runs, it's not known which viewer will actually be used (which depends on other editors). This also cleans up some special cases we had for e.g. the scene time node where we always had to trigger a depsgraph rebuild when it was added/removed because of its time dependence. This is now part of a more general system. This fixes #109219. Pull Request: https://projects.blender.org/blender/blender/pulls/131446
2024-12-05 18:02:14 +01:00
deps.add_generic_id_full(id);
Cleanup: Use FunctionRef for IDProperty iteration callback Avoid the need for a seaprate user_data argument.
2024-03-26 13:36:30 -04:00
}
});
Geometry Nodes: Enable exposing object and collection sockets This patch allows connecting wires for object and collection socket types to the "Group Input" node, which exposes them to be adjusted in the modifier. Thanks to @angavrilov's recent work in rB8964c02348f6, it is now possible to edit pointer IDProperties in the interface when they are drawn with `uiItemPointerR`. This patch is composed of a few changes: - Add code to create pointer properties in the modifier settings for object and collection sockets, and also to draw them in the UI. - Also search through the modifier's `IDProperty` settings to find IDs used by the modifier. - Change the setting's UI layout to support the change. Differential Revision: https://developer.blender.org/D10056
2021-01-13 08:13:57 -06:00
}
Depsgraph: support depending on collection geometry This fixes T87666 and T83252. The boolean modifier and geometry nodes can depend on the geometry of an entire collection. Before, the modifiers had to manually create relations to all the objects in the collection. This worked for the most part, but was cumbersome and did not solve all issues. For example, the modifiers were not properly updated when objects were added/removed from the referenced collection. This commit introduces the concept of "collection geometry" in the depsgraph. The geometry of a collection depends on the transforms and geometry of all the objects in it. The boolean modifier and geometry nodes can now just depend on the collection geometry instead of creating all the dependencies themselves. Differential Revision: https://developer.blender.org/D11053
2021-04-26 16:35:22 +02:00
/* We don't know exactly what attributes from the other object we will need. */
static const CustomData_MeshMasks dependency_data_mask{CD_MASK_PROP_ALL | CD_MASK_MDEFORMVERT,
CD_MASK_PROP_ALL,
CD_MASK_PROP_ALL,
CD_MASK_PROP_ALL,
CD_MASK_PROP_ALL};
static void add_collection_relation(const ModifierUpdateDepsgraphContext *ctx,
Collection &collection)
{
DEG_add_collection_geometry_relation(ctx->node, &collection, "Nodes Modifier");
DEG_add_collection_geometry_customdata_mask(ctx->node, &collection, &dependency_data_mask);
}
Fix: Geometry nodes not depending on instanced collections properly Geometry nodes were not adding referenced instanced collections as dependencies to depsgraph. This would lead to meshes and data not being ready on evaluation in certain cases.
2021-02-22 20:26:51 +01:00
Geometry Nodes: improve detecting data-block dependencies Previously, the data-block dependencies were always detected in `update_depsgraph` in `MOD_nodes.cc`. This would only be called when something called `DEG_relations_tag_update` before. We don't want to trigger a depsgraph rebuild after each operation in the node editor, as that would be expensive. However, that also meant that we often had to add data-block dependencies that are not actually used, but might be used if the user changed e.g. a link. A typical example for that is a object socket that has a default value, but the socket is also linked. Now, the dependencies referenced by the node tree are collected by the node tree update code which runs after all changes. This way we can detect whether the dependencies have changed. Only if they have changed, a depsgraph rebuild is triggered. This now allows also taking into account the mute status of nodes and whether an input is linked. There are still more things that could be taken into account. Most obviously whether a node is connected to an output. This can be done later. The most tricky aspect here is probably that we also have to consider all viewer nodes as output, because at the time the node runs, it's not known which viewer will actually be used (which depends on other editors). This also cleans up some special cases we had for e.g. the scene time node where we always had to trigger a depsgraph rebuild when it was added/removed because of its time dependence. This is now part of a more general system. This fixes #109219. Pull Request: https://projects.blender.org/blender/blender/pulls/131446
2024-12-05 18:02:14 +01:00
static void add_object_relation(
const ModifierUpdateDepsgraphContext *ctx,
Object &object,
const nodes::GeometryNodesEvalDependencies::ObjectDependencyInfo &info)
Geometry Nodes: Add dependency relation for collection objects Currently moving or changing an object references in a node modifier's node group does not trigger re-evaluation. Because there is no collection relation in the dependency graph, we must add the relation to all objects in the collection individually.
2021-02-12 12:03:38 -06:00
{
Geometry Nodes: improve detecting data-block dependencies Previously, the data-block dependencies were always detected in `update_depsgraph` in `MOD_nodes.cc`. This would only be called when something called `DEG_relations_tag_update` before. We don't want to trigger a depsgraph rebuild after each operation in the node editor, as that would be expensive. However, that also meant that we often had to add data-block dependencies that are not actually used, but might be used if the user changed e.g. a link. A typical example for that is a object socket that has a default value, but the socket is also linked. Now, the dependencies referenced by the node tree are collected by the node tree update code which runs after all changes. This way we can detect whether the dependencies have changed. Only if they have changed, a depsgraph rebuild is triggered. This now allows also taking into account the mute status of nodes and whether an input is linked. There are still more things that could be taken into account. Most obviously whether a node is connected to an output. This can be done later. The most tricky aspect here is probably that we also have to consider all viewer nodes as output, because at the time the node runs, it's not known which viewer will actually be used (which depends on other editors). This also cleans up some special cases we had for e.g. the scene time node where we always had to trigger a depsgraph rebuild when it was added/removed because of its time dependence. This is now part of a more general system. This fixes #109219. Pull Request: https://projects.blender.org/blender/blender/pulls/131446
2024-12-05 18:02:14 +01:00
if (info.transform) {
DEG_add_object_relation(ctx->node, &object, DEG_OB_COMP_TRANSFORM, "Nodes Modifier");
}
if (&(ID &)object == &ctx->object->id) {
return;
}
if (info.geometry) {
Depsgraph: support depending on collection geometry This fixes T87666 and T83252. The boolean modifier and geometry nodes can depend on the geometry of an entire collection. Before, the modifiers had to manually create relations to all the objects in the collection. This worked for the most part, but was cumbersome and did not solve all issues. For example, the modifiers were not properly updated when objects were added/removed from the referenced collection. This commit introduces the concept of "collection geometry" in the depsgraph. The geometry of a collection depends on the transforms and geometry of all the objects in it. The boolean modifier and geometry nodes can now just depend on the collection geometry instead of creating all the dependencies themselves. Differential Revision: https://developer.blender.org/D11053
2021-04-26 16:35:22 +02:00
if (object.type == OB_EMPTY && object.instance_collection != nullptr) {
add_collection_relation(ctx, *object.instance_collection);
Fix: Geometry nodes not depending on instanced collections properly Geometry nodes were not adding referenced instanced collections as dependencies to depsgraph. This would lead to meshes and data not being ready on evaluation in certain cases.
2021-02-22 20:26:51 +01:00
}
Fix T88250: crash when instancing object in disabled collection This issue was that `BKE_object_eval_uber_data` was not called for the text object, because its geometry was not dependent upon and its `is_directly_visible` tag was `false`. The crash happens in rendering code, because the evaluated data is missing. This not only affects text objects, but all object types that have a geometry component that geometry nodes does not support yet. The solution is to just add the missing dependencies. Differential Revision: https://developer.blender.org/D11385
2021-05-26 16:06:01 +02:00
else if (DEG_object_has_geometry_component(&object)) {
Geometry Nodes: Add dependency relation for collection objects Currently moving or changing an object references in a node modifier's node group does not trigger re-evaluation. Because there is no collection relation in the dependency graph, we must add the relation to all objects in the collection individually.
2021-02-12 12:03:38 -06:00
DEG_add_object_relation(ctx->node, &object, DEG_OB_COMP_GEOMETRY, "Nodes Modifier");
Depsgraph: support depending on collection geometry This fixes T87666 and T83252. The boolean modifier and geometry nodes can depend on the geometry of an entire collection. Before, the modifiers had to manually create relations to all the objects in the collection. This worked for the most part, but was cumbersome and did not solve all issues. For example, the modifiers were not properly updated when objects were added/removed from the referenced collection. This commit introduces the concept of "collection geometry" in the depsgraph. The geometry of a collection depends on the transforms and geometry of all the objects in it. The boolean modifier and geometry nodes can now just depend on the collection geometry instead of creating all the dependencies themselves. Differential Revision: https://developer.blender.org/D11053
2021-04-26 16:35:22 +02:00
DEG_add_customdata_mask(ctx->node, &object, &dependency_data_mask);
Geometry Nodes: Add dependency relation for collection objects Currently moving or changing an object references in a node modifier's node group does not trigger re-evaluation. Because there is no collection relation in the dependency graph, we must add the relation to all objects in the collection individually.
2021-02-12 12:03:38 -06:00
}
}
Geometry Nodes: new Camera Info Node This adds a new Camera Info node to Geometry Nodes. It provides information about the passed in camera like its projection matrix and focus distance. This can be used for camera culling which was must more complex before. It also allows building other view-dependent effects. Pull Request: https://projects.blender.org/blender/blender/pulls/135311
2025-03-28 22:54:13 +01:00
if (object.type == OB_CAMERA) {
if (info.camera_parameters) {
DEG_add_object_relation(ctx->node, &object, DEG_OB_COMP_PARAMETERS, "Nodes Modifier");
}
}
Geometry Nodes: Add dependency relation for collection objects Currently moving or changing an object references in a node modifier's node group does not trigger re-evaluation. Because there is no collection relation in the dependency graph, we must add the relation to all objects in the collection individually.
2021-02-12 12:03:38 -06:00
}
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
static void update_depsgraph(ModifierData *md, const ModifierUpdateDepsgraphContext *ctx)
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
{
NodesModifierData *nmd = reinterpret_cast<NodesModifierData *>(md);
Cleanup: Return early, use switch, rename function
2022-01-31 15:27:35 -06:00
if (nmd->node_group == nullptr) {
return;
}
Fix #131598: handle missing linked data blocks in Geometry Nodes modifier
2024-12-09 13:42:07 +01:00
if (ID_MISSING(nmd->node_group)) {
return;
}
Cleanup: Return early, use switch, rename function
2022-01-31 15:27:35 -06:00
DEG_add_node_tree_output_relation(ctx->node, nmd->node_group, "Nodes Modifier");
Geometry Nodes: improve detecting data-block dependencies Previously, the data-block dependencies were always detected in `update_depsgraph` in `MOD_nodes.cc`. This would only be called when something called `DEG_relations_tag_update` before. We don't want to trigger a depsgraph rebuild after each operation in the node editor, as that would be expensive. However, that also meant that we often had to add data-block dependencies that are not actually used, but might be used if the user changed e.g. a link. A typical example for that is a object socket that has a default value, but the socket is also linked. Now, the dependencies referenced by the node tree are collected by the node tree update code which runs after all changes. This way we can detect whether the dependencies have changed. Only if they have changed, a depsgraph rebuild is triggered. This now allows also taking into account the mute status of nodes and whether an input is linked. There are still more things that could be taken into account. Most obviously whether a node is connected to an output. This can be done later. The most tricky aspect here is probably that we also have to consider all viewer nodes as output, because at the time the node runs, it's not known which viewer will actually be used (which depends on other editors). This also cleans up some special cases we had for e.g. the scene time node where we always had to trigger a depsgraph rebuild when it was added/removed because of its time dependence. This is now part of a more general system. This fixes #109219. Pull Request: https://projects.blender.org/blender/blender/pulls/131446
2024-12-05 18:02:14 +01:00
nodes::GeometryNodesEvalDependencies eval_deps =
Fix #131598: avoid relying on node tree update code being run before dependency graph is build This avoids assuming that `BKE_ntree_update_main` has run on a node tree before the depsgraph is build. The update code already finds the dependencies to determine if a relations update is necessary or not. To avoid detecting these dependencies again (which requires iterating over all the nested nodes), they were cached on the node group so that they can be used when the depsgraph is build. However, since the update code does not run in all necessary cases yet (#131598), this does not work currently. This patch fixes the situation by removing the optimization of not having to find all dependencies again when the depsgraph is build. This optimization can be introduced again after we can be more sure that the node tree update code runs whenever the node tree changes (which is what #131665 tries, but requires more discussion). Pull Request: https://projects.blender.org/blender/blender/pulls/131685
2024-12-10 17:52:44 +01:00
nodes::gather_geometry_nodes_eval_dependencies_recursive(*nmd->node_group);
Geometry Nodes: improve detecting data-block dependencies Previously, the data-block dependencies were always detected in `update_depsgraph` in `MOD_nodes.cc`. This would only be called when something called `DEG_relations_tag_update` before. We don't want to trigger a depsgraph rebuild after each operation in the node editor, as that would be expensive. However, that also meant that we often had to add data-block dependencies that are not actually used, but might be used if the user changed e.g. a link. A typical example for that is a object socket that has a default value, but the socket is also linked. Now, the dependencies referenced by the node tree are collected by the node tree update code which runs after all changes. This way we can detect whether the dependencies have changed. Only if they have changed, a depsgraph rebuild is triggered. This now allows also taking into account the mute status of nodes and whether an input is linked. There are still more things that could be taken into account. Most obviously whether a node is connected to an output. This can be done later. The most tricky aspect here is probably that we also have to consider all viewer nodes as output, because at the time the node runs, it's not known which viewer will actually be used (which depends on other editors). This also cleans up some special cases we had for e.g. the scene time node where we always had to trigger a depsgraph rebuild when it was added/removed because of its time dependence. This is now part of a more general system. This fixes #109219. Pull Request: https://projects.blender.org/blender/blender/pulls/131446
2024-12-05 18:02:14 +01:00
/* Create dependencies to data-blocks referenced by the settings in the modifier. */
find_dependencies_from_settings(nmd->settings, eval_deps);
Curves: support deforming curves on surface Curves that are attached to a surface can now follow the surface when it is modified using shape keys or modifiers (but not when the original surface is deformed in edit or sculpt mode). The surface is allowed to be changed in any way that keeps uv maps intact. So deformation is allowed, but also some topology changes like subdivision. The following features are added: * A new `Deform Curves on Surface` node, which deforms curves with attachment information based on the surface object and uv map set in the properties panel. * A new `Add Rest Position` checkbox in the shape keys panel. When checked, a new `rest_position` vector attribute is added to the mesh before shape keys and modifiers are applied. This is necessary to support proper deformation of the curves, but can also be used for other purposes. * The `Add > Curve > Empty Hair` operator now sets up a simple geometry nodes setup that deforms the hair. It also makes sure that the rest position attribute is added to the surface. * A new `Object (Attach Curves to Surface)` operator in the `Set Parent To` (ctrl+P) menu, which attaches existing curves to the surface and sets the surface object as parent. Limitations: * Sculpting the procedurally deformed curves will be implemented separately. * The `Deform Curves on Surface` node is not generic and can only be used for one specific purpose currently. We plan to generalize this more in the future by adding support by exposing more inputs and/or by turning it into a node group. Differential Revision: https://developer.blender.org/D14864
2022-07-08 14:45:48 +02:00
if (ctx->object->type == OB_CURVES) {
Curves *curves_id = static_cast<Curves *>(ctx->object->data);
if (curves_id->surface != nullptr) {
Geometry Nodes: improve detecting data-block dependencies Previously, the data-block dependencies were always detected in `update_depsgraph` in `MOD_nodes.cc`. This would only be called when something called `DEG_relations_tag_update` before. We don't want to trigger a depsgraph rebuild after each operation in the node editor, as that would be expensive. However, that also meant that we often had to add data-block dependencies that are not actually used, but might be used if the user changed e.g. a link. A typical example for that is a object socket that has a default value, but the socket is also linked. Now, the dependencies referenced by the node tree are collected by the node tree update code which runs after all changes. This way we can detect whether the dependencies have changed. Only if they have changed, a depsgraph rebuild is triggered. This now allows also taking into account the mute status of nodes and whether an input is linked. There are still more things that could be taken into account. Most obviously whether a node is connected to an output. This can be done later. The most tricky aspect here is probably that we also have to consider all viewer nodes as output, because at the time the node runs, it's not known which viewer will actually be used (which depends on other editors). This also cleans up some special cases we had for e.g. the scene time node where we always had to trigger a depsgraph rebuild when it was added/removed because of its time dependence. This is now part of a more general system. This fixes #109219. Pull Request: https://projects.blender.org/blender/blender/pulls/131446
2024-12-05 18:02:14 +01:00
eval_deps.add_object(curves_id->surface);
Curves: support deforming curves on surface Curves that are attached to a surface can now follow the surface when it is modified using shape keys or modifiers (but not when the original surface is deformed in edit or sculpt mode). The surface is allowed to be changed in any way that keeps uv maps intact. So deformation is allowed, but also some topology changes like subdivision. The following features are added: * A new `Deform Curves on Surface` node, which deforms curves with attachment information based on the surface object and uv map set in the properties panel. * A new `Add Rest Position` checkbox in the shape keys panel. When checked, a new `rest_position` vector attribute is added to the mesh before shape keys and modifiers are applied. This is necessary to support proper deformation of the curves, but can also be used for other purposes. * The `Add > Curve > Empty Hair` operator now sets up a simple geometry nodes setup that deforms the hair. It also makes sure that the rest position attribute is added to the surface. * A new `Object (Attach Curves to Surface)` operator in the `Set Parent To` (ctrl+P) menu, which attaches existing curves to the surface and sets the surface object as parent. Limitations: * Sculpting the procedurally deformed curves will be implemented separately. * The `Deform Curves on Surface` node is not generic and can only be used for one specific purpose currently. We plan to generalize this more in the future by adding support by exposing more inputs and/or by turning it into a node group. Differential Revision: https://developer.blender.org/D14864
2022-07-08 14:45:48 +02:00
}
}
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
for (const NodesModifierBake &bake : Span(nmd->bakes, nmd->bakes_num)) {
for (const NodesModifierDataBlock &data_block : Span(bake.data_blocks, bake.data_blocks_num)) {
if (data_block.id) {
Geometry Nodes: improve detecting data-block dependencies Previously, the data-block dependencies were always detected in `update_depsgraph` in `MOD_nodes.cc`. This would only be called when something called `DEG_relations_tag_update` before. We don't want to trigger a depsgraph rebuild after each operation in the node editor, as that would be expensive. However, that also meant that we often had to add data-block dependencies that are not actually used, but might be used if the user changed e.g. a link. A typical example for that is a object socket that has a default value, but the socket is also linked. Now, the dependencies referenced by the node tree are collected by the node tree update code which runs after all changes. This way we can detect whether the dependencies have changed. Only if they have changed, a depsgraph rebuild is triggered. This now allows also taking into account the mute status of nodes and whether an input is linked. There are still more things that could be taken into account. Most obviously whether a node is connected to an output. This can be done later. The most tricky aspect here is probably that we also have to consider all viewer nodes as output, because at the time the node runs, it's not known which viewer will actually be used (which depends on other editors). This also cleans up some special cases we had for e.g. the scene time node where we always had to trigger a depsgraph rebuild when it was added/removed because of its time dependence. This is now part of a more general system. This fixes #109219. Pull Request: https://projects.blender.org/blender/blender/pulls/131446
2024-12-05 18:02:14 +01:00
eval_deps.add_generic_id_full(data_block.id);
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
}
}
}
Geometry Nodes: improve detecting data-block dependencies Previously, the data-block dependencies were always detected in `update_depsgraph` in `MOD_nodes.cc`. This would only be called when something called `DEG_relations_tag_update` before. We don't want to trigger a depsgraph rebuild after each operation in the node editor, as that would be expensive. However, that also meant that we often had to add data-block dependencies that are not actually used, but might be used if the user changed e.g. a link. A typical example for that is a object socket that has a default value, but the socket is also linked. Now, the dependencies referenced by the node tree are collected by the node tree update code which runs after all changes. This way we can detect whether the dependencies have changed. Only if they have changed, a depsgraph rebuild is triggered. This now allows also taking into account the mute status of nodes and whether an input is linked. There are still more things that could be taken into account. Most obviously whether a node is connected to an output. This can be done later. The most tricky aspect here is probably that we also have to consider all viewer nodes as output, because at the time the node runs, it's not known which viewer will actually be used (which depends on other editors). This also cleans up some special cases we had for e.g. the scene time node where we always had to trigger a depsgraph rebuild when it was added/removed because of its time dependence. This is now part of a more general system. This fixes #109219. Pull Request: https://projects.blender.org/blender/blender/pulls/131446
2024-12-05 18:02:14 +01:00
for (ID *id : eval_deps.ids.values()) {
Cleanup: Return early, use switch, rename function
2022-01-31 15:27:35 -06:00
switch ((ID_Type)GS(id->name)) {
case ID_OB: {
Object *object = reinterpret_cast<Object *>(id);
Geometry Nodes: improve detecting data-block dependencies Previously, the data-block dependencies were always detected in `update_depsgraph` in `MOD_nodes.cc`. This would only be called when something called `DEG_relations_tag_update` before. We don't want to trigger a depsgraph rebuild after each operation in the node editor, as that would be expensive. However, that also meant that we often had to add data-block dependencies that are not actually used, but might be used if the user changed e.g. a link. A typical example for that is a object socket that has a default value, but the socket is also linked. Now, the dependencies referenced by the node tree are collected by the node tree update code which runs after all changes. This way we can detect whether the dependencies have changed. Only if they have changed, a depsgraph rebuild is triggered. This now allows also taking into account the mute status of nodes and whether an input is linked. There are still more things that could be taken into account. Most obviously whether a node is connected to an output. This can be done later. The most tricky aspect here is probably that we also have to consider all viewer nodes as output, because at the time the node runs, it's not known which viewer will actually be used (which depends on other editors). This also cleans up some special cases we had for e.g. the scene time node where we always had to trigger a depsgraph rebuild when it was added/removed because of its time dependence. This is now part of a more general system. This fixes #109219. Pull Request: https://projects.blender.org/blender/blender/pulls/131446
2024-12-05 18:02:14 +01:00
add_object_relation(
ctx, *object, eval_deps.objects_info.lookup_default(object->id.session_uid, {}));
Cleanup: Return early, use switch, rename function
2022-01-31 15:27:35 -06:00
break;
}
case ID_GR: {
Collection *collection = reinterpret_cast<Collection *>(id);
add_collection_relation(ctx, *collection);
break;
}
case ID_IM:
case ID_TE: {
DEG_add_generic_id_relation(ctx->node, id, "Nodes Modifier");
Cleanup: break before the default case in switch statements While missing the break before a default that only breaks isn't an error, it means adding new cases needs to remember to add the break for an existing case, changing the default case will also result in an unintended fall-through. Also avoid `default:;` and add an explicit break.
2022-08-31 15:58:33 +10:00
break;
Cleanup: Return early, use switch, rename function
2022-01-31 15:27:35 -06:00
}
default: {
/* Purposefully don't add relations for materials. While there are material sockets,
* the pointers are only passed around as handles rather than dereferenced. */
break;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
}
}
}
Geometry Nodes: Remove object transform dependency in some cases The geometry nodes modifier currently always adds a dependency relation from the evaluated geometry to the object transform. However, that can be avoided unless there is a collection or object info node in "Relative" mode. In order to avoid requiring dependency graph relations updates often when editing a node tree, this patch doesn't check if the node is muted or if the data-block sockets are empty before adding the dependency. Fixes T95265 Differential Revision: https://developer.blender.org/D13973
2022-02-01 16:27:29 -06:00
Geometry Nodes: improve detecting data-block dependencies Previously, the data-block dependencies were always detected in `update_depsgraph` in `MOD_nodes.cc`. This would only be called when something called `DEG_relations_tag_update` before. We don't want to trigger a depsgraph rebuild after each operation in the node editor, as that would be expensive. However, that also meant that we often had to add data-block dependencies that are not actually used, but might be used if the user changed e.g. a link. A typical example for that is a object socket that has a default value, but the socket is also linked. Now, the dependencies referenced by the node tree are collected by the node tree update code which runs after all changes. This way we can detect whether the dependencies have changed. Only if they have changed, a depsgraph rebuild is triggered. This now allows also taking into account the mute status of nodes and whether an input is linked. There are still more things that could be taken into account. Most obviously whether a node is connected to an output. This can be done later. The most tricky aspect here is probably that we also have to consider all viewer nodes as output, because at the time the node runs, it's not known which viewer will actually be used (which depends on other editors). This also cleans up some special cases we had for e.g. the scene time node where we always had to trigger a depsgraph rebuild when it was added/removed because of its time dependence. This is now part of a more general system. This fixes #109219. Pull Request: https://projects.blender.org/blender/blender/pulls/131446
2024-12-05 18:02:14 +01:00
if (eval_deps.needs_own_transform) {
Depsgraph: More clear function name for transform dependnecy The name was confusing to a level that it sounded like the relation goes the opposite direction than it is intended.
2022-08-04 12:11:31 +02:00
DEG_add_depends_on_transform_relation(ctx->node, "Nodes Modifier");
Geometry Nodes: Remove object transform dependency in some cases The geometry nodes modifier currently always adds a dependency relation from the evaluated geometry to the object transform. However, that can be avoided unless there is a collection or object info node in "Relative" mode. In order to avoid requiring dependency graph relations updates often when editing a node tree, this patch doesn't check if the node is muted or if the data-block sockets are empty before adding the dependency. Fixes T95265 Differential Revision: https://developer.blender.org/D13973
2022-02-01 16:27:29 -06:00
}
Geometry Nodes: improve detecting data-block dependencies Previously, the data-block dependencies were always detected in `update_depsgraph` in `MOD_nodes.cc`. This would only be called when something called `DEG_relations_tag_update` before. We don't want to trigger a depsgraph rebuild after each operation in the node editor, as that would be expensive. However, that also meant that we often had to add data-block dependencies that are not actually used, but might be used if the user changed e.g. a link. A typical example for that is a object socket that has a default value, but the socket is also linked. Now, the dependencies referenced by the node tree are collected by the node tree update code which runs after all changes. This way we can detect whether the dependencies have changed. Only if they have changed, a depsgraph rebuild is triggered. This now allows also taking into account the mute status of nodes and whether an input is linked. There are still more things that could be taken into account. Most obviously whether a node is connected to an output. This can be done later. The most tricky aspect here is probably that we also have to consider all viewer nodes as output, because at the time the node runs, it's not known which viewer will actually be used (which depends on other editors). This also cleans up some special cases we had for e.g. the scene time node where we always had to trigger a depsgraph rebuild when it was added/removed because of its time dependence. This is now part of a more general system. This fixes #109219. Pull Request: https://projects.blender.org/blender/blender/pulls/131446
2024-12-05 18:02:14 +01:00
if (eval_deps.needs_active_camera) {
Geometry Nodes: Add Active Camera input node This adds a new "Active Camera" input geometry node, per #105761. The node outputs the the scene's current active camera. It is available from Input > Scene > Active Camera in the geometry nodes Add menu. Typical usage would be to connect this node to an Object Info node to obtain its transform. This works as expected when the camera's transform is animated, and also when there are markers on the timeline that change the active camera. In order to support the aforementioned changes in the active camera, this implementation adds depsgraph relations for all cameras referenced by timeline markers. This eliminates the complexity of updating the depsgraph whenever the scene switches to a different active camera, but of course it comes at the cost of including more objects than strictly necessary in the depsgraph for scenes that switch cameras. Dynamically updating the depsgraph upon camera changes could be a future improvement if there proves to be sufficient need for it. Pull Request: https://projects.blender.org/blender/blender/pulls/113431
2023-12-12 19:11:06 +01:00
DEG_add_scene_camera_relation(ctx->node, ctx->scene, DEG_OB_COMP_TRANSFORM, "Nodes Modifier");
Geometry Nodes: new Camera Info Node This adds a new Camera Info node to Geometry Nodes. It provides information about the passed in camera like its projection matrix and focus distance. This can be used for camera culling which was must more complex before. It also allows building other view-dependent effects. Pull Request: https://projects.blender.org/blender/blender/pulls/135311
2025-03-28 22:54:13 +01:00
}
/* Active camera is a scene parameter that can change, so we need a relation for that, too. */
if (eval_deps.needs_active_camera || eval_deps.needs_scene_render_params) {
Geometry Nodes: Add Active Camera input node This adds a new "Active Camera" input geometry node, per #105761. The node outputs the the scene's current active camera. It is available from Input > Scene > Active Camera in the geometry nodes Add menu. Typical usage would be to connect this node to an Object Info node to obtain its transform. This works as expected when the camera's transform is animated, and also when there are markers on the timeline that change the active camera. In order to support the aforementioned changes in the active camera, this implementation adds depsgraph relations for all cameras referenced by timeline markers. This eliminates the complexity of updating the depsgraph whenever the scene switches to a different active camera, but of course it comes at the cost of including more objects than strictly necessary in the depsgraph for scenes that switch cameras. Dynamically updating the depsgraph upon camera changes could be a future improvement if there proves to be sufficient need for it. Pull Request: https://projects.blender.org/blender/blender/pulls/113431
2023-12-12 19:11:06 +01:00
DEG_add_scene_relation(ctx->node, ctx->scene, DEG_SCENE_COMP_PARAMETERS, "Nodes Modifier");
}
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
}
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
static bool depends_on_time(Scene * /*scene*/, ModifierData *md)
Geometry Nodes: Scene Time Node This node outputs the current scene time in seconds or in frames. Use of this node eliminates the need to use drivers to control values in the node tree that are driven by the scene time. Frame is a float value to provide for subframe rendering for motion blur. Differential Revision: https://developer.blender.org/D13455
2021-12-09 11:50:25 -06:00
{
Cleanup: Use const arguments, references Also slightly change naming to avoid camel case.
2021-12-15 14:51:58 -06:00
const NodesModifierData *nmd = reinterpret_cast<NodesModifierData *>(md);
const bNodeTree *tree = nmd->node_group;
Geometry Nodes: Scene Time Node This node outputs the current scene time in seconds or in frames. Use of this node eliminates the need to use drivers to control values in the node tree that are driven by the scene time. Frame is a float value to provide for subframe rendering for motion blur. Differential Revision: https://developer.blender.org/D13455
2021-12-09 11:50:25 -06:00
if (tree == nullptr) {
return false;
}
Fix #131598: handle missing linked data blocks in Geometry Nodes modifier
2024-12-09 13:42:07 +01:00
if (ID_MISSING(tree)) {
return false;
}
Fix #116369: missing dependency on time when there is a bake animation node
2024-01-09 11:07:52 +01:00
for (const NodesModifierBake &bake : Span(nmd->bakes, nmd->bakes_num)) {
if (bake.bake_mode == NODES_MODIFIER_BAKE_MODE_ANIMATION) {
return true;
}
}
Fix #131598: avoid relying on node tree update code being run before dependency graph is build This avoids assuming that `BKE_ntree_update_main` has run on a node tree before the depsgraph is build. The update code already finds the dependencies to determine if a relations update is necessary or not. To avoid detecting these dependencies again (which requires iterating over all the nested nodes), they were cached on the node group so that they can be used when the depsgraph is build. However, since the update code does not run in all necessary cases yet (#131598), this does not work currently. This patch fixes the situation by removing the optimization of not having to find all dependencies again when the depsgraph is build. This optimization can be introduced again after we can be more sure that the node tree update code runs whenever the node tree changes (which is what #131665 tries, but requires more discussion). Pull Request: https://projects.blender.org/blender/blender/pulls/131685
2024-12-10 17:52:44 +01:00
nodes::GeometryNodesEvalDependencies eval_deps =
nodes::gather_geometry_nodes_eval_dependencies_recursive(*nmd->node_group);
return eval_deps.time_dependent;
Geometry Nodes: Scene Time Node This node outputs the current scene time in seconds or in frames. Use of this node eliminates the need to use drivers to control values in the node tree that are driven by the scene time. Frame is a float value to provide for subframe rendering for motion blur. Differential Revision: https://developer.blender.org/D13455
2021-12-09 11:50:25 -06:00
}
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
static void foreach_ID_link(ModifierData *md, Object *ob, IDWalkFunc walk, void *user_data)
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
{
NodesModifierData *nmd = reinterpret_cast<NodesModifierData *>(md);
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
walk(user_data, ob, (ID **)&nmd->node_group, IDWALK_CB_USER);
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
Cleanup: Use FunctionRef for IDProperty iteration callback Avoid the need for a seaprate user_data argument.
2024-03-26 13:36:30 -04:00
IDP_foreach_property(nmd->settings.properties, IDP_TYPE_FILTER_ID, [&](IDProperty *id_prop) {
walk(user_data, ob, (ID **)&id_prop->data.pointer, IDWALK_CB_USER);
});
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
for (NodesModifierBake &bake : MutableSpan(nmd->bakes, nmd->bakes_num)) {
for (NodesModifierDataBlock &data_block : MutableSpan(bake.data_blocks, bake.data_blocks_num))
{
walk(user_data, ob, &data_block.id, IDWALK_CB_USER);
}
}
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
}
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
static void foreach_tex_link(ModifierData *md, Object *ob, TexWalkFunc walk, void *user_data)
Geometry Nodes: show "Show Texture in texture tab" button This enables the quick access button [to show the relevant Texture in the Properties Editor] for textures used in geometry nodes. This goes in line to what we do for other textures: - modifier textures have this button - particle textures have this button - brush textures will soon have it, too (see D9813) When outside of the Properties Editor, the button will always show (if a texture is actually assigned), but will be inactive if no suiting Properties Editor to show the texture in can be found. Note this also changes the behavior to not show the button if _no_ texture is assigned (as in: we are still showing the "New" button). Previously it was always there (e.g. for modifier textures), even if it would take us to an empty texture tab. (Sure, we could add a texture there then, but imho it makes more sense to just start showing it once a texture is already there) For this to work with geometry nodes, the following chages were done: - implement foreachTexLink for geonode modifiers - new buttons_texture_user_node_property_add() that stores prop as well as node - also use NODE_ACTIVE_TEXTURE flag in geometry nodetrees notes: - this still uses the first suiting (as in: pinning does not interfere) Properties Editor it finds, this should (maybe?) find the _closest_ Property Editor instead (see related feedback in D9813). - this will already show the button for brush textures as well (disabled), but there is another mandatory change in an upcomming commit to make it work there as well (see D9813) ref. T85278 Maniphest Tasks: T85278 Differential Revision: https://developer.blender.org/D10293
2021-02-03 14:39:24 +01:00
{
Refactor: RNA: add `discrete` suffix to `RNA_pointer_create`. This is a noisy preliminary step to the 'RNA ancestors' change. The rename helps clearly tell what each `pointer_create` function does. Pull Request: https://projects.blender.org/blender/blender/pulls/133475
2025-01-24 16:45:32 +01:00
PointerRNA ptr = RNA_pointer_create_discrete(&ob->id, &RNA_Modifier, md);
Physics: Show texture properties tab when fluid modifier uses texture Investigation into #126306 showed that the texture tab shown would actually be for the active image paint brush, but people used it to set up a texture for the fluid modifier settings anyway. Now properly register the texture user for the UI, so the texture properties tab will always be displayed when there is a fluid modifier with a "Flow" fluid type. Main issue is that fluid modifiers weren't handled by the `BKE_modifiers_foreach_tex_link()` iterator. While this could be handled as another special case in `buttons_texture_modifier_foreach()`, I updated the texture-link iterators to support texture properties that are not directly stored in the modifier, but in some nested data. Seems like this should be supported generally. It's enabled here by passing a pointer-property pair, rather than just a property name. Pull Request: https://projects.blender.org/blender/blender/pulls/126893
2024-08-29 12:08:50 +02:00
PropertyRNA *prop = RNA_struct_find_property(&ptr, "texture");
walk(user_data, ob, md, &ptr, prop);
Geometry Nodes: show "Show Texture in texture tab" button This enables the quick access button [to show the relevant Texture in the Properties Editor] for textures used in geometry nodes. This goes in line to what we do for other textures: - modifier textures have this button - particle textures have this button - brush textures will soon have it, too (see D9813) When outside of the Properties Editor, the button will always show (if a texture is actually assigned), but will be inactive if no suiting Properties Editor to show the texture in can be found. Note this also changes the behavior to not show the button if _no_ texture is assigned (as in: we are still showing the "New" button). Previously it was always there (e.g. for modifier textures), even if it would take us to an empty texture tab. (Sure, we could add a texture there then, but imho it makes more sense to just start showing it once a texture is already there) For this to work with geometry nodes, the following chages were done: - implement foreachTexLink for geonode modifiers - new buttons_texture_user_node_property_add() that stores prop as well as node - also use NODE_ACTIVE_TEXTURE flag in geometry nodetrees notes: - this still uses the first suiting (as in: pinning does not interfere) Properties Editor it finds, this should (maybe?) find the _closest_ Property Editor instead (see related feedback in D9813). - this will already show the button for brush textures as well (disabled), but there is another mandatory change in an upcomming commit to make it work there as well (see D9813) ref. T85278 Maniphest Tasks: T85278 Differential Revision: https://developer.blender.org/D10293
2021-02-03 14:39:24 +01:00
}
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
static bool is_disabled(const Scene * /*scene*/, ModifierData *md, bool /*use_render_params*/)
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
{
NodesModifierData *nmd = reinterpret_cast<NodesModifierData *>(md);
if (nmd->node_group == nullptr) {
return true;
}
return false;
}
Fix: geometry nodes logs incorrect preview data Under some circumstances, modifiers are evaluated more than once. One time to compute the actual output geometry and another time with `MOD_APPLY_ORCO`. This design probably has to be revisited at some point in the context of geometry nodes. However, that would be much more involved than a bug fix. The issue was that during the second evaluation, the node tree is evaluated based on a slightly different input geometry. The data generated during the second evaluation overwrote the cached data from the first evaluation, resulting in incorrect data that is shown in the spreadsheet. The fix for now is to simply not log any data in the second evaluation.
2021-04-22 12:48:59 +02:00
static bool logging_enabled(const ModifierEvalContext *ctx)
{
if (!DEG_is_active(ctx->depsgraph)) {
return false;
}
if ((ctx->flag & MOD_APPLY_ORCO) != 0) {
return false;
}
return true;
}
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
static void update_id_properties_from_node_group(NodesModifierData *nmd)
Cleanup: Geometry Nodes: Split modifier property update function It's a bit easier to follow this way, and we can make better use of const. It's also more reusable in case we have to use it elsewhere too (for node group operators?).
2023-03-30 18:51:25 -04:00
{
if (nmd->node_group == nullptr) {
if (nmd->settings.properties) {
IDP_FreeProperty(nmd->settings.properties);
nmd->settings.properties = nullptr;
}
return;
}
IDProperty *old_properties = nmd->settings.properties;
Cleanup: Use newer API for creating IDProperties in most places There are still a few places that are more complicated where the replacement to `IDP_New` isn't obvious, but this commit replaces most uses of the ugly `IDPropertyTemplate` usage.
2024-03-26 15:39:34 -04:00
nmd->settings.properties = bke::idprop::create_group("Nodes Modifier Settings").release();
Cleanup: Geometry Nodes: Split modifier property update function It's a bit easier to follow this way, and we can make better use of const. It's also more reusable in case we have to use it elsewhere too (for node group operators?).
2023-03-30 18:51:25 -04:00
IDProperty *new_properties = nmd->settings.properties;
Geometry Nodes: Use boolean type for "use attribute" inputs When the "use_attribute" properties were added, boolean IDProperties didn't exist. Then we didn't change it for a while because of forward compatibility concerns. But currently we always convert boolean properties to integer properties when saving anyway (since 2ea47e0def6a1d572879, so there is no issue with compatibility. Using booleans makes working with the properties in the Python API a bit friendlier. Pull Request: https://projects.blender.org/blender/blender/pulls/119129
2024-03-08 17:49:09 +01:00
nodes::update_input_properties_from_node_tree(*nmd->node_group, old_properties, *new_properties);
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
nodes::update_output_properties_from_node_tree(
*nmd->node_group, old_properties, *new_properties);
Geometry Nodes: support creating new attributes in modifier This patch allows passing a field to the modifier as output. In the modifier, the user can choose an attribute name. The attribute will be filled with values computed by the field. This only works for realized mesh/curve/point data. As mentioned in T91376, the output domain is selected in the node group itself. We might want to add this functionality to the modifier later as well, but not now. Differential Revision: https://developer.blender.org/D12644
2021-09-27 15:33:48 +02:00
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
if (old_properties != nullptr) {
IDP_FreeProperty(old_properties);
}
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
}
Geometry Nodes: improve handling baked data after undo Previously, one could easily "loose" baked data by undoing. The data was not actually deleted, but Blender didn't find it anymore. This happened because `update_existing_bake_caches` was expected to be called after changes to `NodesModifierData.bakes`. However, this was not called after undo. It was also not possible to call this function from `blend_read`, because it required access to the referenced node tree. Now, the bake cache is lazily created during depsgraph evaluation, which partially solves the problem. It can still seem that Blender lost data, but that fixes itself much more quickly after the next evaluation. The remaining issue should be solved a future patch that keeps the bake cache intact over undo steps using `foreach_cache`.
2024-01-29 11:42:34 +01:00
static void remove_outdated_bake_caches(NodesModifierData &nmd)
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
{
if (!nmd.runtime->cache) {
if (nmd.bakes_num == 0) {
return;
}
nmd.runtime->cache = std::make_shared<bake::ModifierCache>();
}
bake::ModifierCache &modifier_cache = *nmd.runtime->cache;
std::lock_guard lock{modifier_cache.mutex};
Geometry Nodes: improve handling baked data after undo Previously, one could easily "loose" baked data by undoing. The data was not actually deleted, but Blender didn't find it anymore. This happened because `update_existing_bake_caches` was expected to be called after changes to `NodesModifierData.bakes`. However, this was not called after undo. It was also not possible to call this function from `blend_read`, because it required access to the referenced node tree. Now, the bake cache is lazily created during depsgraph evaluation, which partially solves the problem. It can still seem that Blender lost data, but that fixes itself much more quickly after the next evaluation. The remaining issue should be solved a future patch that keeps the bake cache intact over undo steps using `foreach_cache`.
2024-01-29 11:42:34 +01:00
Set<int> existing_bake_ids;
for (const NodesModifierBake &bake : Span{nmd.bakes, nmd.bakes_num}) {
existing_bake_ids.add(bake.id);
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
}
Fix #116515: Single Value Only applies to wrong input in geometry nodes modifier The counting of input sockets did not take closed panels into account correctly.
2024-01-09 11:01:12 +01:00
Geometry Nodes: improve handling baked data after undo Previously, one could easily "loose" baked data by undoing. The data was not actually deleted, but Blender didn't find it anymore. This happened because `update_existing_bake_caches` was expected to be called after changes to `NodesModifierData.bakes`. However, this was not called after undo. It was also not possible to call this function from `blend_read`, because it required access to the referenced node tree. Now, the bake cache is lazily created during depsgraph evaluation, which partially solves the problem. It can still seem that Blender lost data, but that fixes itself much more quickly after the next evaluation. The remaining issue should be solved a future patch that keeps the bake cache intact over undo steps using `foreach_cache`.
2024-01-29 11:42:34 +01:00
auto remove_predicate = [&](auto item) { return !existing_bake_ids.contains(item.key); };
modifier_cache.bake_cache_by_id.remove_if(remove_predicate);
modifier_cache.simulation_cache_by_id.remove_if(remove_predicate);
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
}
static void update_bakes_from_node_group(NodesModifierData &nmd)
{
Map<int, NodesModifierBake *> old_bake_by_id;
for (NodesModifierBake &bake : MutableSpan(nmd.bakes, nmd.bakes_num)) {
old_bake_by_id.add(bake.id, &bake);
}
Vector<int> new_bake_ids;
Fix: Crash deleting geometry nodes node group Missing null check in ad169ba67a5a5087f1b6.
2023-09-26 16:51:00 -04:00
if (nmd.node_group) {
for (const bNestedNodeRef &ref : nmd.node_group->nested_node_refs_span()) {
const bNode *node = nmd.node_group->find_nested_node(ref.id);
if (node) {
Nodes: rename integer type of nodes to type_legacy The new description for `bNode.type_legacy`: ``` /** * Legacy integer type for nodes. It does not uniquely identify a node type, only the `idname` * does that. For example, all custom nodes use #NODE_CUSTOM but do have different idnames. * This is mainly kept for compatibility reasons. * * Currently, this type is also used in many parts of Blender, but that should slowly be phased * out by either relying on idnames, accessor methods like `node.is_reroute()`. * * A main benefit of this integer type over using idnames currently is that integer comparison is * much cheaper than string comparison, especially if many idnames have the same prefix (e.g. * "GeometryNode"). Eventually, we could introduce cheap-to-compare runtime identifier for node * types. That could mean e.g. using `ustring` for idnames (where string comparison is just * pointer comparison), or using a run-time generated integer that is automatically assigned when * node types are registered. */ ``` Pull Request: https://projects.blender.org/blender/blender/pulls/132858
2025-01-09 15:28:57 +01:00
if (ELEM(node->type_legacy, GEO_NODE_SIMULATION_OUTPUT, GEO_NODE_BAKE)) {
Fix: Crash deleting geometry nodes node group Missing null check in ad169ba67a5a5087f1b6.
2023-09-26 16:51:00 -04:00
new_bake_ids.append(ref.id);
}
}
else if (old_bake_by_id.contains(ref.id)) {
/* Keep baked data in case linked data is missing so that it still exists when the linked
* data has been found. */
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
new_bake_ids.append(ref.id);
}
}
}
Refactor: Replace `MEM_cnew` with a type-aware template version of `MEM_callocN`. The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly replace most of its usages with the new, C++-style type-safer template version. * `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`. * `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`. * `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`. Similar templates type-safe version of `MEM_mallocN` will be added soon as well. Following discussions in !134452. NOTE: For now static type checking in `MEM_callocN` and related are slightly different for Windows MSVC. This compiler seems to consider structs using the `DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default copy constructors are deleted). So using checks on trivially constructible/destructible instead on this compiler/system. Pull Request: https://projects.blender.org/blender/blender/pulls/134771
2025-03-05 16:35:09 +01:00
NodesModifierBake *new_bake_data = MEM_calloc_arrayN<NodesModifierBake>(new_bake_ids.size(),
__func__);
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
for (const int i : new_bake_ids.index_range()) {
const int id = new_bake_ids[i];
NodesModifierBake *old_bake = old_bake_by_id.lookup_default(id, nullptr);
NodesModifierBake &new_bake = new_bake_data[i];
if (old_bake) {
new_bake = *old_bake;
Fix #132831: memory leak when deleting simulation zone The leak happened because the bake data of the removed zone was only partially freed. Pull Request: https://projects.blender.org/blender/blender/pulls/132867
2025-01-09 18:19:53 +01:00
/* The ownership of this data was moved to `new_bake`. */
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
old_bake->directory = nullptr;
Fix #132831: memory leak when deleting simulation zone The leak happened because the bake data of the removed zone was only partially freed. Pull Request: https://projects.blender.org/blender/blender/pulls/132867
2025-01-09 18:19:53 +01:00
old_bake->data_blocks = nullptr;
old_bake->data_blocks_num = 0;
old_bake->packed = nullptr;
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
}
else {
new_bake.id = id;
new_bake.frame_start = 1;
new_bake.frame_end = 100;
Geometry Nodes: use Still mode by default in Bake node Currently, the geometry nodes modifier always creates a time dependency if there is a bake animation node, even if there is no bake. Changing this is not entirely trivial, because it is only known during evaluation if there is baked data. Making `Still` the default works around that issue in many cases where the Bake node is in a node group asset that does not depend on time. Furthermore, it's nice to have the "cheaper" version of the node by default, which is baking a single frame, instead of baking everything. Pull Request: https://projects.blender.org/blender/blender/pulls/117999
2024-02-08 17:04:38 +01:00
new_bake.bake_mode = NODES_MODIFIER_BAKE_MODE_STILL;
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
}
}
for (NodesModifierBake &old_bake : MutableSpan(nmd.bakes, nmd.bakes_num)) {
Fix #132831: memory leak when deleting simulation zone The leak happened because the bake data of the removed zone was only partially freed. Pull Request: https://projects.blender.org/blender/blender/pulls/132867
2025-01-09 18:19:53 +01:00
nodes_modifier_bake_destruct(&old_bake, true);
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
}
MEM_SAFE_FREE(nmd.bakes);
nmd.bakes = new_bake_data;
nmd.bakes_num = new_bake_ids.size();
Geometry Nodes: improve handling baked data after undo Previously, one could easily "loose" baked data by undoing. The data was not actually deleted, but Blender didn't find it anymore. This happened because `update_existing_bake_caches` was expected to be called after changes to `NodesModifierData.bakes`. However, this was not called after undo. It was also not possible to call this function from `blend_read`, because it required access to the referenced node tree. Now, the bake cache is lazily created during depsgraph evaluation, which partially solves the problem. It can still seem that Blender lost data, but that fixes itself much more quickly after the next evaluation. The remaining issue should be solved a future patch that keeps the bake cache intact over undo steps using `foreach_cache`.
2024-01-29 11:42:34 +01:00
remove_outdated_bake_caches(nmd);
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
}
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
static void update_panels_from_node_group(NodesModifierData &nmd)
{
Map<int, NodesModifierPanel *> old_panel_by_id;
for (NodesModifierPanel &panel : MutableSpan(nmd.panels, nmd.panels_num)) {
old_panel_by_id.add(panel.id, &panel);
}
Vector<const bNodeTreeInterfacePanel *> interface_panels;
if (nmd.node_group) {
nmd.node_group->ensure_interface_cache();
nmd.node_group->tree_interface.foreach_item([&](const bNodeTreeInterfaceItem &item) {
if (item.item_type != NODE_INTERFACE_PANEL) {
return true;
}
interface_panels.append(reinterpret_cast<const bNodeTreeInterfacePanel *>(&item));
return true;
});
}
Refactor: Replace `MEM_cnew` with a type-aware template version of `MEM_callocN`. The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly replace most of its usages with the new, C++-style type-safer template version. * `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`. * `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`. * `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`. Similar templates type-safe version of `MEM_mallocN` will be added soon as well. Following discussions in !134452. NOTE: For now static type checking in `MEM_callocN` and related are slightly different for Windows MSVC. This compiler seems to consider structs using the `DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default copy constructors are deleted). So using checks on trivially constructible/destructible instead on this compiler/system. Pull Request: https://projects.blender.org/blender/blender/pulls/134771
2025-03-05 16:35:09 +01:00
NodesModifierPanel *new_panels = MEM_calloc_arrayN<NodesModifierPanel>(interface_panels.size(),
__func__);
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
for (const int i : interface_panels.index_range()) {
const bNodeTreeInterfacePanel &interface_panel = *interface_panels[i];
const int id = interface_panel.identifier;
NodesModifierPanel *old_panel = old_panel_by_id.lookup_default(id, nullptr);
NodesModifierPanel &new_panel = new_panels[i];
if (old_panel) {
new_panel = *old_panel;
}
else {
new_panel.id = id;
const bool default_closed = interface_panel.flag & NODE_INTERFACE_PANEL_DEFAULT_CLOSED;
SET_FLAG_FROM_TEST(new_panel.flag, !default_closed, NODES_MODIFIER_PANEL_OPEN);
}
}
MEM_SAFE_FREE(nmd.panels);
nmd.panels = new_panels;
nmd.panels_num = interface_panels.size();
}
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
} // namespace blender
void MOD_nodes_update_interface(Object *object, NodesModifierData *nmd)
{
using namespace blender;
update_id_properties_from_node_group(nmd);
update_bakes_from_node_group(*nmd);
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
update_panels_from_node_group(*nmd);
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
DEG_id_tag_update(&object->id, ID_RECALC_GEOMETRY);
}
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
NodesModifierBake *NodesModifierData::find_bake(const int id)
{
return const_cast<NodesModifierBake *>(std::as_const(*this).find_bake(id));
}
const NodesModifierBake *NodesModifierData::find_bake(const int id) const
{
for (const NodesModifierBake &bake : blender::Span{this->bakes, this->bakes_num}) {
if (bake.id == id) {
return &bake;
}
}
return nullptr;
}
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
namespace blender {
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
/**
* Setup side effects nodes so that the given node in the given compute context will be executed.
* To make sure that it is executed, all parent group nodes and zones have to be set to have side
* effects as well.
*/
Geometry Nodes: support viewers in closures This adds support for having viewer nodes in closures. The code attempt to detect where the closure is evaluated and shows the data from there. If the closure is evaluated in multiple Evaluate Closure nodes, currently it just picks the first one it finds. Support for more user control in this case may be added a bit later. If the Evaluate Closure node is in e.g. the repeat or foreach zone, it will automatically use the inspection index of that zone to determine what evaluation to look at specifically. Overall, not too much had to change conceptually to support viewers in closures. Just some code like converting between viewer paths and compute contexts had to be generalized a little bit. Pull Request: https://projects.blender.org/blender/blender/pulls/137625
2025-04-16 23:35:59 +02:00
static void try_add_side_effect_node(const ModifierEvalContext &ctx,
const ComputeContext &final_compute_context,
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
const int final_node_id,
const NodesModifierData &nmd,
nodes::GeoNodesSideEffectNodes &r_side_effect_nodes)
Spreadsheet: support showing data of specific node Previously, the spreadsheet editor could only show data of the original and of the final evaluated object. Now it is possible to show the data at some intermediate stages too. For that the mode has to be set to "Node" in the spreadsheet editor. Furthermore, the preview of a specific node has to be activated by clicking the new icon in the header of geometry nodes. The exact ui of this feature might be refined in upcoming commits. It is already very useful for debugging node groups in it's current state though. Differential Revision: https://developer.blender.org/D10875
2021-04-08 17:35:06 +02:00
{
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
if (nmd.node_group == nullptr) {
Geometry Nodes: fix force-computing multiple non-output sockets There were some issues when multiple inputs of the same node were forced to be computed (e.g. for the spreadsheet), but none of the node outputs (if existant) were used. Essentially the node was marked as "finished" too early in this case. This fix is necessary for the improved viewer node (T92167).
2021-10-21 15:49:29 +02:00
return;
Spreadsheet: breadcrumbs and node pinning This introduces a context path to the spreadsheet editor, which contains information about what data is shown in the spreadsheet. The context path (breadcrumbs) can reference a specific node in a node group hierarchy. During object evaluation, the geometry nodes modifier checks what data is currently requested by visible spreadsheets and stores the corresponding geometry sets separately for later access. The context path can be updated by the user explicitely, by clicking on the new icon in the header of nodes. Under some circumstances, the context path is updated automatically based on Blender's context. This patch also consolidates the "Node" and "Final" object evaluation mode to just "Evaluated". Based on the current context path, either the final geometry set of an object will be displayed, or the data at a specific node. The new preview icon in geometry nodes now behaves more like a toggle. It can be clicked again to clear the context path in an open spreadsheet editor. Previously, only an object could be pinned in the spreadsheet editor. Now it is possible to pin the entire context path. That allows two different spreadsheets to display geometry data from two different nodes. The breadcrumbs in the spreadsheet header can be collapsed by clicking on the arrow icons. It's not ideal but works well for now. This might be changed again, if we get a data set region on the left. Differential Revision: https://developer.blender.org/D10931
2021-04-15 08:57:10 +02:00
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
Vector<const ComputeContext *> compute_context_vec;
for (const ComputeContext *c = &final_compute_context; c; c = c->parent()) {
compute_context_vec.append(c);
}
std::reverse(compute_context_vec.begin(), compute_context_vec.end());
const auto *modifier_compute_context = dynamic_cast<const bke::ModifierComputeContext *>(
compute_context_vec[0]);
if (modifier_compute_context == nullptr) {
Geometry Nodes: fix force-computing multiple non-output sockets There were some issues when multiple inputs of the same node were forced to be computed (e.g. for the spreadsheet), but none of the node outputs (if existant) were used. Essentially the node was marked as "finished" too early in this case. This fix is necessary for the improved viewer node (T92167).
2021-10-21 15:49:29 +02:00
return;
Spreadsheet: breadcrumbs and node pinning This introduces a context path to the spreadsheet editor, which contains information about what data is shown in the spreadsheet. The context path (breadcrumbs) can reference a specific node in a node group hierarchy. During object evaluation, the geometry nodes modifier checks what data is currently requested by visible spreadsheets and stores the corresponding geometry sets separately for later access. The context path can be updated by the user explicitely, by clicking on the new icon in the header of nodes. Under some circumstances, the context path is updated automatically based on Blender's context. This patch also consolidates the "Node" and "Final" object evaluation mode to just "Evaluated". Based on the current context path, either the final geometry set of an object will be displayed, or the data at a specific node. The new preview icon in geometry nodes now behaves more like a toggle. It can be clicked again to clear the context path in an open spreadsheet editor. Previously, only an object could be pinned in the spreadsheet editor. Now it is possible to pin the entire context path. That allows two different spreadsheets to display geometry data from two different nodes. The breadcrumbs in the spreadsheet header can be collapsed by clicking on the arrow icons. It's not ideal but works well for now. This might be changed again, if we get a data set region on the left. Differential Revision: https://developer.blender.org/D10931
2021-04-15 08:57:10 +02:00
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
if (modifier_compute_context->modifier_name() != nmd.modifier.name) {
Geometry Nodes: fix force-computing multiple non-output sockets There were some issues when multiple inputs of the same node were forced to be computed (e.g. for the spreadsheet), but none of the node outputs (if existant) were used. Essentially the node was marked as "finished" too early in this case. This fix is necessary for the improved viewer node (T92167).
2021-10-21 15:49:29 +02:00
return;
Spreadsheet: breadcrumbs and node pinning This introduces a context path to the spreadsheet editor, which contains information about what data is shown in the spreadsheet. The context path (breadcrumbs) can reference a specific node in a node group hierarchy. During object evaluation, the geometry nodes modifier checks what data is currently requested by visible spreadsheets and stores the corresponding geometry sets separately for later access. The context path can be updated by the user explicitely, by clicking on the new icon in the header of nodes. Under some circumstances, the context path is updated automatically based on Blender's context. This patch also consolidates the "Node" and "Final" object evaluation mode to just "Evaluated". Based on the current context path, either the final geometry set of an object will be displayed, or the data at a specific node. The new preview icon in geometry nodes now behaves more like a toggle. It can be clicked again to clear the context path in an open spreadsheet editor. Previously, only an object could be pinned in the spreadsheet editor. Now it is possible to pin the entire context path. That allows two different spreadsheets to display geometry data from two different nodes. The breadcrumbs in the spreadsheet header can be collapsed by clicking on the arrow icons. It's not ideal but works well for now. This might be changed again, if we get a data set region on the left. Differential Revision: https://developer.blender.org/D10931
2021-04-15 08:57:10 +02:00
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
const bNodeTree *current_tree = nmd.node_group;
const bke::bNodeTreeZone *current_zone = nullptr;
Spreadsheet: breadcrumbs and node pinning This introduces a context path to the spreadsheet editor, which contains information about what data is shown in the spreadsheet. The context path (breadcrumbs) can reference a specific node in a node group hierarchy. During object evaluation, the geometry nodes modifier checks what data is currently requested by visible spreadsheets and stores the corresponding geometry sets separately for later access. The context path can be updated by the user explicitely, by clicking on the new icon in the header of nodes. Under some circumstances, the context path is updated automatically based on Blender's context. This patch also consolidates the "Node" and "Final" object evaluation mode to just "Evaluated". Based on the current context path, either the final geometry set of an object will be displayed, or the data at a specific node. The new preview icon in geometry nodes now behaves more like a toggle. It can be clicked again to clear the context path in an open spreadsheet editor. Previously, only an object could be pinned in the spreadsheet editor. Now it is possible to pin the entire context path. That allows two different spreadsheets to display geometry data from two different nodes. The breadcrumbs in the spreadsheet header can be collapsed by clicking on the arrow icons. It's not ideal but works well for now. This might be changed again, if we get a data set region on the left. Differential Revision: https://developer.blender.org/D10931
2021-04-15 08:57:10 +02:00
Geometry Nodes: make evaluation and logging system aware of zones This refactors how a geometry nodes node tree is converted to a lazy-function graph. Previously, all nodes were inserted into a single graph. This was fine because every node was evaluated at most once per node group evaluation. However, loops (#108896) break this assumption since now nodes may be evaluated multiple times and thus a single flat graph does not work anymore. Now, a separate lazy-function is build for every zone which gives us much more flexibility for what can happen in a zone. Right now, the change only applies to simulation zones since that's the only kind of zone we have. Technically, those zones could be inlined, but turning them into a separate lazy-function also does not hurt and makes it possible to test this refactor without implementing loops first. Also, having them as separate functions might help in the future if we integrate a substep loop directly into the simulation zone. The most tricky part here is to just link everything up correctly, especially with respect to deterministic anonymous attribute lifetimes. Fortunately, correctness can be checked visually by looking at the generated graphs. The logging/viewer system also had to be refactored a bit, because now there can be multiple different `ComputeContext` in a single node tree. Each zone is in a separate `ComputeContext`. To make it work, the `ViewerPath` system now explicitly supports zones and drawing code will look up the right logger for showing inspection data. No functional changes are expected, except that the spreadsheet now shows "Simulation Zone" in the context path if the viewer is in a simulation.
2023-06-20 09:50:44 +02:00
/* Write side effect nodes to a new map and only if everything succeeds, move the nodes to the
* caller. This is easier than changing r_side_effect_nodes directly and then undoing changes in
* case of errors. */
Geometry Nodes: use separate struct for side effect nodes This makes it easier to add another map containing side effect nodes in #112421. No functional changes expected.
2023-09-16 18:57:04 +02:00
nodes::GeoNodesSideEffectNodes local_side_effect_nodes;
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
for (const ComputeContext *compute_context_generic : compute_context_vec.as_span().drop_front(1))
{
const bke::bNodeTreeZones *current_zones = current_tree->zones();
if (current_zones == nullptr) {
Geometry Nodes: fix force-computing multiple non-output sockets There were some issues when multiple inputs of the same node were forced to be computed (e.g. for the spreadsheet), but none of the node outputs (if existant) were used. Essentially the node was marked as "finished" too early in this case. This fix is necessary for the improved viewer node (T92167).
2021-10-21 15:49:29 +02:00
return;
Spreadsheet: breadcrumbs and node pinning This introduces a context path to the spreadsheet editor, which contains information about what data is shown in the spreadsheet. The context path (breadcrumbs) can reference a specific node in a node group hierarchy. During object evaluation, the geometry nodes modifier checks what data is currently requested by visible spreadsheets and stores the corresponding geometry sets separately for later access. The context path can be updated by the user explicitely, by clicking on the new icon in the header of nodes. Under some circumstances, the context path is updated automatically based on Blender's context. This patch also consolidates the "Node" and "Final" object evaluation mode to just "Evaluated". Based on the current context path, either the final geometry set of an object will be displayed, or the data at a specific node. The new preview icon in geometry nodes now behaves more like a toggle. It can be clicked again to clear the context path in an open spreadsheet editor. Previously, only an object could be pinned in the spreadsheet editor. Now it is possible to pin the entire context path. That allows two different spreadsheets to display geometry data from two different nodes. The breadcrumbs in the spreadsheet header can be collapsed by clicking on the arrow icons. It's not ideal but works well for now. This might be changed again, if we get a data set region on the left. Differential Revision: https://developer.blender.org/D10931
2021-04-15 08:57:10 +02:00
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
const auto *lf_graph_info = nodes::ensure_geometry_nodes_lazy_function_graph(*current_tree);
Geometry Nodes: make evaluation and logging system aware of zones This refactors how a geometry nodes node tree is converted to a lazy-function graph. Previously, all nodes were inserted into a single graph. This was fine because every node was evaluated at most once per node group evaluation. However, loops (#108896) break this assumption since now nodes may be evaluated multiple times and thus a single flat graph does not work anymore. Now, a separate lazy-function is build for every zone which gives us much more flexibility for what can happen in a zone. Right now, the change only applies to simulation zones since that's the only kind of zone we have. Technically, those zones could be inlined, but turning them into a separate lazy-function also does not hurt and makes it possible to test this refactor without implementing loops first. Also, having them as separate functions might help in the future if we integrate a substep loop directly into the simulation zone. The most tricky part here is to just link everything up correctly, especially with respect to deterministic anonymous attribute lifetimes. Fortunately, correctness can be checked visually by looking at the generated graphs. The logging/viewer system also had to be refactored a bit, because now there can be multiple different `ComputeContext` in a single node tree. Each zone is in a separate `ComputeContext`. To make it work, the `ViewerPath` system now explicitly supports zones and drawing code will look up the right logger for showing inspection data. No functional changes are expected, except that the spreadsheet now shows "Simulation Zone" in the context path if the viewer is in a simulation.
2023-06-20 09:50:44 +02:00
if (lf_graph_info == nullptr) {
Geometry Nodes: fix force-computing multiple non-output sockets There were some issues when multiple inputs of the same node were forced to be computed (e.g. for the spreadsheet), but none of the node outputs (if existant) were used. Essentially the node was marked as "finished" too early in this case. This fix is necessary for the improved viewer node (T92167).
2021-10-21 15:49:29 +02:00
return;
Spreadsheet: breadcrumbs and node pinning This introduces a context path to the spreadsheet editor, which contains information about what data is shown in the spreadsheet. The context path (breadcrumbs) can reference a specific node in a node group hierarchy. During object evaluation, the geometry nodes modifier checks what data is currently requested by visible spreadsheets and stores the corresponding geometry sets separately for later access. The context path can be updated by the user explicitely, by clicking on the new icon in the header of nodes. Under some circumstances, the context path is updated automatically based on Blender's context. This patch also consolidates the "Node" and "Final" object evaluation mode to just "Evaluated". Based on the current context path, either the final geometry set of an object will be displayed, or the data at a specific node. The new preview icon in geometry nodes now behaves more like a toggle. It can be clicked again to clear the context path in an open spreadsheet editor. Previously, only an object could be pinned in the spreadsheet editor. Now it is possible to pin the entire context path. That allows two different spreadsheets to display geometry data from two different nodes. The breadcrumbs in the spreadsheet header can be collapsed by clicking on the arrow icons. It's not ideal but works well for now. This might be changed again, if we get a data set region on the left. Differential Revision: https://developer.blender.org/D10931
2021-04-15 08:57:10 +02:00
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
const ComputeContextHash &parent_compute_context_hash =
compute_context_generic->parent()->hash();
if (const auto *compute_context = dynamic_cast<const bke::SimulationZoneComputeContext *>(
compute_context_generic))
{
const bke::bNodeTreeZone *simulation_zone = current_zones->get_zone_by_node(
compute_context->output_node_id());
if (simulation_zone == nullptr) {
return;
Geometry Nodes: make evaluation and logging system aware of zones This refactors how a geometry nodes node tree is converted to a lazy-function graph. Previously, all nodes were inserted into a single graph. This was fine because every node was evaluated at most once per node group evaluation. However, loops (#108896) break this assumption since now nodes may be evaluated multiple times and thus a single flat graph does not work anymore. Now, a separate lazy-function is build for every zone which gives us much more flexibility for what can happen in a zone. Right now, the change only applies to simulation zones since that's the only kind of zone we have. Technically, those zones could be inlined, but turning them into a separate lazy-function also does not hurt and makes it possible to test this refactor without implementing loops first. Also, having them as separate functions might help in the future if we integrate a substep loop directly into the simulation zone. The most tricky part here is to just link everything up correctly, especially with respect to deterministic anonymous attribute lifetimes. Fortunately, correctness can be checked visually by looking at the generated graphs. The logging/viewer system also had to be refactored a bit, because now there can be multiple different `ComputeContext` in a single node tree. Each zone is in a separate `ComputeContext`. To make it work, the `ViewerPath` system now explicitly supports zones and drawing code will look up the right logger for showing inspection data. No functional changes are expected, except that the spreadsheet now shows "Simulation Zone" in the context path if the viewer is in a simulation.
2023-06-20 09:50:44 +02:00
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
if (simulation_zone->parent_zone != current_zone) {
return;
Geometry Nodes: new Repeat Zone This adds support for running a set of nodes repeatedly. The number of iterations can be controlled dynamically as an input of the repeat zone. The repeat zone can be added in via the search or from the Add > Utilities menu. The main use case is to replace long repetitive node chains with a more flexible alternative. Technically, repeat zones can also be used for many other use cases. However, due to their serial nature, performance is very sub-optimal when they are used to solve problems that could be processed in parallel. Better solutions for such use cases will be worked on separately. Repeat zones are similar to simulation zones. The major difference is that they have no concept of time and are always evaluated entirely in the current frame, while in simulations only a single iteration is evaluated per frame. Stopping the repetition early using a dynamic condition is not yet supported. "Break" functionality can be implemented manually using Switch nodes in the loop for now. It's likely that this functionality will be built into the repeat zone in the future. For now, things are kept more simple. Remaining Todos after this first version: * Improve socket inspection and viewer node support. Currently, only the first iteration is taken into account for socket inspection and the viewer. * Make loop evaluation more lazy. Currently, the evaluation is eager, meaning that it evaluates some nodes even though their output may not be required. Pull Request: https://projects.blender.org/blender/blender/pulls/109164
2023-07-11 22:36:10 +02:00
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
const lf::FunctionNode *lf_zone_node = lf_graph_info->mapping.zone_node_map.lookup_default(
simulation_zone, nullptr);
if (lf_zone_node == nullptr) {
return;
Geometry Nodes: make evaluation and logging system aware of zones This refactors how a geometry nodes node tree is converted to a lazy-function graph. Previously, all nodes were inserted into a single graph. This was fine because every node was evaluated at most once per node group evaluation. However, loops (#108896) break this assumption since now nodes may be evaluated multiple times and thus a single flat graph does not work anymore. Now, a separate lazy-function is build for every zone which gives us much more flexibility for what can happen in a zone. Right now, the change only applies to simulation zones since that's the only kind of zone we have. Technically, those zones could be inlined, but turning them into a separate lazy-function also does not hurt and makes it possible to test this refactor without implementing loops first. Also, having them as separate functions might help in the future if we integrate a substep loop directly into the simulation zone. The most tricky part here is to just link everything up correctly, especially with respect to deterministic anonymous attribute lifetimes. Fortunately, correctness can be checked visually by looking at the generated graphs. The logging/viewer system also had to be refactored a bit, because now there can be multiple different `ComputeContext` in a single node tree. Each zone is in a separate `ComputeContext`. To make it work, the `ViewerPath` system now explicitly supports zones and drawing code will look up the right logger for showing inspection data. No functional changes are expected, except that the spreadsheet now shows "Simulation Zone" in the context path if the viewer is in a simulation.
2023-06-20 09:50:44 +02:00
}
Fix #116820: make sure that simulation runs when it contains an active viewer Previously, the viewer node would work, but since the simulation output node was never evaluated, the new simulation state was never stored. Now make sure that the simulation output node is executed when there is an active viewer inside the simulation. Pull Request: https://projects.blender.org/blender/blender/pulls/118804
2024-02-27 20:37:52 +01:00
const lf::FunctionNode *lf_simulation_output_node =
lf_graph_info->mapping.possible_side_effect_node_map.lookup_default(
simulation_zone->output_node, nullptr);
if (lf_simulation_output_node == nullptr) {
return;
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
local_side_effect_nodes.nodes_by_context.add(parent_compute_context_hash, lf_zone_node);
Fix #116820: make sure that simulation runs when it contains an active viewer Previously, the viewer node would work, but since the simulation output node was never evaluated, the new simulation state was never stored. Now make sure that the simulation output node is executed when there is an active viewer inside the simulation. Pull Request: https://projects.blender.org/blender/blender/pulls/118804
2024-02-27 20:37:52 +01:00
/* By making the simulation output node a side-effect-node, we can ensure that the simulation
* runs when it contains an active viewer. */
local_side_effect_nodes.nodes_by_context.add(compute_context_generic->hash(),
lf_simulation_output_node);
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
current_zone = simulation_zone;
}
else if (const auto *compute_context = dynamic_cast<const bke::RepeatZoneComputeContext *>(
compute_context_generic))
{
const bke::bNodeTreeZone *repeat_zone = current_zones->get_zone_by_node(
compute_context->output_node_id());
if (repeat_zone == nullptr) {
return;
}
if (repeat_zone->parent_zone != current_zone) {
return;
}
const lf::FunctionNode *lf_zone_node = lf_graph_info->mapping.zone_node_map.lookup_default(
repeat_zone, nullptr);
if (lf_zone_node == nullptr) {
Geometry Nodes: make evaluation and logging system aware of zones This refactors how a geometry nodes node tree is converted to a lazy-function graph. Previously, all nodes were inserted into a single graph. This was fine because every node was evaluated at most once per node group evaluation. However, loops (#108896) break this assumption since now nodes may be evaluated multiple times and thus a single flat graph does not work anymore. Now, a separate lazy-function is build for every zone which gives us much more flexibility for what can happen in a zone. Right now, the change only applies to simulation zones since that's the only kind of zone we have. Technically, those zones could be inlined, but turning them into a separate lazy-function also does not hurt and makes it possible to test this refactor without implementing loops first. Also, having them as separate functions might help in the future if we integrate a substep loop directly into the simulation zone. The most tricky part here is to just link everything up correctly, especially with respect to deterministic anonymous attribute lifetimes. Fortunately, correctness can be checked visually by looking at the generated graphs. The logging/viewer system also had to be refactored a bit, because now there can be multiple different `ComputeContext` in a single node tree. Each zone is in a separate `ComputeContext`. To make it work, the `ViewerPath` system now explicitly supports zones and drawing code will look up the right logger for showing inspection data. No functional changes are expected, except that the spreadsheet now shows "Simulation Zone" in the context path if the viewer is in a simulation.
2023-06-20 09:50:44 +02:00
return;
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
local_side_effect_nodes.nodes_by_context.add(parent_compute_context_hash, lf_zone_node);
Geometry Nodes: new For Each Geometry Element zone This adds a new type of zone to Geometry Nodes that allows executing some nodes for each element in a geometry. ## Features * The `Selection` input allows iterating over a subset of elements on the set domain. * Fields passed into the input node are available as single values inside of the zone. * The input geometry can be split up into separate (completely independent) geometries for each element (on all domains except face corner). * New attributes can be created on the input geometry by outputting a single value from each iteration. * New geometries can be generated in each iteration. * All of these geometries are joined to form the final output. * Attributes from the input geometry are propagated to the output geometries. ## Evaluation The evaluation strategy is similar to the one used for repeat zones. Namely, it dynamically builds a `lazy_function::Graph` once it knows how many iterations are necessary. It contains a separate node for each iteration. The inputs for each iteration are hardcoded into the graph. The outputs of each iteration a passed to a separate lazy-function that reduces all the values down to the final outputs. This final output can have a huge number of inputs and that is not ideal for multi-threading yet, but that can still be improved in the future. ## Performance There is a non-neglilible amount of overhead for each iteration. The overhead is way larger than the per-element overhead when just doing field evaluation. Therefore, normal field evaluation should be preferred when possible. That can partially still be optimized if there is only some number crunching going on in the zone but that optimization is not implemented yet. However, processing many small geometries (e.g. each hair of a character separately) will likely **always be slower** than working on fewer larger geoemtries. The additional flexibility you get by processing each element separately comes at the cost that Blender can't optimize the operation as well. For node groups that need to handle lots of geometry elements, we recommend trying to design the node setup so that iteration over tiny sub-geometries is not required. An opposite point is true as well though. It can be faster to process more medium sized geometries in parallel than fewer very large geometries because of more multi-threading opportunities. The exact threshold between tiny, medium and large geometries depends on a lot of factors though. Overall, this initial version of the new zone does not implement all optimization opportunities yet, but the points mentioned above will still hold true later. Pull Request: https://projects.blender.org/blender/blender/pulls/127331
2024-09-24 11:52:02 +02:00
local_side_effect_nodes.iterations_by_iteration_zone.add(
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
{parent_compute_context_hash, compute_context->output_node_id()},
compute_context->iteration());
current_zone = repeat_zone;
}
Geometry Nodes: new For Each Geometry Element zone This adds a new type of zone to Geometry Nodes that allows executing some nodes for each element in a geometry. ## Features * The `Selection` input allows iterating over a subset of elements on the set domain. * Fields passed into the input node are available as single values inside of the zone. * The input geometry can be split up into separate (completely independent) geometries for each element (on all domains except face corner). * New attributes can be created on the input geometry by outputting a single value from each iteration. * New geometries can be generated in each iteration. * All of these geometries are joined to form the final output. * Attributes from the input geometry are propagated to the output geometries. ## Evaluation The evaluation strategy is similar to the one used for repeat zones. Namely, it dynamically builds a `lazy_function::Graph` once it knows how many iterations are necessary. It contains a separate node for each iteration. The inputs for each iteration are hardcoded into the graph. The outputs of each iteration a passed to a separate lazy-function that reduces all the values down to the final outputs. This final output can have a huge number of inputs and that is not ideal for multi-threading yet, but that can still be improved in the future. ## Performance There is a non-neglilible amount of overhead for each iteration. The overhead is way larger than the per-element overhead when just doing field evaluation. Therefore, normal field evaluation should be preferred when possible. That can partially still be optimized if there is only some number crunching going on in the zone but that optimization is not implemented yet. However, processing many small geometries (e.g. each hair of a character separately) will likely **always be slower** than working on fewer larger geoemtries. The additional flexibility you get by processing each element separately comes at the cost that Blender can't optimize the operation as well. For node groups that need to handle lots of geometry elements, we recommend trying to design the node setup so that iteration over tiny sub-geometries is not required. An opposite point is true as well though. It can be faster to process more medium sized geometries in parallel than fewer very large geometries because of more multi-threading opportunities. The exact threshold between tiny, medium and large geometries depends on a lot of factors though. Overall, this initial version of the new zone does not implement all optimization opportunities yet, but the points mentioned above will still hold true later. Pull Request: https://projects.blender.org/blender/blender/pulls/127331
2024-09-24 11:52:02 +02:00
else if (const auto *compute_context =
dynamic_cast<const bke::ForeachGeometryElementZoneComputeContext *>(
compute_context_generic))
{
const bke::bNodeTreeZone *foreach_zone = current_zones->get_zone_by_node(
compute_context->output_node_id());
if (foreach_zone == nullptr) {
return;
}
if (foreach_zone->parent_zone != current_zone) {
return;
}
const lf::FunctionNode *lf_zone_node = lf_graph_info->mapping.zone_node_map.lookup_default(
foreach_zone, nullptr);
if (lf_zone_node == nullptr) {
return;
}
local_side_effect_nodes.nodes_by_context.add(parent_compute_context_hash, lf_zone_node);
local_side_effect_nodes.iterations_by_iteration_zone.add(
{parent_compute_context_hash, compute_context->output_node_id()},
compute_context->index());
current_zone = foreach_zone;
}
Cleanup: rename node group to group node context `GroupNodeComputeContext` is the more correct name because it's specifically about a group node that invokes another node tree. The old name makes it sound like it should be used because a node group is invoked but does not tell anything about what invoked it. For example, the current context in a node group can also be a `ModifierComputeContext` if that's what invoked it.
2023-11-21 14:12:07 +01:00
else if (const auto *compute_context = dynamic_cast<const bke::GroupNodeComputeContext *>(
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
compute_context_generic))
{
const bNode *group_node = current_tree->node_by_id(compute_context->node_id());
if (group_node == nullptr) {
return;
}
if (group_node->id == nullptr) {
return;
}
if (group_node->is_muted()) {
return;
}
if (current_zone != current_zones->get_zone_by_node(group_node->identifier)) {
return;
}
const lf::FunctionNode *lf_group_node = lf_graph_info->mapping.group_node_map.lookup_default(
group_node, nullptr);
if (lf_group_node == nullptr) {
return;
}
local_side_effect_nodes.nodes_by_context.add(parent_compute_context_hash, lf_group_node);
current_tree = reinterpret_cast<const bNodeTree *>(group_node->id);
current_zone = nullptr;
}
Geometry Nodes: support viewers in closures This adds support for having viewer nodes in closures. The code attempt to detect where the closure is evaluated and shows the data from there. If the closure is evaluated in multiple Evaluate Closure nodes, currently it just picks the first one it finds. Support for more user control in this case may be added a bit later. If the Evaluate Closure node is in e.g. the repeat or foreach zone, it will automatically use the inspection index of that zone to determine what evaluation to look at specifically. Overall, not too much had to change conceptually to support viewers in closures. Just some code like converting between viewer paths and compute contexts had to be generalized a little bit. Pull Request: https://projects.blender.org/blender/blender/pulls/137625
2025-04-16 23:35:59 +02:00
else if (const auto *compute_context =
dynamic_cast<const bke::EvaluateClosureComputeContext *>(compute_context_generic))
{
const bNode *evaluate_node = current_tree->node_by_id(compute_context->node_id());
if (!evaluate_node) {
return;
}
if (evaluate_node->is_muted()) {
return;
}
if (current_zone != current_zones->get_zone_by_node(evaluate_node->identifier)) {
return;
}
const std::optional<nodes::ClosureSourceLocation> &source_location =
compute_context->closure_source_location();
if (!source_location) {
return;
}
if (!source_location->tree->zones()) {
return;
}
const lf::FunctionNode *lf_evaluate_node =
lf_graph_info->mapping.possible_side_effect_node_map.lookup_default(evaluate_node,
nullptr);
if (!lf_evaluate_node) {
return;
}
/* The tree may sometimes be original and sometimes evaluated, depending on the source of the
* compute context. */
Refactor: Depsgraph: simplify query API further * Remove `DEG_get_evaluated_object` in favor of `DEG_get_evaluated`. * Remove `DEG_is_original_object` in favor of `DEG_is_original`. * Remove `DEG_is_evaluated_object` in favor of `DEG_is_evaluated`. Pull Request: https://projects.blender.org/blender/blender/pulls/138317
2025-05-02 15:08:29 +02:00
const bNodeTree *eval_closure_tree = DEG_is_evaluated(source_location->tree) ?
Geometry Nodes: support viewers in closures This adds support for having viewer nodes in closures. The code attempt to detect where the closure is evaluated and shows the data from there. If the closure is evaluated in multiple Evaluate Closure nodes, currently it just picks the first one it finds. Support for more user control in this case may be added a bit later. If the Evaluate Closure node is in e.g. the repeat or foreach zone, it will automatically use the inspection index of that zone to determine what evaluation to look at specifically. Overall, not too much had to change conceptually to support viewers in closures. Just some code like converting between viewer paths and compute contexts had to be generalized a little bit. Pull Request: https://projects.blender.org/blender/blender/pulls/137625
2025-04-16 23:35:59 +02:00
source_location->tree :
reinterpret_cast<const bNodeTree *>(
DEG_get_evaluated_id(
ctx.depsgraph, &source_location->tree->id));
const bNode *closure_output_node = eval_closure_tree->node_by_id(
source_location->closure_output_node_id);
if (!closure_output_node) {
return;
}
local_side_effect_nodes.nodes_by_context.add(parent_compute_context_hash, lf_evaluate_node);
current_tree = eval_closure_tree;
current_zone = eval_closure_tree->zones()->get_zone_by_node(closure_output_node->identifier);
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
else {
return;
Fix T102153: crash when muting node group with active viewer
2022-11-06 15:39:57 +01:00
}
Spreadsheet: breadcrumbs and node pinning This introduces a context path to the spreadsheet editor, which contains information about what data is shown in the spreadsheet. The context path (breadcrumbs) can reference a specific node in a node group hierarchy. During object evaluation, the geometry nodes modifier checks what data is currently requested by visible spreadsheets and stores the corresponding geometry sets separately for later access. The context path can be updated by the user explicitely, by clicking on the new icon in the header of nodes. Under some circumstances, the context path is updated automatically based on Blender's context. This patch also consolidates the "Node" and "Final" object evaluation mode to just "Evaluated". Based on the current context path, either the final geometry set of an object will be displayed, or the data at a specific node. The new preview icon in geometry nodes now behaves more like a toggle. It can be clicked again to clear the context path in an open spreadsheet editor. Previously, only an object could be pinned in the spreadsheet editor. Now it is possible to pin the entire context path. That allows two different spreadsheets to display geometry data from two different nodes. The breadcrumbs in the spreadsheet header can be collapsed by clicking on the arrow icons. It's not ideal but works well for now. This might be changed again, if we get a data set region on the left. Differential Revision: https://developer.blender.org/D10931
2021-04-15 08:57:10 +02:00
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
const bNode *final_node = current_tree->node_by_id(final_node_id);
if (final_node == nullptr) {
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
return;
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
const auto *lf_graph_info = nodes::ensure_geometry_nodes_lazy_function_graph(*current_tree);
Geometry Nodes: make evaluation and logging system aware of zones This refactors how a geometry nodes node tree is converted to a lazy-function graph. Previously, all nodes were inserted into a single graph. This was fine because every node was evaluated at most once per node group evaluation. However, loops (#108896) break this assumption since now nodes may be evaluated multiple times and thus a single flat graph does not work anymore. Now, a separate lazy-function is build for every zone which gives us much more flexibility for what can happen in a zone. Right now, the change only applies to simulation zones since that's the only kind of zone we have. Technically, those zones could be inlined, but turning them into a separate lazy-function also does not hurt and makes it possible to test this refactor without implementing loops first. Also, having them as separate functions might help in the future if we integrate a substep loop directly into the simulation zone. The most tricky part here is to just link everything up correctly, especially with respect to deterministic anonymous attribute lifetimes. Fortunately, correctness can be checked visually by looking at the generated graphs. The logging/viewer system also had to be refactored a bit, because now there can be multiple different `ComputeContext` in a single node tree. Each zone is in a separate `ComputeContext`. To make it work, the `ViewerPath` system now explicitly supports zones and drawing code will look up the right logger for showing inspection data. No functional changes are expected, except that the spreadsheet now shows "Simulation Zone" in the context path if the viewer is in a simulation.
2023-06-20 09:50:44 +02:00
if (lf_graph_info == nullptr) {
return;
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
const bke::bNodeTreeZones *tree_zones = current_tree->zones();
Geometry Nodes: make evaluation and logging system aware of zones This refactors how a geometry nodes node tree is converted to a lazy-function graph. Previously, all nodes were inserted into a single graph. This was fine because every node was evaluated at most once per node group evaluation. However, loops (#108896) break this assumption since now nodes may be evaluated multiple times and thus a single flat graph does not work anymore. Now, a separate lazy-function is build for every zone which gives us much more flexibility for what can happen in a zone. Right now, the change only applies to simulation zones since that's the only kind of zone we have. Technically, those zones could be inlined, but turning them into a separate lazy-function also does not hurt and makes it possible to test this refactor without implementing loops first. Also, having them as separate functions might help in the future if we integrate a substep loop directly into the simulation zone. The most tricky part here is to just link everything up correctly, especially with respect to deterministic anonymous attribute lifetimes. Fortunately, correctness can be checked visually by looking at the generated graphs. The logging/viewer system also had to be refactored a bit, because now there can be multiple different `ComputeContext` in a single node tree. Each zone is in a separate `ComputeContext`. To make it work, the `ViewerPath` system now explicitly supports zones and drawing code will look up the right logger for showing inspection data. No functional changes are expected, except that the spreadsheet now shows "Simulation Zone" in the context path if the viewer is in a simulation.
2023-06-20 09:50:44 +02:00
if (tree_zones == nullptr) {
return;
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
if (tree_zones->get_zone_by_node(final_node_id) != current_zone) {
Geometry Nodes: make evaluation and logging system aware of zones This refactors how a geometry nodes node tree is converted to a lazy-function graph. Previously, all nodes were inserted into a single graph. This was fine because every node was evaluated at most once per node group evaluation. However, loops (#108896) break this assumption since now nodes may be evaluated multiple times and thus a single flat graph does not work anymore. Now, a separate lazy-function is build for every zone which gives us much more flexibility for what can happen in a zone. Right now, the change only applies to simulation zones since that's the only kind of zone we have. Technically, those zones could be inlined, but turning them into a separate lazy-function also does not hurt and makes it possible to test this refactor without implementing loops first. Also, having them as separate functions might help in the future if we integrate a substep loop directly into the simulation zone. The most tricky part here is to just link everything up correctly, especially with respect to deterministic anonymous attribute lifetimes. Fortunately, correctness can be checked visually by looking at the generated graphs. The logging/viewer system also had to be refactored a bit, because now there can be multiple different `ComputeContext` in a single node tree. Each zone is in a separate `ComputeContext`. To make it work, the `ViewerPath` system now explicitly supports zones and drawing code will look up the right logger for showing inspection data. No functional changes are expected, except that the spreadsheet now shows "Simulation Zone" in the context path if the viewer is in a simulation.
2023-06-20 09:50:44 +02:00
return;
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
const lf::FunctionNode *lf_node =
lf_graph_info->mapping.possible_side_effect_node_map.lookup_default(final_node, nullptr);
if (lf_node == nullptr) {
Fix #102882: Geometry Nodes: crash when using viewer in invalid group Invalid node trees (e.g. when nodes are linked in a cycle) can not be evaluated and the viewer is not available in them. This commit just adds some null checks to handle this case more gracefully.
2023-02-22 18:42:15 +01:00
return;
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
local_side_effect_nodes.nodes_by_context.add(final_compute_context.hash(), lf_node);
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
Geometry Nodes: use separate struct for side effect nodes This makes it easier to add another map containing side effect nodes in #112421. No functional changes expected.
2023-09-16 18:57:04 +02:00
/* Successfully found all side effect nodes for the viewer path. */
for (const auto item : local_side_effect_nodes.nodes_by_context.items()) {
r_side_effect_nodes.nodes_by_context.add_multiple(item.key, item.value);
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
}
Geometry Nodes: new For Each Geometry Element zone This adds a new type of zone to Geometry Nodes that allows executing some nodes for each element in a geometry. ## Features * The `Selection` input allows iterating over a subset of elements on the set domain. * Fields passed into the input node are available as single values inside of the zone. * The input geometry can be split up into separate (completely independent) geometries for each element (on all domains except face corner). * New attributes can be created on the input geometry by outputting a single value from each iteration. * New geometries can be generated in each iteration. * All of these geometries are joined to form the final output. * Attributes from the input geometry are propagated to the output geometries. ## Evaluation The evaluation strategy is similar to the one used for repeat zones. Namely, it dynamically builds a `lazy_function::Graph` once it knows how many iterations are necessary. It contains a separate node for each iteration. The inputs for each iteration are hardcoded into the graph. The outputs of each iteration a passed to a separate lazy-function that reduces all the values down to the final outputs. This final output can have a huge number of inputs and that is not ideal for multi-threading yet, but that can still be improved in the future. ## Performance There is a non-neglilible amount of overhead for each iteration. The overhead is way larger than the per-element overhead when just doing field evaluation. Therefore, normal field evaluation should be preferred when possible. That can partially still be optimized if there is only some number crunching going on in the zone but that optimization is not implemented yet. However, processing many small geometries (e.g. each hair of a character separately) will likely **always be slower** than working on fewer larger geoemtries. The additional flexibility you get by processing each element separately comes at the cost that Blender can't optimize the operation as well. For node groups that need to handle lots of geometry elements, we recommend trying to design the node setup so that iteration over tiny sub-geometries is not required. An opposite point is true as well though. It can be faster to process more medium sized geometries in parallel than fewer very large geometries because of more multi-threading opportunities. The exact threshold between tiny, medium and large geometries depends on a lot of factors though. Overall, this initial version of the new zone does not implement all optimization opportunities yet, but the points mentioned above will still hold true later. Pull Request: https://projects.blender.org/blender/blender/pulls/127331
2024-09-24 11:52:02 +02:00
for (const auto item : local_side_effect_nodes.iterations_by_iteration_zone.items()) {
r_side_effect_nodes.iterations_by_iteration_zone.add_multiple(item.key, item.value);
Geometry Nodes: use lazy evaluation in repeat zone The goal is to make the evaluation of repeat zones more efficient by making use of the lazy-function evaluation system. Performance is improved in two ways: * Unnecessary nodes are not evaluated anymore. E.g. if a repeat zone outputs two geometries but only one of those is actually used, the other one will not be computed anymore. * Support evaluating different iteration indices at the same time on different threads. It is possible that some uses of repeat zones become slower with this refactor, especially when each iteration does very little work and there are a lot of iterations. The old implementation was not optimized for this use case either but now there is a bit more overhead constant overhead per iteration than before. On the bright side, this change can result in some very significant speedups when some computations can be skipped. See #112421 for some example setups. There is one todo comment for adding back-links for socket usages. Properly linking those up can result in better (shorter) life-times for anonymous attributes. Even without that, performance is already better than before. The implementation reuses the existing lazy-function graph system for the repeat zone, by building a dynamically sized graph based on the number of iterations. Building a lazy-function graph makes it possible to use the lazyness and multi-threading features of the lazy-function graph executor. This is much easier than reimplementing this behavior for repeat zones specifically (hence there was only single-threaded eager execution before). Pull Request: https://projects.blender.org/blender/blender/pulls/112421
2023-09-22 08:58:16 +02:00
}
Spreadsheet: support showing data of specific node Previously, the spreadsheet editor could only show data of the original and of the final evaluated object. Now it is possible to show the data at some intermediate stages too. For that the mode has to be set to "Node" in the spreadsheet editor. Furthermore, the preview of a specific node has to be activated by clicking the new icon in the header of geometry nodes. The exact ui of this feature might be refined in upcoming commits. It is already very useful for debugging node groups in it's current state though. Differential Revision: https://developer.blender.org/D10875
2021-04-08 17:35:06 +02:00
}
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
static void find_side_effect_nodes_for_viewer_path(
const ViewerPath &viewer_path,
const NodesModifierData &nmd,
const ModifierEvalContext &ctx,
nodes::GeoNodesSideEffectNodes &r_side_effect_nodes)
{
const std::optional<ed::viewer_path::ViewerPathForGeometryNodesViewer> parsed_path =
ed::viewer_path::parse_geometry_nodes_viewer(viewer_path);
if (!parsed_path.has_value()) {
return;
}
Depsgraph: improve type safety when getting evaluated or original ID The goal here is to avoid having to cast to and from `ID` when getting the evaluated or original ID using the depsgraph API, which is often verbose and not type safe. To solve this, there are now `DEG_get_original` and `DEG_get_evaluated` methods which are templated on the type and use a new `is_ID_v` static type check to make sure it's only used with valid types. This allows removing quite some verbosity on all the call sites. I also removed `DEG_get_original_object`, because that does not have to be a special case anymore. Pull Request: https://projects.blender.org/blender/blender/pulls/137629
2025-04-17 13:09:20 +02:00
if (parsed_path->object != DEG_get_original(ctx.object)) {
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
return;
}
if (parsed_path->modifier_name != nmd.modifier.name) {
return;
}
Refactor: Geometry Nodes: replace ComputeContextBuilder with ComputeContextCache While `ComputeContextBuilder` worked well for building simple linear compute contexts, it was fairly limiting for all the slightly more complex cases where an entire tree of compute contexts is built. Using `ComputeContextCache` that is easier to do more explicitly. There were only very few cases where using `ComputeContextBuilder` would have still helped a bit, but it's not really worth keeping that abstraction around just for those few cases. Pull Request: https://projects.blender.org/blender/blender/pulls/137370
2025-04-14 17:47:56 +02:00
bke::ComputeContextCache compute_context_cache;
const ComputeContext *current = &compute_context_cache.for_modifier(nullptr, nmd);
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
for (const ViewerPathElem *elem : parsed_path->node_path) {
Refactor: Geometry Nodes: replace ComputeContextBuilder with ComputeContextCache While `ComputeContextBuilder` worked well for building simple linear compute contexts, it was fairly limiting for all the slightly more complex cases where an entire tree of compute contexts is built. Using `ComputeContextCache` that is easier to do more explicitly. There were only very few cases where using `ComputeContextBuilder` would have still helped a bit, but it's not really worth keeping that abstraction around just for those few cases. Pull Request: https://projects.blender.org/blender/blender/pulls/137370
2025-04-14 17:47:56 +02:00
current = ed::viewer_path::compute_context_for_viewer_path_elem(
*elem, compute_context_cache, current);
if (!current) {
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
return;
}
}
Geometry Nodes: support viewers in closures This adds support for having viewer nodes in closures. The code attempt to detect where the closure is evaluated and shows the data from there. If the closure is evaluated in multiple Evaluate Closure nodes, currently it just picks the first one it finds. Support for more user control in this case may be added a bit later. If the Evaluate Closure node is in e.g. the repeat or foreach zone, it will automatically use the inspection index of that zone to determine what evaluation to look at specifically. Overall, not too much had to change conceptually to support viewers in closures. Just some code like converting between viewer paths and compute contexts had to be generalized a little bit. Pull Request: https://projects.blender.org/blender/blender/pulls/137625
2025-04-16 23:35:59 +02:00
try_add_side_effect_node(ctx, *current, parsed_path->viewer_node_id, nmd, r_side_effect_nodes);
Geometry Nodes: refactor how side effect nodes are set up Previously, the geometry nodes modifier was converting the viewer path to a compute context at the same time as it was setting up side effect nodes for the geometry nodes evaluation. Now, this is changed to be a two step process. First, the viewer path is converted to the corresponding compute context. Afterwards, a separate function sets side effect nodes up so that the given node in the given compute context will be evaluated. This has three main benefits: * More obvious separation of concerns. * Can reuse the code that maps a viewer path element to a compute context already. * With gizmo nodes (#112677), it may become necessary to add side effect nodes based on a compute context, but without having a corresponding viewer path.
2023-10-03 14:12:12 +02:00
}
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
static void find_side_effect_nodes_for_nested_node(
Geometry Nodes: support viewers in closures This adds support for having viewer nodes in closures. The code attempt to detect where the closure is evaluated and shows the data from there. If the closure is evaluated in multiple Evaluate Closure nodes, currently it just picks the first one it finds. Support for more user control in this case may be added a bit later. If the Evaluate Closure node is in e.g. the repeat or foreach zone, it will automatically use the inspection index of that zone to determine what evaluation to look at specifically. Overall, not too much had to change conceptually to support viewers in closures. Just some code like converting between viewer paths and compute contexts had to be generalized a little bit. Pull Request: https://projects.blender.org/blender/blender/pulls/137625
2025-04-16 23:35:59 +02:00
const ModifierEvalContext &ctx,
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
const NodesModifierData &nmd,
const int root_nested_node_id,
nodes::GeoNodesSideEffectNodes &r_side_effect_nodes)
{
Refactor: Geometry Nodes: replace ComputeContextBuilder with ComputeContextCache While `ComputeContextBuilder` worked well for building simple linear compute contexts, it was fairly limiting for all the slightly more complex cases where an entire tree of compute contexts is built. Using `ComputeContextCache` that is easier to do more explicitly. There were only very few cases where using `ComputeContextBuilder` would have still helped a bit, but it's not really worth keeping that abstraction around just for those few cases. Pull Request: https://projects.blender.org/blender/blender/pulls/137370
2025-04-14 17:47:56 +02:00
bke::ComputeContextCache compute_context_cache;
const ComputeContext *compute_context = &compute_context_cache.for_modifier(nullptr, nmd);
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
int nested_node_id = root_nested_node_id;
const bNodeTree *tree = nmd.node_group;
while (true) {
const bNestedNodeRef *ref = tree->find_nested_node_ref(nested_node_id);
if (!ref) {
return;
}
const bNode *node = tree->node_by_id(ref->path.node_id);
if (!node) {
return;
}
const bke::bNodeTreeZones *zones = tree->zones();
if (!zones) {
return;
}
if (zones->get_zone_by_node(node->identifier) != nullptr) {
/* Only top level nodes are allowed here. */
return;
}
if (node->is_group()) {
if (!node->id) {
return;
}
Refactor: Geometry Nodes: replace ComputeContextBuilder with ComputeContextCache While `ComputeContextBuilder` worked well for building simple linear compute contexts, it was fairly limiting for all the slightly more complex cases where an entire tree of compute contexts is built. Using `ComputeContextCache` that is easier to do more explicitly. There were only very few cases where using `ComputeContextBuilder` would have still helped a bit, but it's not really worth keeping that abstraction around just for those few cases. Pull Request: https://projects.blender.org/blender/blender/pulls/137370
2025-04-14 17:47:56 +02:00
compute_context = &compute_context_cache.for_group_node(compute_context, *node, *tree);
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
tree = reinterpret_cast<const bNodeTree *>(node->id);
nested_node_id = ref->path.id_in_node;
}
else {
Geometry Nodes: support viewers in closures This adds support for having viewer nodes in closures. The code attempt to detect where the closure is evaluated and shows the data from there. If the closure is evaluated in multiple Evaluate Closure nodes, currently it just picks the first one it finds. Support for more user control in this case may be added a bit later. If the Evaluate Closure node is in e.g. the repeat or foreach zone, it will automatically use the inspection index of that zone to determine what evaluation to look at specifically. Overall, not too much had to change conceptually to support viewers in closures. Just some code like converting between viewer paths and compute contexts had to be generalized a little bit. Pull Request: https://projects.blender.org/blender/blender/pulls/137625
2025-04-16 23:35:59 +02:00
try_add_side_effect_node(ctx, *compute_context, ref->path.node_id, nmd, r_side_effect_nodes);
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
return;
}
}
}
/**
* This ensures that nodes that the user wants to bake are actually evaluated. Otherwise they might
* not be if they are not connected to the output.
*/
static void find_side_effect_nodes_for_baking(const NodesModifierData &nmd,
const ModifierEvalContext &ctx,
nodes::GeoNodesSideEffectNodes &r_side_effect_nodes)
{
if (!nmd.runtime->cache) {
return;
}
if (!DEG_is_active(ctx.depsgraph)) {
/* Only the active depsgraph can bake. */
return;
}
bake::ModifierCache &modifier_cache = *nmd.runtime->cache;
for (const bNestedNodeRef &ref : nmd.node_group->nested_node_refs_span()) {
if (!modifier_cache.requested_bakes.contains(ref.id)) {
continue;
}
Geometry Nodes: support viewers in closures This adds support for having viewer nodes in closures. The code attempt to detect where the closure is evaluated and shows the data from there. If the closure is evaluated in multiple Evaluate Closure nodes, currently it just picks the first one it finds. Support for more user control in this case may be added a bit later. If the Evaluate Closure node is in e.g. the repeat or foreach zone, it will automatically use the inspection index of that zone to determine what evaluation to look at specifically. Overall, not too much had to change conceptually to support viewers in closures. Just some code like converting between viewer paths and compute contexts had to be generalized a little bit. Pull Request: https://projects.blender.org/blender/blender/pulls/137625
2025-04-16 23:35:59 +02:00
find_side_effect_nodes_for_nested_node(ctx, nmd, ref.id, r_side_effect_nodes);
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
}
}
Geometry Nodes: support attaching gizmos to input values This adds support for attaching gizmos for input values. The goal is to make it easier for users to set input values intuitively in the 3D viewport. We went through multiple different possible designs until we settled on the one implemented here. We picked it for it's flexibility and ease of use when using geometry node assets. The core principle in the design is that **gizmos are attached to existing input values instead of being the input value themselves**. This actually fits the existing concept of gizmos in Blender well, but may be a bit unintutitive in a node setup at first. The attachment is done using links in the node editor. The most basic usage of the node is to link a Value node to the new Linear Gizmo node. This attaches the gizmo to the input value and allows you to change it from the 3D view. The attachment is indicated by the gizmo icon in the sockets which are controlled by a gizmo as well as the back-link (notice the double link) when the gizmo is active. The core principle makes it straight forward to control the same node setup from the 3D view with gizmos, or by manually changing input values, or by driving the input values procedurally. If the input value is controlled indirectly by other inputs, it's often possible to **automatically propagate** the gizmo to the actual input. Backpropagation does not work for all nodes, although more nodes can be supported over time. This patch adds the first three gizmo nodes which cover common use cases: * **Linear Gizmo**: Creates a gizmo that controls a float or integer value using a linear movement of e.g. an arrow in the 3D viewport. * **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be rotated to change the attached angle input. * **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale. In the future, more built-in gizmos and potentially the ability for custom gizmos could be added. All gizmo nodes have a **Transform** geometry output. Using it is optional but it is recommended when the gizmo is used to control inputs that affect a geometry. When it is used, Blender will automatically transform the gizmos together with the geometry that they control. To achieve this, the output should be merged with the generated geometry using the *Join Geometry* node. The data contained in *Transform* output is not visible geometry, but just internal information that helps Blender to give a better user experience when using gizmos. The gizmo nodes have a multi-input socket. This allows **controlling multiple values** with the same gizmo. Only a small set of **gizmo shapes** is supported initially. It might be extended in the future but one goal is to give the gizmos used by different node group assets a familiar look and feel. A similar constraint exists for **colors**. Currently, one can choose from a fixed set of colors which can be modified in the theme settings. The set of **visible gizmos** is determined by a multiple factors because it's not really feasible to show all possible gizmos at all times. To see any of the geometry nodes gizmos, the "Active Modifier" option has to be enabled in the "Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of the following is true: * The gizmo controls an input of the active modifier of the active object. * The gizmo controls a value in a selected node in an open node editor. * The gizmo controls a pinned value in an open node editor. Pinning works by clicking the gizmo icon next to the value. Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
static void find_side_effect_nodes_for_active_gizmos(
const NodesModifierData &nmd,
const ModifierEvalContext &ctx,
const wmWindowManager &wm,
nodes::GeoNodesSideEffectNodes &r_side_effect_nodes,
Set<ComputeContextHash> &r_socket_log_contexts)
{
Depsgraph: improve type safety when getting evaluated or original ID The goal here is to avoid having to cast to and from `ID` when getting the evaluated or original ID using the depsgraph API, which is often verbose and not type safe. To solve this, there are now `DEG_get_original` and `DEG_get_evaluated` methods which are templated on the type and use a new `is_ID_v` static type check to make sure it's only used with valid types. This allows removing quite some verbosity on all the call sites. I also removed `DEG_get_original_object`, because that does not have to be a special case anymore. Pull Request: https://projects.blender.org/blender/blender/pulls/137629
2025-04-17 13:09:20 +02:00
Object *object_orig = DEG_get_original(ctx.object);
Geometry Nodes: support attaching gizmos to input values This adds support for attaching gizmos for input values. The goal is to make it easier for users to set input values intuitively in the 3D viewport. We went through multiple different possible designs until we settled on the one implemented here. We picked it for it's flexibility and ease of use when using geometry node assets. The core principle in the design is that **gizmos are attached to existing input values instead of being the input value themselves**. This actually fits the existing concept of gizmos in Blender well, but may be a bit unintutitive in a node setup at first. The attachment is done using links in the node editor. The most basic usage of the node is to link a Value node to the new Linear Gizmo node. This attaches the gizmo to the input value and allows you to change it from the 3D view. The attachment is indicated by the gizmo icon in the sockets which are controlled by a gizmo as well as the back-link (notice the double link) when the gizmo is active. The core principle makes it straight forward to control the same node setup from the 3D view with gizmos, or by manually changing input values, or by driving the input values procedurally. If the input value is controlled indirectly by other inputs, it's often possible to **automatically propagate** the gizmo to the actual input. Backpropagation does not work for all nodes, although more nodes can be supported over time. This patch adds the first three gizmo nodes which cover common use cases: * **Linear Gizmo**: Creates a gizmo that controls a float or integer value using a linear movement of e.g. an arrow in the 3D viewport. * **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be rotated to change the attached angle input. * **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale. In the future, more built-in gizmos and potentially the ability for custom gizmos could be added. All gizmo nodes have a **Transform** geometry output. Using it is optional but it is recommended when the gizmo is used to control inputs that affect a geometry. When it is used, Blender will automatically transform the gizmos together with the geometry that they control. To achieve this, the output should be merged with the generated geometry using the *Join Geometry* node. The data contained in *Transform* output is not visible geometry, but just internal information that helps Blender to give a better user experience when using gizmos. The gizmo nodes have a multi-input socket. This allows **controlling multiple values** with the same gizmo. Only a small set of **gizmo shapes** is supported initially. It might be extended in the future but one goal is to give the gizmos used by different node group assets a familiar look and feel. A similar constraint exists for **colors**. Currently, one can choose from a fixed set of colors which can be modified in the theme settings. The set of **visible gizmos** is determined by a multiple factors because it's not really feasible to show all possible gizmos at all times. To see any of the geometry nodes gizmos, the "Active Modifier" option has to be enabled in the "Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of the following is true: * The gizmo controls an input of the active modifier of the active object. * The gizmo controls a value in a selected node in an open node editor. * The gizmo controls a pinned value in an open node editor. Pinning works by clicking the gizmo icon next to the value. Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
const NodesModifierData &nmd_orig = *reinterpret_cast<const NodesModifierData *>(
BKE_modifier_get_original(ctx.object, const_cast<ModifierData *>(&nmd.modifier)));
Refactor: Geometry Nodes: replace ComputeContextBuilder with ComputeContextCache While `ComputeContextBuilder` worked well for building simple linear compute contexts, it was fairly limiting for all the slightly more complex cases where an entire tree of compute contexts is built. Using `ComputeContextCache` that is easier to do more explicitly. There were only very few cases where using `ComputeContextBuilder` would have still helped a bit, but it's not really worth keeping that abstraction around just for those few cases. Pull Request: https://projects.blender.org/blender/blender/pulls/137370
2025-04-14 17:47:56 +02:00
bke::ComputeContextCache compute_context_cache;
Geometry Nodes: support attaching gizmos to input values This adds support for attaching gizmos for input values. The goal is to make it easier for users to set input values intuitively in the 3D viewport. We went through multiple different possible designs until we settled on the one implemented here. We picked it for it's flexibility and ease of use when using geometry node assets. The core principle in the design is that **gizmos are attached to existing input values instead of being the input value themselves**. This actually fits the existing concept of gizmos in Blender well, but may be a bit unintutitive in a node setup at first. The attachment is done using links in the node editor. The most basic usage of the node is to link a Value node to the new Linear Gizmo node. This attaches the gizmo to the input value and allows you to change it from the 3D view. The attachment is indicated by the gizmo icon in the sockets which are controlled by a gizmo as well as the back-link (notice the double link) when the gizmo is active. The core principle makes it straight forward to control the same node setup from the 3D view with gizmos, or by manually changing input values, or by driving the input values procedurally. If the input value is controlled indirectly by other inputs, it's often possible to **automatically propagate** the gizmo to the actual input. Backpropagation does not work for all nodes, although more nodes can be supported over time. This patch adds the first three gizmo nodes which cover common use cases: * **Linear Gizmo**: Creates a gizmo that controls a float or integer value using a linear movement of e.g. an arrow in the 3D viewport. * **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be rotated to change the attached angle input. * **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale. In the future, more built-in gizmos and potentially the ability for custom gizmos could be added. All gizmo nodes have a **Transform** geometry output. Using it is optional but it is recommended when the gizmo is used to control inputs that affect a geometry. When it is used, Blender will automatically transform the gizmos together with the geometry that they control. To achieve this, the output should be merged with the generated geometry using the *Join Geometry* node. The data contained in *Transform* output is not visible geometry, but just internal information that helps Blender to give a better user experience when using gizmos. The gizmo nodes have a multi-input socket. This allows **controlling multiple values** with the same gizmo. Only a small set of **gizmo shapes** is supported initially. It might be extended in the future but one goal is to give the gizmos used by different node group assets a familiar look and feel. A similar constraint exists for **colors**. Currently, one can choose from a fixed set of colors which can be modified in the theme settings. The set of **visible gizmos** is determined by a multiple factors because it's not really feasible to show all possible gizmos at all times. To see any of the geometry nodes gizmos, the "Active Modifier" option has to be enabled in the "Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of the following is true: * The gizmo controls an input of the active modifier of the active object. * The gizmo controls a value in a selected node in an open node editor. * The gizmo controls a pinned value in an open node editor. Pinning works by clicking the gizmo icon next to the value. Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
nodes::gizmos::foreach_active_gizmo_in_modifier(
*object_orig,
nmd_orig,
wm,
Refactor: Geometry Nodes: replace ComputeContextBuilder with ComputeContextCache While `ComputeContextBuilder` worked well for building simple linear compute contexts, it was fairly limiting for all the slightly more complex cases where an entire tree of compute contexts is built. Using `ComputeContextCache` that is easier to do more explicitly. There were only very few cases where using `ComputeContextBuilder` would have still helped a bit, but it's not really worth keeping that abstraction around just for those few cases. Pull Request: https://projects.blender.org/blender/blender/pulls/137370
2025-04-14 17:47:56 +02:00
compute_context_cache,
Geometry Nodes: support attaching gizmos to input values This adds support for attaching gizmos for input values. The goal is to make it easier for users to set input values intuitively in the 3D viewport. We went through multiple different possible designs until we settled on the one implemented here. We picked it for it's flexibility and ease of use when using geometry node assets. The core principle in the design is that **gizmos are attached to existing input values instead of being the input value themselves**. This actually fits the existing concept of gizmos in Blender well, but may be a bit unintutitive in a node setup at first. The attachment is done using links in the node editor. The most basic usage of the node is to link a Value node to the new Linear Gizmo node. This attaches the gizmo to the input value and allows you to change it from the 3D view. The attachment is indicated by the gizmo icon in the sockets which are controlled by a gizmo as well as the back-link (notice the double link) when the gizmo is active. The core principle makes it straight forward to control the same node setup from the 3D view with gizmos, or by manually changing input values, or by driving the input values procedurally. If the input value is controlled indirectly by other inputs, it's often possible to **automatically propagate** the gizmo to the actual input. Backpropagation does not work for all nodes, although more nodes can be supported over time. This patch adds the first three gizmo nodes which cover common use cases: * **Linear Gizmo**: Creates a gizmo that controls a float or integer value using a linear movement of e.g. an arrow in the 3D viewport. * **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be rotated to change the attached angle input. * **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale. In the future, more built-in gizmos and potentially the ability for custom gizmos could be added. All gizmo nodes have a **Transform** geometry output. Using it is optional but it is recommended when the gizmo is used to control inputs that affect a geometry. When it is used, Blender will automatically transform the gizmos together with the geometry that they control. To achieve this, the output should be merged with the generated geometry using the *Join Geometry* node. The data contained in *Transform* output is not visible geometry, but just internal information that helps Blender to give a better user experience when using gizmos. The gizmo nodes have a multi-input socket. This allows **controlling multiple values** with the same gizmo. Only a small set of **gizmo shapes** is supported initially. It might be extended in the future but one goal is to give the gizmos used by different node group assets a familiar look and feel. A similar constraint exists for **colors**. Currently, one can choose from a fixed set of colors which can be modified in the theme settings. The set of **visible gizmos** is determined by a multiple factors because it's not really feasible to show all possible gizmos at all times. To see any of the geometry nodes gizmos, the "Active Modifier" option has to be enabled in the "Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of the following is true: * The gizmo controls an input of the active modifier of the active object. * The gizmo controls a value in a selected node in an open node editor. * The gizmo controls a pinned value in an open node editor. Pinning works by clicking the gizmo icon next to the value. Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
[&](const ComputeContext &compute_context,
const bNode &gizmo_node,
const bNodeSocket &gizmo_socket) {
Geometry Nodes: support viewers in closures This adds support for having viewer nodes in closures. The code attempt to detect where the closure is evaluated and shows the data from there. If the closure is evaluated in multiple Evaluate Closure nodes, currently it just picks the first one it finds. Support for more user control in this case may be added a bit later. If the Evaluate Closure node is in e.g. the repeat or foreach zone, it will automatically use the inspection index of that zone to determine what evaluation to look at specifically. Overall, not too much had to change conceptually to support viewers in closures. Just some code like converting between viewer paths and compute contexts had to be generalized a little bit. Pull Request: https://projects.blender.org/blender/blender/pulls/137625
2025-04-16 23:35:59 +02:00
try_add_side_effect_node(
ctx, compute_context, gizmo_node.identifier, nmd, r_side_effect_nodes);
Geometry Nodes: support attaching gizmos to input values This adds support for attaching gizmos for input values. The goal is to make it easier for users to set input values intuitively in the 3D viewport. We went through multiple different possible designs until we settled on the one implemented here. We picked it for it's flexibility and ease of use when using geometry node assets. The core principle in the design is that **gizmos are attached to existing input values instead of being the input value themselves**. This actually fits the existing concept of gizmos in Blender well, but may be a bit unintutitive in a node setup at first. The attachment is done using links in the node editor. The most basic usage of the node is to link a Value node to the new Linear Gizmo node. This attaches the gizmo to the input value and allows you to change it from the 3D view. The attachment is indicated by the gizmo icon in the sockets which are controlled by a gizmo as well as the back-link (notice the double link) when the gizmo is active. The core principle makes it straight forward to control the same node setup from the 3D view with gizmos, or by manually changing input values, or by driving the input values procedurally. If the input value is controlled indirectly by other inputs, it's often possible to **automatically propagate** the gizmo to the actual input. Backpropagation does not work for all nodes, although more nodes can be supported over time. This patch adds the first three gizmo nodes which cover common use cases: * **Linear Gizmo**: Creates a gizmo that controls a float or integer value using a linear movement of e.g. an arrow in the 3D viewport. * **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be rotated to change the attached angle input. * **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale. In the future, more built-in gizmos and potentially the ability for custom gizmos could be added. All gizmo nodes have a **Transform** geometry output. Using it is optional but it is recommended when the gizmo is used to control inputs that affect a geometry. When it is used, Blender will automatically transform the gizmos together with the geometry that they control. To achieve this, the output should be merged with the generated geometry using the *Join Geometry* node. The data contained in *Transform* output is not visible geometry, but just internal information that helps Blender to give a better user experience when using gizmos. The gizmo nodes have a multi-input socket. This allows **controlling multiple values** with the same gizmo. Only a small set of **gizmo shapes** is supported initially. It might be extended in the future but one goal is to give the gizmos used by different node group assets a familiar look and feel. A similar constraint exists for **colors**. Currently, one can choose from a fixed set of colors which can be modified in the theme settings. The set of **visible gizmos** is determined by a multiple factors because it's not really feasible to show all possible gizmos at all times. To see any of the geometry nodes gizmos, the "Active Modifier" option has to be enabled in the "Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of the following is true: * The gizmo controls an input of the active modifier of the active object. * The gizmo controls a value in a selected node in an open node editor. * The gizmo controls a pinned value in an open node editor. Pinning works by clicking the gizmo icon next to the value. Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
r_socket_log_contexts.add(compute_context.hash());
nodes::gizmos::foreach_compute_context_on_gizmo_path(
compute_context, gizmo_node, gizmo_socket, [&](const ComputeContext &node_context) {
/* Make sure that all intermediate sockets are logged. This is necessary to be able
* to evaluate the nodes in reverse for the gizmo. */
r_socket_log_contexts.add(node_context.hash());
});
});
}
Geometry Nodes: use separate struct for side effect nodes This makes it easier to add another map containing side effect nodes in #112421. No functional changes expected.
2023-09-16 18:57:04 +02:00
static void find_side_effect_nodes(const NodesModifierData &nmd,
const ModifierEvalContext &ctx,
Geometry Nodes: support attaching gizmos to input values This adds support for attaching gizmos for input values. The goal is to make it easier for users to set input values intuitively in the 3D viewport. We went through multiple different possible designs until we settled on the one implemented here. We picked it for it's flexibility and ease of use when using geometry node assets. The core principle in the design is that **gizmos are attached to existing input values instead of being the input value themselves**. This actually fits the existing concept of gizmos in Blender well, but may be a bit unintutitive in a node setup at first. The attachment is done using links in the node editor. The most basic usage of the node is to link a Value node to the new Linear Gizmo node. This attaches the gizmo to the input value and allows you to change it from the 3D view. The attachment is indicated by the gizmo icon in the sockets which are controlled by a gizmo as well as the back-link (notice the double link) when the gizmo is active. The core principle makes it straight forward to control the same node setup from the 3D view with gizmos, or by manually changing input values, or by driving the input values procedurally. If the input value is controlled indirectly by other inputs, it's often possible to **automatically propagate** the gizmo to the actual input. Backpropagation does not work for all nodes, although more nodes can be supported over time. This patch adds the first three gizmo nodes which cover common use cases: * **Linear Gizmo**: Creates a gizmo that controls a float or integer value using a linear movement of e.g. an arrow in the 3D viewport. * **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be rotated to change the attached angle input. * **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale. In the future, more built-in gizmos and potentially the ability for custom gizmos could be added. All gizmo nodes have a **Transform** geometry output. Using it is optional but it is recommended when the gizmo is used to control inputs that affect a geometry. When it is used, Blender will automatically transform the gizmos together with the geometry that they control. To achieve this, the output should be merged with the generated geometry using the *Join Geometry* node. The data contained in *Transform* output is not visible geometry, but just internal information that helps Blender to give a better user experience when using gizmos. The gizmo nodes have a multi-input socket. This allows **controlling multiple values** with the same gizmo. Only a small set of **gizmo shapes** is supported initially. It might be extended in the future but one goal is to give the gizmos used by different node group assets a familiar look and feel. A similar constraint exists for **colors**. Currently, one can choose from a fixed set of colors which can be modified in the theme settings. The set of **visible gizmos** is determined by a multiple factors because it's not really feasible to show all possible gizmos at all times. To see any of the geometry nodes gizmos, the "Active Modifier" option has to be enabled in the "Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of the following is true: * The gizmo controls an input of the active modifier of the active object. * The gizmo controls a value in a selected node in an open node editor. * The gizmo controls a pinned value in an open node editor. Pinning works by clicking the gizmo icon next to the value. Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
nodes::GeoNodesSideEffectNodes &r_side_effect_nodes,
Set<ComputeContextHash> &r_socket_log_contexts)
Spreadsheet: support showing data of specific node Previously, the spreadsheet editor could only show data of the original and of the final evaluated object. Now it is possible to show the data at some intermediate stages too. For that the mode has to be set to "Node" in the spreadsheet editor. Furthermore, the preview of a specific node has to be activated by clicking the new icon in the header of geometry nodes. The exact ui of this feature might be refined in upcoming commits. It is already very useful for debugging node groups in it's current state though. Differential Revision: https://developer.blender.org/D10875
2021-04-08 17:35:06 +02:00
{
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
Main *bmain = DEG_get_bmain(ctx.depsgraph);
Geometry Nodes: viewport preview This adds support for showing geometry passed to the Viewer in the 3d viewport (instead of just in the spreadsheet). The "viewer geometry" bypasses the group output. So it is not necessary to change the final output of the node group to be able to see the intermediate geometry. **Activation and deactivation of a viewer node** * A viewer node is activated by clicking on it. * Ctrl+shift+click on any node/socket connects it to the viewer and makes it active. * Ctrl+shift+click in empty space deactivates the active viewer. * When the active viewer is not visible anymore (e.g. another object is selected, or the current node group is exit), it is deactivated. * Clicking on the icon in the header of the Viewer node toggles whether its active or not. **Pinning** * The spreadsheet still allows pinning the active viewer as before. When pinned, the spreadsheet still references the viewer node even when it becomes inactive. * The viewport does not support pinning at the moment. It always shows the active viewer. **Attribute** * When a field is linked to the second input of the viewer node it is displayed as an overlay in the viewport. * When possible the correct domain for the attribute is determined automatically. This does not work in all cases. It falls back to the face corner domain on meshes and the point domain on curves. When necessary, the domain can be picked manually. * The spreadsheet now only shows the "Viewer" column for the domain that is selected in the Viewer node. * Instance attributes are visualized as a constant color per instance. **Viewport Options** * The attribute overlay opacity can be controlled with the "Viewer Node" setting in the overlays popover. * A viewport can be configured not to show intermediate viewer-geometry by disabling the "Viewer Node" option in the "View" menu. **Implementation Details** * The "spreadsheet context path" was generalized to a "viewer path" that is used in more places now. * The viewer node itself determines the attribute domain, evaluates the field and stores the result in a `.viewer` attribute. * A new "viewer attribute' overlay displays the data from the `.viewer` attribute. * The ground truth for the active viewer node is stored in the workspace now. Node editors, spreadsheets and viewports retrieve the active viewer from there unless they are pinned. * The depsgraph object iterator has a new "viewer path" setting. When set, the viewed geometry of the corresponding object is part of the iterator instead of the final evaluated geometry. * To support the instance attribute overlay `DupliObject` was extended to contain the information necessary for drawing the overlay. * The ctrl+shift+click operator has been refactored so that it can make existing links to viewers active again. * The auto-domain-detection in the Viewer node works by checking the "preferred domain" for every field input. If there is not exactly one preferred domain, the fallback is used. Known limitations: * Loose edges of meshes don't have the attribute overlay. This could be added separately if necessary. * Some attributes are hard to visualize as a color directly. For example, the values might have to be normalized or some should be drawn as arrays. For now, we encourage users to build node groups that generate appropriate viewer-geometry. We might include some of that functionality in future versions. Support for displaying attribute values as text in the viewport is planned as well. * There seems to be an issue with the attribute overlay for pointclouds on nvidia gpus, to be investigated. Differential Revision: https://developer.blender.org/D15954
2022-09-28 17:54:59 +02:00
wmWindowManager *wm = (wmWindowManager *)bmain->wm.first;
if (wm == nullptr) {
return;
}
LISTBASE_FOREACH (const wmWindow *, window, &wm->windows) {
const bScreen *screen = BKE_workspace_active_screen_get(window->workspace_hook);
const WorkSpace *workspace = BKE_workspace_active_get(window->workspace_hook);
find_side_effect_nodes_for_viewer_path(workspace->viewer_path, nmd, ctx, r_side_effect_nodes);
LISTBASE_FOREACH (const ScrArea *, area, &screen->areabase) {
const SpaceLink *sl = static_cast<SpaceLink *>(area->spacedata.first);
if (sl->spacetype == SPACE_SPREADSHEET) {
const SpaceSpreadsheet &sspreadsheet = *reinterpret_cast<const SpaceSpreadsheet *>(sl);
find_side_effect_nodes_for_viewer_path(
sspreadsheet.viewer_path, nmd, ctx, r_side_effect_nodes);
}
if (sl->spacetype == SPACE_VIEW3D) {
const View3D &v3d = *reinterpret_cast<const View3D *>(sl);
find_side_effect_nodes_for_viewer_path(v3d.viewer_path, nmd, ctx, r_side_effect_nodes);
}
}
Spreadsheet: support showing data of specific node Previously, the spreadsheet editor could only show data of the original and of the final evaluated object. Now it is possible to show the data at some intermediate stages too. For that the mode has to be set to "Node" in the spreadsheet editor. Furthermore, the preview of a specific node has to be activated by clicking the new icon in the header of geometry nodes. The exact ui of this feature might be refined in upcoming commits. It is already very useful for debugging node groups in it's current state though. Differential Revision: https://developer.blender.org/D10875
2021-04-08 17:35:06 +02:00
}
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
find_side_effect_nodes_for_baking(nmd, ctx, r_side_effect_nodes);
Geometry Nodes: support attaching gizmos to input values This adds support for attaching gizmos for input values. The goal is to make it easier for users to set input values intuitively in the 3D viewport. We went through multiple different possible designs until we settled on the one implemented here. We picked it for it's flexibility and ease of use when using geometry node assets. The core principle in the design is that **gizmos are attached to existing input values instead of being the input value themselves**. This actually fits the existing concept of gizmos in Blender well, but may be a bit unintutitive in a node setup at first. The attachment is done using links in the node editor. The most basic usage of the node is to link a Value node to the new Linear Gizmo node. This attaches the gizmo to the input value and allows you to change it from the 3D view. The attachment is indicated by the gizmo icon in the sockets which are controlled by a gizmo as well as the back-link (notice the double link) when the gizmo is active. The core principle makes it straight forward to control the same node setup from the 3D view with gizmos, or by manually changing input values, or by driving the input values procedurally. If the input value is controlled indirectly by other inputs, it's often possible to **automatically propagate** the gizmo to the actual input. Backpropagation does not work for all nodes, although more nodes can be supported over time. This patch adds the first three gizmo nodes which cover common use cases: * **Linear Gizmo**: Creates a gizmo that controls a float or integer value using a linear movement of e.g. an arrow in the 3D viewport. * **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be rotated to change the attached angle input. * **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale. In the future, more built-in gizmos and potentially the ability for custom gizmos could be added. All gizmo nodes have a **Transform** geometry output. Using it is optional but it is recommended when the gizmo is used to control inputs that affect a geometry. When it is used, Blender will automatically transform the gizmos together with the geometry that they control. To achieve this, the output should be merged with the generated geometry using the *Join Geometry* node. The data contained in *Transform* output is not visible geometry, but just internal information that helps Blender to give a better user experience when using gizmos. The gizmo nodes have a multi-input socket. This allows **controlling multiple values** with the same gizmo. Only a small set of **gizmo shapes** is supported initially. It might be extended in the future but one goal is to give the gizmos used by different node group assets a familiar look and feel. A similar constraint exists for **colors**. Currently, one can choose from a fixed set of colors which can be modified in the theme settings. The set of **visible gizmos** is determined by a multiple factors because it's not really feasible to show all possible gizmos at all times. To see any of the geometry nodes gizmos, the "Active Modifier" option has to be enabled in the "Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of the following is true: * The gizmo controls an input of the active modifier of the active object. * The gizmo controls a value in a selected node in an open node editor. * The gizmo controls a pinned value in an open node editor. Pinning works by clicking the gizmo icon next to the value. Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
find_side_effect_nodes_for_active_gizmos(
nmd, ctx, *wm, r_side_effect_nodes, r_socket_log_contexts);
Spreadsheet: support showing data of specific node Previously, the spreadsheet editor could only show data of the original and of the final evaluated object. Now it is possible to show the data at some intermediate stages too. For that the mode has to be set to "Node" in the spreadsheet editor. Furthermore, the preview of a specific node has to be activated by clicking the new icon in the header of geometry nodes. The exact ui of this feature might be refined in upcoming commits. It is already very useful for debugging node groups in it's current state though. Differential Revision: https://developer.blender.org/D10875
2021-04-08 17:35:06 +02:00
}
Geometry Nodes: skip logging socket values for invisible trees Geometry nodes used to log all socket values during evaluation. This allowed the user to hover over any socket (that was evaluated) to see its last value. The problem is that in large (nested) node trees, the number of sockets becomes huge, causing a lot of performance and memory overhead (in extreme cases, more than 70% of the total execution time). This patch changes it so, that only socket values are logged that the user is likely to investigate. The simple heuristic is that socket values of the currently visible node tree are logged. The downside is that when the user changes the visible node tree, it won't have any logged values until it is reevaluated. I updated the tooltip message for that case to be a bit more precise. If user feedback suggests that this new behavior is too annoying, we can always add a UI option to log all socket values again. That shouldn't be done without an actual need though because it takes up UI space. Differential Revision: https://developer.blender.org/D16884
2022-12-29 19:36:15 +01:00
static void find_socket_log_contexts(const NodesModifierData &nmd,
const ModifierEvalContext &ctx,
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
Set<ComputeContextHash> &r_socket_log_contexts)
Geometry Nodes: skip logging socket values for invisible trees Geometry nodes used to log all socket values during evaluation. This allowed the user to hover over any socket (that was evaluated) to see its last value. The problem is that in large (nested) node trees, the number of sockets becomes huge, causing a lot of performance and memory overhead (in extreme cases, more than 70% of the total execution time). This patch changes it so, that only socket values are logged that the user is likely to investigate. The simple heuristic is that socket values of the currently visible node tree are logged. The downside is that when the user changes the visible node tree, it won't have any logged values until it is reevaluated. I updated the tooltip message for that case to be a bit more precise. If user feedback suggests that this new behavior is too annoying, we can always add a UI option to log all socket values again. That shouldn't be done without an actual need though because it takes up UI space. Differential Revision: https://developer.blender.org/D16884
2022-12-29 19:36:15 +01:00
{
Main *bmain = DEG_get_bmain(ctx.depsgraph);
wmWindowManager *wm = (wmWindowManager *)bmain->wm.first;
if (wm == nullptr) {
return;
}
Refactor: Geometry Nodes: simplify getting compute context for edittree This adds a simple `compute_context_for_edittree` function that returns the "active" compute context for the given node editor. This is used in various places, but previously one had to construct the compute context in multiple steps (first find the root context (modifier/operator), then handle the tree path). Since the edittree already has a specific active context, there should be an easy way to retrieve that. This also adds a few extra check that avoid redundant work that was done before. Pull Request: https://projects.blender.org/blender/blender/pulls/137525
2025-04-15 15:24:29 +02:00
bke::ComputeContextCache compute_context_cache;
Geometry Nodes: skip logging socket values for invisible trees Geometry nodes used to log all socket values during evaluation. This allowed the user to hover over any socket (that was evaluated) to see its last value. The problem is that in large (nested) node trees, the number of sockets becomes huge, causing a lot of performance and memory overhead (in extreme cases, more than 70% of the total execution time). This patch changes it so, that only socket values are logged that the user is likely to investigate. The simple heuristic is that socket values of the currently visible node tree are logged. The downside is that when the user changes the visible node tree, it won't have any logged values until it is reevaluated. I updated the tooltip message for that case to be a bit more precise. If user feedback suggests that this new behavior is too annoying, we can always add a UI option to log all socket values again. That shouldn't be done without an actual need though because it takes up UI space. Differential Revision: https://developer.blender.org/D16884
2022-12-29 19:36:15 +01:00
LISTBASE_FOREACH (const wmWindow *, window, &wm->windows) {
const bScreen *screen = BKE_workspace_active_screen_get(window->workspace_hook);
LISTBASE_FOREACH (const ScrArea *, area, &screen->areabase) {
const SpaceLink *sl = static_cast<SpaceLink *>(area->spacedata.first);
if (sl->spacetype == SPACE_NODE) {
const SpaceNode &snode = *reinterpret_cast<const SpaceNode *>(sl);
Fix: Nodes: Only look for compute contexts in geo-node trees `find_socket_log_contexts` tries to look for `ComputeContext`s regardless of the tree type. This doesn't currently cause any problem in main because no other node editor has zones, but it causes crashes in the NPR branch, and will crash in main when other tree types add zones support. (See https://projects.blender.org/pragma37/npr-tracker/issues/13) Pull Request: https://projects.blender.org/blender/blender/pulls/133447
2025-01-23 15:34:12 +01:00
if (snode.edittree == nullptr || snode.edittree->type != NTREE_GEOMETRY) {
Fix crash in geo_node_* tests, missing null check Missing null check in [0] caused tests (geo_node_simulation_test_simple_particles & others) to crash. [0]: 7015d833686fbf697d45faa3fbdaea4f85c30163
2023-09-25 10:25:48 +10:00
continue;
}
Refactor: Geometry Nodes: simplify getting compute context for edittree This adds a simple `compute_context_for_edittree` function that returns the "active" compute context for the given node editor. This is used in various places, but previously one had to construct the compute context in multiple steps (first find the root context (modifier/operator), then handle the tree path). Since the edittree already has a specific active context, there should be an easy way to retrieve that. This also adds a few extra check that avoid redundant work that was done before. Pull Request: https://projects.blender.org/blender/blender/pulls/137525
2025-04-15 15:24:29 +02:00
if (!ed::space_node::node_editor_is_for_geometry_nodes_modifier(snode, *ctx.object, nmd)) {
continue;
}
Cleanup: improve node tree zones naming
2023-06-20 10:25:41 +02:00
const Map<const bke::bNodeTreeZone *, ComputeContextHash> hash_by_zone =
Refactor: Geometry Nodes: simplify getting compute context for edittree This adds a simple `compute_context_for_edittree` function that returns the "active" compute context for the given node editor. This is used in various places, but previously one had to construct the compute context in multiple steps (first find the root context (modifier/operator), then handle the tree path). Since the edittree already has a specific active context, there should be an easy way to retrieve that. This also adds a few extra check that avoid redundant work that was done before. Pull Request: https://projects.blender.org/blender/blender/pulls/137525
2025-04-15 15:24:29 +02:00
geo_log::GeoModifierLog::get_context_hash_by_zone_for_node_editor(
snode, compute_context_cache);
Geometry Nodes: make evaluation and logging system aware of zones This refactors how a geometry nodes node tree is converted to a lazy-function graph. Previously, all nodes were inserted into a single graph. This was fine because every node was evaluated at most once per node group evaluation. However, loops (#108896) break this assumption since now nodes may be evaluated multiple times and thus a single flat graph does not work anymore. Now, a separate lazy-function is build for every zone which gives us much more flexibility for what can happen in a zone. Right now, the change only applies to simulation zones since that's the only kind of zone we have. Technically, those zones could be inlined, but turning them into a separate lazy-function also does not hurt and makes it possible to test this refactor without implementing loops first. Also, having them as separate functions might help in the future if we integrate a substep loop directly into the simulation zone. The most tricky part here is to just link everything up correctly, especially with respect to deterministic anonymous attribute lifetimes. Fortunately, correctness can be checked visually by looking at the generated graphs. The logging/viewer system also had to be refactored a bit, because now there can be multiple different `ComputeContext` in a single node tree. Each zone is in a separate `ComputeContext`. To make it work, the `ViewerPath` system now explicitly supports zones and drawing code will look up the right logger for showing inspection data. No functional changes are expected, except that the spreadsheet now shows "Simulation Zone" in the context path if the viewer is in a simulation.
2023-06-20 09:50:44 +02:00
for (const ComputeContextHash &hash : hash_by_zone.values()) {
r_socket_log_contexts.add(hash);
Geometry Nodes: skip logging socket values for invisible trees Geometry nodes used to log all socket values during evaluation. This allowed the user to hover over any socket (that was evaluated) to see its last value. The problem is that in large (nested) node trees, the number of sockets becomes huge, causing a lot of performance and memory overhead (in extreme cases, more than 70% of the total execution time). This patch changes it so, that only socket values are logged that the user is likely to investigate. The simple heuristic is that socket values of the currently visible node tree are logged. The downside is that when the user changes the visible node tree, it won't have any logged values until it is reevaluated. I updated the tooltip message for that case to be a bit more precise. If user feedback suggests that this new behavior is too annoying, we can always add a UI option to log all socket values again. That shouldn't be done without an actual need though because it takes up UI space. Differential Revision: https://developer.blender.org/D16884
2022-12-29 19:36:15 +01:00
}
}
}
}
}
Fix T95084: evaluate all output attributes before changing geometry This refactors how output attributes are computed in the geometry nodes modifier. Previously, all output attributes were computed one after the other. Every attribute was stored on the geometry directly after computing it. The issue was that other output attributes might depend on the already overwritten attributes, leading to unexpected behavior. The solution is to compute all output attributes first before changing the geometry. Under specific circumstances, this refactor can result in a speedup, because output attributes on the same domain are evaluated together now. Overwriting existing might have become a bit slower, because we write the attribute into new buffer instead of using the existing one. Differential Revision: https://developer.blender.org/D13983
2022-02-02 10:54:54 +01:00
/**
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
* \note This could be done in #initialize_group_input, though that would require adding the
* the object as a parameter, so it's likely better to this check as a separate step.
Fix T95084: evaluate all output attributes before changing geometry This refactors how output attributes are computed in the geometry nodes modifier. Previously, all output attributes were computed one after the other. Every attribute was stored on the geometry directly after computing it. The issue was that other output attributes might depend on the already overwritten attributes, leading to unexpected behavior. The solution is to compute all output attributes first before changing the geometry. Under specific circumstances, this refactor can result in a speedup, because output attributes on the same domain are evaluated together now. Overwriting existing might have become a bit slower, because we write the attribute into new buffer instead of using the existing one. Differential Revision: https://developer.blender.org/D13983
2022-02-02 10:54:54 +01:00
*/
Geometry Nodes: Improve performance with many inputs Resolves #136183 To avoid quadratic worst case runtime when gathering values from the modifier properties, build a temporary VectorSet of the modifier's IDProperties. In the file from #136183, this change improves playback performance by 1.4x for me, from 50 to 70ms. Ideally IDProperty groups would have constant time lookup on their own, but that's a much larger change, and this smaller change for just Geometry Nodes is not so invasive. Pull Request: https://projects.blender.org/blender/blender/pulls/136463
2025-03-25 15:40:32 +01:00
static void check_property_socket_sync(const Object *ob,
const nodes::PropertiesVectorSet &properties,
ModifierData *md)
Geometry Nodes: support creating new attributes in modifier This patch allows passing a field to the modifier as output. In the modifier, the user can choose an attribute name. The attribute will be filled with values computed by the field. This only works for realized mesh/curve/point data. As mentioned in T91376, the output domain is selected in the node group itself. We might want to add this functionality to the modifier later as well, but not now. Differential Revision: https://developer.blender.org/D12644
2021-09-27 15:33:48 +02:00
{
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
NodesModifierData *nmd = reinterpret_cast<NodesModifierData *>(md);
Fix T95084: evaluate all output attributes before changing geometry This refactors how output attributes are computed in the geometry nodes modifier. Previously, all output attributes were computed one after the other. Every attribute was stored on the geometry directly after computing it. The issue was that other output attributes might depend on the already overwritten attributes, leading to unexpected behavior. The solution is to compute all output attributes first before changing the geometry. Under specific circumstances, this refactor can result in a speedup, because output attributes on the same domain are evaluated together now. Overwriting existing might have become a bit slower, because we write the attribute into new buffer instead of using the existing one. Differential Revision: https://developer.blender.org/D13983
2022-02-02 10:54:54 +01:00
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
int geometry_socket_count = 0;
Geometry Nodes: support creating new attributes in modifier This patch allows passing a field to the modifier as output. In the modifier, the user can choose an attribute name. The attribute will be filled with values computed by the field. This only works for realized mesh/curve/point data. As mentioned in T91376, the output domain is selected in the node group itself. We might want to add this functionality to the modifier later as well, but not now. Differential Revision: https://developer.blender.org/D12644
2021-09-27 15:33:48 +02:00
Fix #112331: Add update tags directly in bNodeTreeInterface API methods Calling an API function after the node panels patch does not internally tag the node tree with `NTREE_CHANGED_INTERFACE` any more, because the node tree is not directly accessible from `bNodeTreeInterface`. Before node panels the API functions for interfaces could tag the tree directly for later update consideration, which now requires explicit tagging calls. The fix is to add a flag and mutex directly to `bNodeTreeInterface`, so API methods can tag after updates. This mostly copies runtime data concepts from `bNodeTree`. The `ensure_interface_cache` method is equivalent to `ensure_topology_cache` and should be called before accessing `interface_inputs` and similar cache data. Pull Request: https://projects.blender.org/blender/blender/pulls/111741
2023-09-14 14:13:07 +02:00
nmd->node_group->ensure_interface_cache();
Nodes: Panels integration with blend files and UI Part 3/3 of #109135, #110272 Switch to new node group interfaces and deprecate old DNA and API. This completes support for panels in node drawing and in node group interface declarations in particular. The new node group interface DNA and RNA code has been added in parts 1 and 2 (#110885, #110952) but has not be enabled yet. This commit completes the integration by * enabling the new RNA API * using the new API in UI * read/write new interfaces from blend files * add versioning for backward compatibility * add forward-compatible writing code to reconstruct old interfaces All places accessing node group interface declarations should now be using the new API. A runtime cache has been added that allows simple linear access to socket inputs and outputs even when a panel hierarchy is used. Old DNA has been deprecated and should only be accessed for versioning (inputs/outputs renamed to inputs_legacy/outputs_legacy to catch errors). Versioning code ensures both backward and forward compatibility of existing files. The API for old interfaces is removed. The new API is very similar but is defined on the `ntree.interface` instead of the `ntree` directly. Breaking change notifications and detailed instructions for migrating will be added. A python test has been added for the node group API functions. This includes new functionality such as creating panels and moving items between different levels. This patch does not yet contain panel representations in the modifier UI. This has been tested in a separate branch and will be added with a later PR (#108565). Pull Request: https://projects.blender.org/blender/blender/pulls/111348
2023-08-30 12:37:21 +02:00
for (const int i : nmd->node_group->interface_inputs().index_range()) {
const bNodeTreeInterfaceSocket *socket = nmd->node_group->interface_inputs()[i];
Cleanup: Move BKE_node to namespace Move all header file into namespace. Unnecessary namespaces was removed from implementations file. Part of forward declarations in header was moved in the top part of file just to do not have a lot of separate namespaces. Pull Request: https://projects.blender.org/blender/blender/pulls/121637
2024-05-13 16:07:12 +02:00
const bke::bNodeSocketType *typeinfo = socket->socket_typeinfo();
Nodes: Panels integration with blend files and UI Part 3/3 of #109135, #110272 Switch to new node group interfaces and deprecate old DNA and API. This completes support for panels in node drawing and in node group interface declarations in particular. The new node group interface DNA and RNA code has been added in parts 1 and 2 (#110885, #110952) but has not be enabled yet. This commit completes the integration by * enabling the new RNA API * using the new API in UI * read/write new interfaces from blend files * add versioning for backward compatibility * add forward-compatible writing code to reconstruct old interfaces All places accessing node group interface declarations should now be using the new API. A runtime cache has been added that allows simple linear access to socket inputs and outputs even when a panel hierarchy is used. Old DNA has been deprecated and should only be accessed for versioning (inputs/outputs renamed to inputs_legacy/outputs_legacy to catch errors). Versioning code ensures both backward and forward compatibility of existing files. The API for old interfaces is removed. The new API is very similar but is defined on the `ntree.interface` instead of the `ntree` directly. Breaking change notifications and detailed instructions for migrating will be added. A python test has been added for the node group API functions. This includes new functionality such as creating panels and moving items between different levels. This patch does not yet contain panel representations in the modifier UI. This has been tested in a separate branch and will be added with a later PR (#108565). Pull Request: https://projects.blender.org/blender/blender/pulls/111348
2023-08-30 12:37:21 +02:00
const eNodeSocketDatatype type = typeinfo ? eNodeSocketDatatype(typeinfo->type) : SOCK_CUSTOM;
Geometry Nodes: add Closures and Bundles behind experimental feature flag This implements bundles and closures which are described in more detail in this blog post: https://code.blender.org/2024/11/geometry-nodes-workshop-october-2024/ tl;dr: * Bundles are containers that allow storing multiple socket values in a single value. Each value in the bundle is identified by a name. Bundles can be nested. * Closures are functions that are created with the Closure Zone and can be evaluated with the Evaluate Closure node. To use the patch, the `Bundle and Closure Nodes` experimental feature has to be enabled. This is necessary, because these features are not fully done yet and still need iterations to improve the workflow before they can be officially released. These iterations are easier to do in `main` than in a separate branch though. That's because this patch is quite large and somewhat prone to merge conflicts. Also other work we want to do, depends on this. This adds the following new nodes: * Combine Bundle: can pack multiple values into one. * Separate Bundle: extracts values from a bundle. * Closure Zone: outputs a closure zone for use in the `Evaluate Closure` node. * Evaluate Closure: evaluates the passed in closure. Things that will be added soon after this lands: * Fields in bundles and closures. The way this is done changes with #134811, so I rather implement this once both are in `main`. * UI features for keeping sockets in sync (right now there are warnings only). One bigger issue is the limited support for lazyness. For example, all inputs of a Combine Bundle node will be evaluated, even if they are not all needed. The same is true for all captured values of a closure. This is a deeper limitation that needs to be resolved at some point. This will likely be done after an initial version of this patch is done. Pull Request: https://projects.blender.org/blender/blender/pulls/128340
2025-04-03 15:44:06 +02:00
if (type == SOCK_GEOMETRY) {
geometry_socket_count++;
}
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
/* The first socket is the special geometry socket for the modifier object. */
Nodes: Panels integration with blend files and UI Part 3/3 of #109135, #110272 Switch to new node group interfaces and deprecate old DNA and API. This completes support for panels in node drawing and in node group interface declarations in particular. The new node group interface DNA and RNA code has been added in parts 1 and 2 (#110885, #110952) but has not be enabled yet. This commit completes the integration by * enabling the new RNA API * using the new API in UI * read/write new interfaces from blend files * add versioning for backward compatibility * add forward-compatible writing code to reconstruct old interfaces All places accessing node group interface declarations should now be using the new API. A runtime cache has been added that allows simple linear access to socket inputs and outputs even when a panel hierarchy is used. Old DNA has been deprecated and should only be accessed for versioning (inputs/outputs renamed to inputs_legacy/outputs_legacy to catch errors). Versioning code ensures both backward and forward compatibility of existing files. The API for old interfaces is removed. The new API is very similar but is defined on the `ntree.interface` instead of the `ntree` directly. Breaking change notifications and detailed instructions for migrating will be added. A python test has been added for the node group API functions. This includes new functionality such as creating panels and moving items between different levels. This patch does not yet contain panel representations in the modifier UI. This has been tested in a separate branch and will be added with a later PR (#108565). Pull Request: https://projects.blender.org/blender/blender/pulls/111348
2023-08-30 12:37:21 +02:00
if (i == 0 && type == SOCK_GEOMETRY) {
Fix T95084: evaluate all output attributes before changing geometry This refactors how output attributes are computed in the geometry nodes modifier. Previously, all output attributes were computed one after the other. Every attribute was stored on the geometry directly after computing it. The issue was that other output attributes might depend on the already overwritten attributes, leading to unexpected behavior. The solution is to compute all output attributes first before changing the geometry. Under specific circumstances, this refactor can result in a speedup, because output attributes on the same domain are evaluated together now. Overwriting existing might have become a bit slower, because we write the attribute into new buffer instead of using the existing one. Differential Revision: https://developer.blender.org/D13983
2022-02-02 10:54:54 +01:00
continue;
}
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
Geometry Nodes: Improve performance with many inputs Resolves #136183 To avoid quadratic worst case runtime when gathering values from the modifier properties, build a temporary VectorSet of the modifier's IDProperties. In the file from #136183, this change improves playback performance by 1.4x for me, from 50 to 70ms. Ideally IDProperty groups would have constant time lookup on their own, but that's a much larger change, and this smaller change for just Geometry Nodes is not so invasive. Pull Request: https://projects.blender.org/blender/blender/pulls/136463
2025-03-25 15:40:32 +01:00
IDProperty *property = properties.lookup_key_default_as(socket->identifier, nullptr);
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
if (property == nullptr) {
Geometry Nodes: add Closures and Bundles behind experimental feature flag This implements bundles and closures which are described in more detail in this blog post: https://code.blender.org/2024/11/geometry-nodes-workshop-october-2024/ tl;dr: * Bundles are containers that allow storing multiple socket values in a single value. Each value in the bundle is identified by a name. Bundles can be nested. * Closures are functions that are created with the Closure Zone and can be evaluated with the Evaluate Closure node. To use the patch, the `Bundle and Closure Nodes` experimental feature has to be enabled. This is necessary, because these features are not fully done yet and still need iterations to improve the workflow before they can be officially released. These iterations are easier to do in `main` than in a separate branch though. That's because this patch is quite large and somewhat prone to merge conflicts. Also other work we want to do, depends on this. This adds the following new nodes: * Combine Bundle: can pack multiple values into one. * Separate Bundle: extracts values from a bundle. * Closure Zone: outputs a closure zone for use in the `Evaluate Closure` node. * Evaluate Closure: evaluates the passed in closure. Things that will be added soon after this lands: * Fields in bundles and closures. The way this is done changes with #134811, so I rather implement this once both are in `main`. * UI features for keeping sockets in sync (right now there are warnings only). One bigger issue is the limited support for lazyness. For example, all inputs of a Combine Bundle node will be evaluated, even if they are not all needed. The same is true for all captured values of a closure. This is a deeper limitation that needs to be resolved at some point. This will likely be done after an initial version of this patch is done. Pull Request: https://projects.blender.org/blender/blender/pulls/128340
2025-04-03 15:44:06 +02:00
if (!ELEM(type, SOCK_GEOMETRY, SOCK_MATRIX, SOCK_BUNDLE, SOCK_CLOSURE)) {
Fix #113860: Nullptr checks for node socket and panel name pointers In 3.6 the names of node group sockets were using char arrays, but now use allocated strings. The RNA system assigns nullptr to such strings when assigning an empty string through python (UI assignment appears to always generate a valid string). This creates issues with many STL functions, in particular assigning nullptr to `std::string` will crash. We have to check for valid pointers before using them in places that don't handle nullptrs. Pull Request: https://projects.blender.org/blender/blender/pulls/113924
2023-10-19 11:48:08 +02:00
BKE_modifier_set_error(
ob, md, "Missing property for input socket \"%s\"", socket->name ? socket->name : "");
Fix T95084: evaluate all output attributes before changing geometry This refactors how output attributes are computed in the geometry nodes modifier. Previously, all output attributes were computed one after the other. Every attribute was stored on the geometry directly after computing it. The issue was that other output attributes might depend on the already overwritten attributes, leading to unexpected behavior. The solution is to compute all output attributes first before changing the geometry. Under specific circumstances, this refactor can result in a speedup, because output attributes on the same domain are evaluated together now. Overwriting existing might have become a bit slower, because we write the attribute into new buffer instead of using the existing one. Differential Revision: https://developer.blender.org/D13983
2022-02-02 10:54:54 +01:00
}
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
continue;
Fix T95084: evaluate all output attributes before changing geometry This refactors how output attributes are computed in the geometry nodes modifier. Previously, all output attributes were computed one after the other. Every attribute was stored on the geometry directly after computing it. The issue was that other output attributes might depend on the already overwritten attributes, leading to unexpected behavior. The solution is to compute all output attributes first before changing the geometry. Under specific circumstances, this refactor can result in a speedup, because output attributes on the same domain are evaluated together now. Overwriting existing might have become a bit slower, because we write the attribute into new buffer instead of using the existing one. Differential Revision: https://developer.blender.org/D13983
2022-02-02 10:54:54 +01:00
}
Fix: Memory leak writing to builtin attribute from modifier If the attribute already existed, but had a different domain or data type than the user tried to write to it with (i.e. writing to `position` with a float), then the data from field evaluation wasn't freed. This restructures the geometry nodes modifier attribute writing process to solve that problem and remove some of the nested if statements that made the process confusing. One case that still doesn't work is writing to a builtin attribute from a different domain. If `OutputAttribute` gets that feature then that could be supported here too. Differential Revision: https://developer.blender.org/D14706
2022-04-21 14:05:16 -05:00
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
if (!nodes::id_property_type_matches_socket(*socket, *property)) {
Fix #113860: Nullptr checks for node socket and panel name pointers In 3.6 the names of node group sockets were using char arrays, but now use allocated strings. The RNA system assigns nullptr to such strings when assigning an empty string through python (UI assignment appears to always generate a valid string). This creates issues with many STL functions, in particular assigning nullptr to `std::string` will crash. We have to check for valid pointers before using them in places that don't handle nullptrs. Pull Request: https://projects.blender.org/blender/blender/pulls/113924
2023-10-19 11:48:08 +02:00
BKE_modifier_set_error(ob,
md,
"Property type does not match input socket \"(%s)\"",
socket->name ? socket->name : "");
Fix: Memory leak writing to builtin attribute from modifier If the attribute already existed, but had a different domain or data type than the user tried to write to it with (i.e. writing to `position` with a float), then the data from field evaluation wasn't freed. This restructures the geometry nodes modifier attribute writing process to solve that problem and remove some of the nested if statements that made the process confusing. One case that still doesn't work is writing to a builtin attribute from a different domain. If `OutputAttribute` gets that feature then that could be supported here too. Differential Revision: https://developer.blender.org/D14706
2022-04-21 14:05:16 -05:00
continue;
}
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
}
Fix: Memory leak writing to builtin attribute from modifier If the attribute already existed, but had a different domain or data type than the user tried to write to it with (i.e. writing to `position` with a float), then the data from field evaluation wasn't freed. This restructures the geometry nodes modifier attribute writing process to solve that problem and remove some of the nested if statements that made the process confusing. One case that still doesn't work is writing to a builtin attribute from a different domain. If `OutputAttribute` gets that feature then that could be supported here too. Differential Revision: https://developer.blender.org/D14706
2022-04-21 14:05:16 -05:00
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
if (geometry_socket_count == 1) {
Nodes: Panels integration with blend files and UI Part 3/3 of #109135, #110272 Switch to new node group interfaces and deprecate old DNA and API. This completes support for panels in node drawing and in node group interface declarations in particular. The new node group interface DNA and RNA code has been added in parts 1 and 2 (#110885, #110952) but has not be enabled yet. This commit completes the integration by * enabling the new RNA API * using the new API in UI * read/write new interfaces from blend files * add versioning for backward compatibility * add forward-compatible writing code to reconstruct old interfaces All places accessing node group interface declarations should now be using the new API. A runtime cache has been added that allows simple linear access to socket inputs and outputs even when a panel hierarchy is used. Old DNA has been deprecated and should only be accessed for versioning (inputs/outputs renamed to inputs_legacy/outputs_legacy to catch errors). Versioning code ensures both backward and forward compatibility of existing files. The API for old interfaces is removed. The new API is very similar but is defined on the `ntree.interface` instead of the `ntree` directly. Breaking change notifications and detailed instructions for migrating will be added. A python test has been added for the node group API functions. This includes new functionality such as creating panels and moving items between different levels. This patch does not yet contain panel representations in the modifier UI. This has been tested in a separate branch and will be added with a later PR (#108565). Pull Request: https://projects.blender.org/blender/blender/pulls/111348
2023-08-30 12:37:21 +02:00
const bNodeTreeInterfaceSocket *first_socket = nmd->node_group->interface_inputs()[0];
Cleanup: Move BKE_node to namespace Move all header file into namespace. Unnecessary namespaces was removed from implementations file. Part of forward declarations in header was moved in the top part of file just to do not have a lot of separate namespaces. Pull Request: https://projects.blender.org/blender/blender/pulls/121637
2024-05-13 16:07:12 +02:00
const bke::bNodeSocketType *typeinfo = first_socket->socket_typeinfo();
Nodes: Panels integration with blend files and UI Part 3/3 of #109135, #110272 Switch to new node group interfaces and deprecate old DNA and API. This completes support for panels in node drawing and in node group interface declarations in particular. The new node group interface DNA and RNA code has been added in parts 1 and 2 (#110885, #110952) but has not be enabled yet. This commit completes the integration by * enabling the new RNA API * using the new API in UI * read/write new interfaces from blend files * add versioning for backward compatibility * add forward-compatible writing code to reconstruct old interfaces All places accessing node group interface declarations should now be using the new API. A runtime cache has been added that allows simple linear access to socket inputs and outputs even when a panel hierarchy is used. Old DNA has been deprecated and should only be accessed for versioning (inputs/outputs renamed to inputs_legacy/outputs_legacy to catch errors). Versioning code ensures both backward and forward compatibility of existing files. The API for old interfaces is removed. The new API is very similar but is defined on the `ntree.interface` instead of the `ntree` directly. Breaking change notifications and detailed instructions for migrating will be added. A python test has been added for the node group API functions. This includes new functionality such as creating panels and moving items between different levels. This patch does not yet contain panel representations in the modifier UI. This has been tested in a separate branch and will be added with a later PR (#108565). Pull Request: https://projects.blender.org/blender/blender/pulls/111348
2023-08-30 12:37:21 +02:00
const eNodeSocketDatatype type = typeinfo ? eNodeSocketDatatype(typeinfo->type) : SOCK_CUSTOM;
if (type != SOCK_GEOMETRY) {
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
BKE_modifier_set_error(ob, md, "Node group's geometry input must be the first");
Fix T95084: evaluate all output attributes before changing geometry This refactors how output attributes are computed in the geometry nodes modifier. Previously, all output attributes were computed one after the other. Every attribute was stored on the geometry directly after computing it. The issue was that other output attributes might depend on the already overwritten attributes, leading to unexpected behavior. The solution is to compute all output attributes first before changing the geometry. Under specific circumstances, this refactor can result in a speedup, because output attributes on the same domain are evaluated together now. Overwriting existing might have become a bit slower, because we write the attribute into new buffer instead of using the existing one. Differential Revision: https://developer.blender.org/D13983
2022-02-02 10:54:54 +01:00
}
Geometry Nodes: Only create instance IDs when they exist Instance IDs serve no purpose for rendering when they aren't stable from one frame to the next, and if the index is used in the end anyway, there is no point in storing a vector of IDs and copying it around. This commit exposes the `id` attribute on the instances component, makes it optional-- only generated by default with the distribute points on faces node. Since the string to curves node only added the index as each instance's ID, I removed it. This means that it would be necessary to add the ID data manually if the initial index actually helps (when deleting only certain characters, for example). Differential Revision: https://developer.blender.org/D12980
2021-10-26 12:50:39 -05:00
}
Geometry Nodes: support creating new attributes in modifier This patch allows passing a field to the modifier as output. In the modifier, the user can choose an attribute name. The attribute will be filled with values computed by the field. This only works for realized mesh/curve/point data. As mentioned in T91376, the output domain is selected in the node group itself. We might want to add this functionality to the modifier later as well, but not now. Differential Revision: https://developer.blender.org/D12644
2021-09-27 15:33:48 +02:00
}
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
class NodesModifierBakeDataBlockMap : public bake::BakeDataBlockMap {
/** Protects access to `new_mappings` which may be added to from multiple threads. */
BLI: use blender::Mutex by default which wraps tbb::mutex This patch adds a new `BLI_mutex.hh` header which adds `blender::Mutex` as alias for either `tbb::mutex` or `std::mutex` depending on whether TBB is enabled. Description copied from the patch: ``` /** * blender::Mutex should be used as the default mutex in Blender. It implements a subset of the API * of std::mutex but has overall better guaranteed properties. It can be used with RAII helpers * like std::lock_guard. However, it is not compatible with e.g. std::condition_variable. So one * still has to use std::mutex for that case. * * The mutex provided by TBB has these properties: * - It's as fast as a spin-lock in the non-contended case, i.e. when no other thread is trying to * lock the mutex at the same time. * - In the contended case, it spins a couple of times but then blocks to avoid draining system * resources by spinning for a long time. * - It's only 1 byte large, compared to e.g. 40 bytes when using the std::mutex of GCC. This makes * it more feasible to have many smaller mutexes which can improve scalability of algorithms * compared to using fewer larger mutexes. Also it just reduces "memory slop" across Blender. * - It is *not* a fair mutex, i.e. it's not guaranteed that a thread will ever be able to lock the * mutex when there are always more than one threads that try to lock it. In the majority of * cases, using a fair mutex just causes extra overhead without any benefit. std::mutex is not * guaranteed to be fair either. */ ``` The performance benchmark suggests that the impact is negilible in almost all cases. The only benchmarks that show interesting behavior are the once testing foreach zones in Geometry Nodes. These tests are explicitly testing overhead, which I still have to reduce over time. So it's not unexpected that changing the mutex has an impact there. What's interesting is that on macos the performance improves a lot while on linux it gets worse. Since that overhead should eventually be removed almost entirely, I don't really consider that blocking. Links: * Documentation of different mutex flavors in TBB: https://www.intel.com/content/www/us/en/docs/onetbb/developer-guide-api-reference/2021-12/mutex-flavors.html * Older implementation of a similar mutex by me: https://archive.blender.org/developer/differential/0016/0016711/index.html * Interesting read regarding how a mutex can be this small: https://webkit.org/blog/6161/locking-in-webkit/ Pull Request: https://projects.blender.org/blender/blender/pulls/138370
2025-05-07 04:53:16 +02:00
Mutex mutex_;
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
public:
Map<bake::BakeDataBlockID, ID *> old_mappings;
Map<bake::BakeDataBlockID, ID *> new_mappings;
ID *lookup_or_remember_missing(const bake::BakeDataBlockID &key) override
{
if (ID *id = this->old_mappings.lookup_default(key, nullptr)) {
return id;
}
if (this->old_mappings.contains(key)) {
/* Don't allow overwriting old mappings. */
return nullptr;
}
std::lock_guard lock{mutex_};
return this->new_mappings.lookup_or_add(key, nullptr);
}
void try_add(ID &id) override
{
bake::BakeDataBlockID key{id};
if (this->old_mappings.contains(key)) {
return;
}
std::lock_guard lock{mutex_};
this->new_mappings.add_overwrite(std::move(key), &id);
}
private:
ID *lookup_in_map(Map<bake::BakeDataBlockID, ID *> &map,
const bake::BakeDataBlockID &key,
const std::optional<ID_Type> &type)
{
ID *id = map.lookup_default(key, nullptr);
if (!id) {
return nullptr;
}
if (type && GS(id->name) != *type) {
return nullptr;
}
return id;
}
};
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
namespace sim_input = nodes::sim_input;
namespace sim_output = nodes::sim_output;
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 BakeFrameIndices {
std::optional<int> prev;
std::optional<int> current;
std::optional<int> next;
};
static BakeFrameIndices get_bake_frame_indices(
Cleanup: Pass Span by value Also pass Span instead of `const Array &` and use parantheses for BLI includes.
2024-02-27 23:09:54 -05:00
const Span<std::unique_ptr<bake::FrameCache>> frame_caches, const 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
{
BakeFrameIndices frame_indices;
if (!frame_caches.is_empty()) {
Cleanup: BLI: Binary search first_if and last_if utils Cleanup to simplify code by using common terms like _first_ and _last_ in context of predicate applying in a range just like we do for spans and range containers. Pull Request: https://projects.blender.org/blender/blender/pulls/130380
2024-11-19 11:05:57 +01:00
const int first_future_frame_index = binary_search::first_if(
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
frame_caches,
[&](const std::unique_ptr<bake::FrameCache> &value) { return value->frame > frame; });
frame_indices.next = (first_future_frame_index == frame_caches.size()) ?
std::nullopt :
std::optional<int>(first_future_frame_index);
if (first_future_frame_index > 0) {
const int index = first_future_frame_index - 1;
if (frame_caches[index]->frame < frame) {
frame_indices.prev = index;
}
else {
BLI_assert(frame_caches[index]->frame == frame);
frame_indices.current = index;
if (index > 0) {
frame_indices.prev = index - 1;
}
}
}
}
return frame_indices;
}
static void ensure_bake_loaded(bake::NodeBakeCache &bake_cache, bake::FrameCache &frame_cache)
{
if (!frame_cache.state.items_by_id.is_empty()) {
return;
}
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
if (!frame_cache.meta_data_source.has_value()) {
return;
}
if (bake_cache.memory_blob_reader) {
if (const auto *meta_buffer = std::get_if<Span<std::byte>>(&*frame_cache.meta_data_source)) {
const std::string meta_str{reinterpret_cast<const char *>(meta_buffer->data()),
size_t(meta_buffer->size())};
std::istringstream meta_stream{meta_str};
std::optional<bake::BakeState> bake_state = bake::deserialize_bake(
meta_stream, *bake_cache.memory_blob_reader, *bake_cache.blob_sharing);
if (!bake_state.has_value()) {
return;
}
frame_cache.state = std::move(*bake_state);
return;
}
}
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
if (!bake_cache.blobs_dir) {
return;
}
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
const auto *meta_path = std::get_if<std::string>(&*frame_cache.meta_data_source);
if (!meta_path) {
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
return;
}
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
bake::DiskBlobReader blob_reader{*bake_cache.blobs_dir};
fstream meta_file{*meta_path};
std::optional<bake::BakeState> bake_state = bake::deserialize_bake(
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
meta_file, blob_reader, *bake_cache.blob_sharing);
if (!bake_state.has_value()) {
return;
}
frame_cache.state = std::move(*bake_state);
}
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
static bool try_find_baked_data(const NodesModifierBake &bake,
bake::NodeBakeCache &bake_cache,
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
const Main &bmain,
const Object &object,
const NodesModifierData &nmd,
const int id)
{
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
if (bake.packed) {
if (bake.packed->meta_files_num == 0) {
return false;
}
bake_cache.reset();
Map<SubFrame, const NodesModifierBakeFile *> file_by_frame;
for (const NodesModifierBakeFile &meta_file :
Span{bake.packed->meta_files, bake.packed->meta_files_num})
{
const std::optional<SubFrame> frame = bake::file_name_to_frame(meta_file.name);
if (!frame) {
return false;
}
if (!file_by_frame.add(*frame, &meta_file)) {
/* Can only have on file per (sub)frame. */
return false;
}
}
/* Make sure frames processed in the right order. */
Vector<SubFrame> frames;
frames.extend(file_by_frame.keys().begin(), file_by_frame.keys().end());
for (const SubFrame &frame : frames) {
const NodesModifierBakeFile &meta_file = *file_by_frame.lookup(frame);
auto frame_cache = std::make_unique<bake::FrameCache>();
frame_cache->frame = frame;
frame_cache->meta_data_source = meta_file.data();
bake_cache.frames.append(std::move(frame_cache));
}
bake_cache.memory_blob_reader = std::make_unique<bake::MemoryBlobReader>();
for (const NodesModifierBakeFile &blob_file :
Span{bake.packed->blob_files, bake.packed->blob_files_num})
{
bake_cache.memory_blob_reader->add(blob_file.name, blob_file.data());
}
bake_cache.blob_sharing = std::make_unique<bake::BlobReadSharing>();
return true;
}
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
std::optional<bake::BakePath> bake_path = bake::get_node_bake_path(bmain, object, nmd, id);
if (!bake_path) {
return false;
}
Vector<bake::MetaFile> meta_files = bake::find_sorted_meta_files(bake_path->meta_dir);
if (meta_files.is_empty()) {
return false;
}
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
bake_cache.reset();
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
for (const bake::MetaFile &meta_file : meta_files) {
auto frame_cache = std::make_unique<bake::FrameCache>();
frame_cache->frame = meta_file.frame;
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
frame_cache->meta_data_source = meta_file.path;
bake_cache.frames.append(std::move(frame_cache));
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
}
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
bake_cache.blobs_dir = bake_path->blobs_dir;
bake_cache.blob_sharing = std::make_unique<bake::BlobReadSharing>();
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
return true;
}
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
class NodesModifierSimulationParams : public nodes::GeoNodesSimulationParams {
private:
static constexpr float max_delta_frames = 1.0f;
const NodesModifierData &nmd_;
const ModifierEvalContext &ctx_;
const Main *bmain_;
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
const Scene *scene_;
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
SubFrame current_frame_;
bool use_frame_cache_;
bool depsgraph_is_active_;
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
bake::ModifierCache *modifier_cache_;
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
float fps_;
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
bool has_invalid_simulation_ = false;
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
public:
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
struct DataPerZone {
nodes::SimulationZoneBehavior behavior;
NodesModifierBakeDataBlockMap data_block_map;
};
mutable Map<int, std::unique_ptr<DataPerZone>> data_by_zone_id;
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
NodesModifierSimulationParams(NodesModifierData &nmd, const ModifierEvalContext &ctx)
: nmd_(nmd), ctx_(ctx)
Fix #108720: allow discovering baked simulation data during rendering Sometimes the modifier has never been evaluated by an active depsgraph before it is used for rendering. In this case, the baked data was never loaded. Now also allow checking for baked data in a non-active depsgraph. The locking that is in-place already should probably already be enough to make this thread-safe but maybe that could be made more explicit.
2023-06-14 14:23:13 +02:00
{
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
const Depsgraph *depsgraph = ctx_.depsgraph;
bmain_ = DEG_get_bmain(depsgraph);
current_frame_ = DEG_get_ctime(depsgraph);
const Scene *scene = DEG_get_input_scene(depsgraph);
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
scene_ = scene;
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
use_frame_cache_ = ctx_.object->flag & OB_FLAG_USE_SIMULATION_CACHE;
depsgraph_is_active_ = DEG_is_active(depsgraph);
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
modifier_cache_ = nmd.runtime->cache.get();
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
fps_ = FPS;
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
if (!modifier_cache_) {
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
return;
}
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
std::lock_guard lock{modifier_cache_->mutex};
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
if (depsgraph_is_active_) {
/* Invalidate data on user edits. */
if (nmd.modifier.flag & eModifierFlag_UserModified) {
Cleanup: make name more specific for simulations This is necessary for the bake node (#115466).
2023-12-01 17:08:00 +01:00
for (std::unique_ptr<bake::SimulationNodeCache> &node_cache :
modifier_cache_->simulation_cache_by_id.values())
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
{
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
if (node_cache->cache_status != bake::CacheStatus::Baked) {
node_cache->cache_status = bake::CacheStatus::Invalid;
Geometry Nodes: resimulate current frame if it's the last cached one The goal is to simplify debugging the "current" simulation step. Previously, when a frame was cached already, one would have to go back to the beginning to cache everything again. Now, the last cached simulation step is discarded and simulated again if any property that affects it is changed. Pull Request: https://projects.blender.org/blender/blender/pulls/122736
2024-06-06 20:47:17 +02:00
if (!node_cache->bake.frames.is_empty()) {
if (node_cache->bake.frames.last()->frame == current_frame_) {
/* Remove the last (which is the current) cached frame so that it is simulated
* again. */
node_cache->bake.frames.pop_last();
}
}
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
}
}
}
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
this->reset_invalid_node_bakes();
}
Cleanup: make name more specific for simulations This is necessary for the bake node (#115466).
2023-12-01 17:08:00 +01:00
for (const std::unique_ptr<bake::SimulationNodeCache> &node_cache_ptr :
modifier_cache_->simulation_cache_by_id.values())
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
{
Cleanup: make name more specific for simulations This is necessary for the bake node (#115466).
2023-12-01 17:08:00 +01:00
const bake::SimulationNodeCache &node_cache = *node_cache_ptr;
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
if (node_cache.cache_status == bake::CacheStatus::Invalid) {
has_invalid_simulation_ = true;
break;
}
}
}
void reset_invalid_node_bakes()
{
Cleanup: make name more specific for simulations This is necessary for the bake node (#115466).
2023-12-01 17:08:00 +01:00
for (auto item : modifier_cache_->simulation_cache_by_id.items()) {
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
const int id = item.key;
Cleanup: make name more specific for simulations This is necessary for the bake node (#115466).
2023-12-01 17:08:00 +01:00
bake::SimulationNodeCache &node_cache = *item.value;
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
if (node_cache.cache_status != bake::CacheStatus::Invalid) {
continue;
}
const std::optional<IndexRange> sim_frame_range = bake::get_node_bake_frame_range(
*scene_, *ctx_.object, nmd_, id);
if (!sim_frame_range.has_value()) {
continue;
}
const SubFrame start_frame{int(sim_frame_range->start())};
if (current_frame_ <= start_frame) {
node_cache.reset();
}
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
if (!node_cache.bake.frames.is_empty() &&
Clang Format: bump to version 17 Along with the 4.1 libraries upgrade, we are bumping the clang-format version from 8-12 to 17. This affects quite a few files. If not already the case, you may consider pointing your IDE to the clang-format binary bundled with the Blender precompiled libraries.
2024-01-02 18:12:54 +01:00
current_frame_ < node_cache.bake.frames.first()->frame)
{
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
node_cache.reset();
Geometry Nodes: add simulation support 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
2023-05-03 13:18:51 +02:00
}
}
Fix #108720: allow discovering baked simulation data during rendering Sometimes the modifier has never been evaluated by an active depsgraph before it is used for rendering. In this case, the baked data was never loaded. Now also allow checking for baked data in a non-active depsgraph. The locking that is in-place already should probably already be enough to make this thread-safe but maybe that could be made more explicit.
2023-06-14 14:23:13 +02:00
}
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
nodes::SimulationZoneBehavior *get(const int zone_id) const override
{
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
if (!modifier_cache_) {
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
return nullptr;
}
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
std::lock_guard lock{modifier_cache_->mutex};
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
return &this->data_by_zone_id
.lookup_or_add_cb(zone_id,
[&]() {
auto data = std::make_unique<DataPerZone>();
data->behavior.data_block_map = &data->data_block_map;
this->init_simulation_info(
zone_id, data->behavior, data->data_block_map);
return data;
})
->behavior;
}
void init_simulation_info(const int zone_id,
nodes::SimulationZoneBehavior &zone_behavior,
NodesModifierBakeDataBlockMap &data_block_map) const
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
{
Geometry Nodes: improve handling baked data after undo Previously, one could easily "loose" baked data by undoing. The data was not actually deleted, but Blender didn't find it anymore. This happened because `update_existing_bake_caches` was expected to be called after changes to `NodesModifierData.bakes`. However, this was not called after undo. It was also not possible to call this function from `blend_read`, because it required access to the referenced node tree. Now, the bake cache is lazily created during depsgraph evaluation, which partially solves the problem. It can still seem that Blender lost data, but that fixes itself much more quickly after the next evaluation. The remaining issue should be solved a future patch that keeps the bake cache intact over undo steps using `foreach_cache`.
2024-01-29 11:42:34 +01:00
bake::SimulationNodeCache &node_cache =
*modifier_cache_->simulation_cache_by_id.lookup_or_add_cb(
zone_id, []() { return std::make_unique<bake::SimulationNodeCache>(); });
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
const NodesModifierBake &bake = *nmd_.find_bake(zone_id);
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
const IndexRange sim_frame_range = *bake::get_node_bake_frame_range(
*scene_, *ctx_.object, nmd_, zone_id);
const SubFrame sim_start_frame{int(sim_frame_range.first())};
const SubFrame sim_end_frame{int(sim_frame_range.last())};
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
Fix: avoid trying to load bake while baking This could cause issues when rebaking a simulation without freeing the old bake first.
2024-06-03 18:46:35 +02:00
if (!modifier_cache_->requested_bakes.contains(zone_id)) {
/* Try load baked data. */
if (!node_cache.bake.failed_finding_bake) {
if (node_cache.cache_status != bake::CacheStatus::Baked) {
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
if (try_find_baked_data(bake, node_cache.bake, *bmain_, *ctx_.object, nmd_, zone_id)) {
Fix: avoid trying to load bake while baking This could cause issues when rebaking a simulation without freeing the old bake first.
2024-06-03 18:46:35 +02:00
node_cache.cache_status = bake::CacheStatus::Baked;
}
else {
node_cache.bake.failed_finding_bake = true;
}
Fix #109462: Incorrect "No Cache" simulation cache invalidation The "No Cache" simulation nodes option effectively changes the cache to work in a "realtime mode" where there are only two states, the current and previous frame. Whenever the current frame doesn't increase, the previous state should reset. This didn't happen properly, and it was hard to verify because the code was shared with the regular "cache on" mode. Instead, separate the caching more in the code, using a different struct to store the two "realtime" states. Also clarify that we don't support animation of the "No Cache" option by disabling support for that in RNA. Pull Request: https://projects.blender.org/blender/blender/pulls/109741
2023-07-10 16:02:31 +02:00
}
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
}
Geometry Nodes: add simulation support 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
2023-05-03 13:18:51 +02:00
}
Fix #109462: Incorrect "No Cache" simulation cache invalidation The "No Cache" simulation nodes option effectively changes the cache to work in a "realtime mode" where there are only two states, the current and previous frame. Whenever the current frame doesn't increase, the previous state should reset. This didn't happen properly, and it was hard to verify because the code was shared with the regular "cache on" mode. Instead, separate the caching more in the code, using a different struct to store the two "realtime" states. Also clarify that we don't support animation of the "No Cache" option by disabling support for that in RNA. Pull Request: https://projects.blender.org/blender/blender/pulls/109741
2023-07-10 16:02:31 +02:00
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
/* If there are no baked frames, we don't need keep track of the data-blocks. */
Fix #129642: material lost after first frame in uncached simulation zone The issue was that some checks didn't handle the no-cache case correctly. Pull Request: https://projects.blender.org/blender/blender/pulls/129959
2024-11-07 14:25:57 +01:00
if (!node_cache.bake.frames.is_empty() || node_cache.prev_cache.has_value()) {
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
for (const NodesModifierDataBlock &data_block : Span{bake.data_blocks, bake.data_blocks_num})
{
data_block_map.old_mappings.add(data_block, data_block.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
const BakeFrameIndices frame_indices = get_bake_frame_indices(node_cache.bake.frames,
current_frame_);
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
if (node_cache.cache_status == bake::CacheStatus::Baked) {
this->read_from_cache(frame_indices, node_cache, zone_behavior);
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
return;
Fix #109462: Incorrect "No Cache" simulation cache invalidation The "No Cache" simulation nodes option effectively changes the cache to work in a "realtime mode" where there are only two states, the current and previous frame. Whenever the current frame doesn't increase, the previous state should reset. This didn't happen properly, and it was hard to verify because the code was shared with the regular "cache on" mode. Instead, separate the caching more in the code, using a different struct to store the two "realtime" states. Also clarify that we don't support animation of the "No Cache" option by disabling support for that in RNA. Pull Request: https://projects.blender.org/blender/blender/pulls/109741
2023-07-10 16:02:31 +02:00
}
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
if (use_frame_cache_) {
/* If the depsgraph is active, we allow creating new simulation states. Otherwise, the access
* is read-only. */
if (depsgraph_is_active_) {
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
if (node_cache.bake.frames.is_empty()) {
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
if (current_frame_ < sim_start_frame || current_frame_ > sim_end_frame) {
/* Outside of simulation frame range, so ignore the simulation if there is no cache. */
this->input_pass_through(zone_behavior);
this->output_pass_through(zone_behavior);
return;
}
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
/* Initialize the simulation. */
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
if (current_frame_ > sim_start_frame || has_invalid_simulation_) {
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
node_cache.cache_status = bake::CacheStatus::Invalid;
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
}
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
this->input_pass_through(zone_behavior);
this->output_store_frame_cache(node_cache, zone_behavior);
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
return;
}
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
if (frame_indices.prev && !frame_indices.current && !frame_indices.next &&
current_frame_ <= sim_end_frame)
{
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
/* Read the previous frame's data and store the newly computed simulation state. */
auto &output_copy_info = zone_behavior.input.emplace<sim_input::OutputCopy>();
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
const bake::FrameCache &prev_frame_cache = *node_cache.bake.frames[*frame_indices.prev];
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
const float real_delta_frames = float(current_frame_) - float(prev_frame_cache.frame);
if (real_delta_frames != 1) {
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
node_cache.cache_status = bake::CacheStatus::Invalid;
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
}
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
const float delta_frames = std::min(max_delta_frames, real_delta_frames);
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
output_copy_info.delta_time = delta_frames / fps_;
Geometry Nodes: simplify bake state api This introduces `BakeState` and `BakeStateRef` to replace the use of `Map<int, BakeItem pointer>` in various places.
2023-09-01 11:23:53 +02:00
output_copy_info.state = prev_frame_cache.state;
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
this->output_store_frame_cache(node_cache, zone_behavior);
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
return;
}
Geometry Nodes: add simulation support 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
2023-05-03 13:18:51 +02:00
}
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
this->read_from_cache(frame_indices, node_cache, zone_behavior);
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
return;
Geometry Nodes: add simulation support 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
2023-05-03 13:18:51 +02:00
}
Fix #109462: Incorrect "No Cache" simulation cache invalidation The "No Cache" simulation nodes option effectively changes the cache to work in a "realtime mode" where there are only two states, the current and previous frame. Whenever the current frame doesn't increase, the previous state should reset. This didn't happen properly, and it was hard to verify because the code was shared with the regular "cache on" mode. Instead, separate the caching more in the code, using a different struct to store the two "realtime" states. Also clarify that we don't support animation of the "No Cache" option by disabling support for that in RNA. Pull Request: https://projects.blender.org/blender/blender/pulls/109741
2023-07-10 16:02:31 +02:00
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
/* When there is no per-frame cache, check if there is a previous state. */
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
if (node_cache.prev_cache) {
if (node_cache.prev_cache->frame < current_frame_) {
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
/* Do a simulation step. */
const float delta_frames = std::min(
Fix #112094: negative delta time values in simulation nodes
2023-09-14 12:03:24 +02:00
max_delta_frames, float(current_frame_) - float(node_cache.prev_cache->frame));
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
auto &output_move_info = zone_behavior.input.emplace<sim_input::OutputMove>();
output_move_info.delta_time = delta_frames / fps_;
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
output_move_info.state = std::move(node_cache.prev_cache->state);
this->store_as_prev_items(node_cache, zone_behavior);
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
return;
Fix #109462: Incorrect "No Cache" simulation cache invalidation The "No Cache" simulation nodes option effectively changes the cache to work in a "realtime mode" where there are only two states, the current and previous frame. Whenever the current frame doesn't increase, the previous state should reset. This didn't happen properly, and it was hard to verify because the code was shared with the regular "cache on" mode. Instead, separate the caching more in the code, using a different struct to store the two "realtime" states. Also clarify that we don't support animation of the "No Cache" option by disabling support for that in RNA. Pull Request: https://projects.blender.org/blender/blender/pulls/109741
2023-07-10 16:02:31 +02:00
}
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
if (node_cache.prev_cache->frame == current_frame_) {
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
/* Just read from the previous state if the frame has not changed. */
auto &output_copy_info = zone_behavior.input.emplace<sim_input::OutputCopy>();
output_copy_info.delta_time = 0.0f;
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
output_copy_info.state = node_cache.prev_cache->state;
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
auto &read_single_info = zone_behavior.output.emplace<sim_output::ReadSingle>();
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
read_single_info.state = node_cache.prev_cache->state;
Fix: simulation with no-cache resets when changing property The simulation used to reset when the previously computed frame is the same as the current one. However, in this case the output should just be the same as in the previous computation. Pull Request: https://projects.blender.org/blender/blender/pulls/110799
2023-08-04 16:59:56 +02:00
return;
}
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
if (!depsgraph_is_active_) {
/* There is no previous state, and it's not possible to initialize the simulation because
* the depsgraph is not active. */
zone_behavior.input.emplace<sim_input::PassThrough>();
zone_behavior.output.emplace<sim_output::PassThrough>();
return;
}
/* Reset the simulation when the scene time moved backwards. */
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
node_cache.prev_cache.reset();
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
}
zone_behavior.input.emplace<sim_input::PassThrough>();
if (depsgraph_is_active_) {
/* Initialize the simulation. */
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
this->store_as_prev_items(node_cache, zone_behavior);
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
}
else {
zone_behavior.output.emplace<sim_output::PassThrough>();
}
}
Geometry Nodes: add simulation support 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
2023-05-03 13:18:51 +02:00
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
void input_pass_through(nodes::SimulationZoneBehavior &zone_behavior) const
{
zone_behavior.input.emplace<sim_input::PassThrough>();
}
Fix #109462: Incorrect "No Cache" simulation cache invalidation The "No Cache" simulation nodes option effectively changes the cache to work in a "realtime mode" where there are only two states, the current and previous frame. Whenever the current frame doesn't increase, the previous state should reset. This didn't happen properly, and it was hard to verify because the code was shared with the regular "cache on" mode. Instead, separate the caching more in the code, using a different struct to store the two "realtime" states. Also clarify that we don't support animation of the "No Cache" option by disabling support for that in RNA. Pull Request: https://projects.blender.org/blender/blender/pulls/109741
2023-07-10 16:02:31 +02:00
Fix #112094: pass through simulation before first simulated frame This is more expected than outputting empty data.
2023-09-14 12:02:13 +02:00
void output_pass_through(nodes::SimulationZoneBehavior &zone_behavior) const
{
zone_behavior.output.emplace<sim_output::PassThrough>();
}
Cleanup: make name more specific for simulations This is necessary for the bake node (#115466).
2023-12-01 17:08:00 +01:00
void output_store_frame_cache(bake::SimulationNodeCache &node_cache,
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
nodes::SimulationZoneBehavior &zone_behavior) const
{
Geometry Nodes: add Skip input to Simulation Output node This adds a new Skip input to the Simulation Output node (design task: #112082). It is a convenience feature that makes it easy to conditionally forward the output of the Simulation Input node to the Simulation Output node, without the need for potentially multiple Switch nodes. When Skip is enabled, the other inputs of the Simulation Output node are not evaluated, i.e. the nodes in the simulation zone are ignored. The implementation adds this new functionality directly to the `LazyFunction` of the Simulation Output node. It has new inputs that are linked directly to the Simulation Input node, so that the simulation state can be forwarded. Pull Request: https://projects.blender.org/blender/blender/pulls/112140
2023-09-09 09:53:01 +02:00
auto &store_new_state_info = zone_behavior.output.emplace<sim_output::StoreNewState>();
store_new_state_info.store_fn = [simulation_cache = modifier_cache_,
node_cache = &node_cache,
current_frame = current_frame_](bke::bake::BakeState state) {
std::lock_guard lock{simulation_cache->mutex};
auto frame_cache = std::make_unique<bake::FrameCache>();
frame_cache->frame = current_frame;
frame_cache->state = std::move(state);
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
node_cache->bake.frames.append(std::move(frame_cache));
Geometry Nodes: add Skip input to Simulation Output node This adds a new Skip input to the Simulation Output node (design task: #112082). It is a convenience feature that makes it easy to conditionally forward the output of the Simulation Input node to the Simulation Output node, without the need for potentially multiple Switch nodes. When Skip is enabled, the other inputs of the Simulation Output node are not evaluated, i.e. the nodes in the simulation zone are ignored. The implementation adds this new functionality directly to the `LazyFunction` of the Simulation Output node. It has new inputs that are linked directly to the Simulation Input node, so that the simulation state can be forwarded. Pull Request: https://projects.blender.org/blender/blender/pulls/112140
2023-09-09 09:53:01 +02:00
};
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
}
Cleanup: make name more specific for simulations This is necessary for the bake node (#115466).
2023-12-01 17:08:00 +01:00
void store_as_prev_items(bake::SimulationNodeCache &node_cache,
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
nodes::SimulationZoneBehavior &zone_behavior) const
{
Geometry Nodes: add Skip input to Simulation Output node This adds a new Skip input to the Simulation Output node (design task: #112082). It is a convenience feature that makes it easy to conditionally forward the output of the Simulation Input node to the Simulation Output node, without the need for potentially multiple Switch nodes. When Skip is enabled, the other inputs of the Simulation Output node are not evaluated, i.e. the nodes in the simulation zone are ignored. The implementation adds this new functionality directly to the `LazyFunction` of the Simulation Output node. It has new inputs that are linked directly to the Simulation Input node, so that the simulation state can be forwarded. Pull Request: https://projects.blender.org/blender/blender/pulls/112140
2023-09-09 09:53:01 +02:00
auto &store_new_state_info = zone_behavior.output.emplace<sim_output::StoreNewState>();
store_new_state_info.store_fn = [simulation_cache = modifier_cache_,
node_cache = &node_cache,
current_frame = current_frame_](bke::bake::BakeState state) {
std::lock_guard lock{simulation_cache->mutex};
if (!node_cache->prev_cache) {
node_cache->prev_cache.emplace();
}
node_cache->prev_cache->state = std::move(state);
node_cache->prev_cache->frame = current_frame;
};
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
}
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
void read_from_cache(const BakeFrameIndices &frame_indices,
Cleanup: make name more specific for simulations This is necessary for the bake node (#115466).
2023-12-01 17:08:00 +01:00
bake::SimulationNodeCache &node_cache,
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
nodes::SimulationZoneBehavior &zone_behavior) const
{
if (frame_indices.prev) {
auto &output_copy_info = zone_behavior.input.emplace<sim_input::OutputCopy>();
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
bake::FrameCache &frame_cache = *node_cache.bake.frames[*frame_indices.prev];
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
const float delta_frames = std::min(max_delta_frames,
float(current_frame_) - float(frame_cache.frame));
output_copy_info.delta_time = delta_frames / fps_;
Geometry Nodes: simplify bake state api This introduces `BakeState` and `BakeStateRef` to replace the use of `Map<int, BakeItem pointer>` in various places.
2023-09-01 11:23:53 +02:00
output_copy_info.state = frame_cache.state;
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
}
else {
zone_behavior.input.emplace<sim_input::PassThrough>();
}
if (frame_indices.current) {
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
this->read_single(*frame_indices.current, node_cache, zone_behavior);
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
}
else if (frame_indices.next) {
if (frame_indices.prev) {
this->read_interpolated(
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
*frame_indices.prev, *frame_indices.next, node_cache, zone_behavior);
Fix #109462: Incorrect "No Cache" simulation cache invalidation The "No Cache" simulation nodes option effectively changes the cache to work in a "realtime mode" where there are only two states, the current and previous frame. Whenever the current frame doesn't increase, the previous state should reset. This didn't happen properly, and it was hard to verify because the code was shared with the regular "cache on" mode. Instead, separate the caching more in the code, using a different struct to store the two "realtime" states. Also clarify that we don't support animation of the "No Cache" option by disabling support for that in RNA. Pull Request: https://projects.blender.org/blender/blender/pulls/109741
2023-07-10 16:02:31 +02:00
}
else {
Fix #112094: pass through simulation before first simulated frame This is more expected than outputting empty data.
2023-09-14 12:02:13 +02:00
this->output_pass_through(zone_behavior);
Fix #109462: Incorrect "No Cache" simulation cache invalidation The "No Cache" simulation nodes option effectively changes the cache to work in a "realtime mode" where there are only two states, the current and previous frame. Whenever the current frame doesn't increase, the previous state should reset. This didn't happen properly, and it was hard to verify because the code was shared with the regular "cache on" mode. Instead, separate the caching more in the code, using a different struct to store the two "realtime" states. Also clarify that we don't support animation of the "No Cache" option by disabling support for that in RNA. Pull Request: https://projects.blender.org/blender/blender/pulls/109741
2023-07-10 16:02:31 +02:00
}
Geometry Nodes: add simulation support 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
2023-05-03 13:18:51 +02:00
}
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
else if (frame_indices.prev) {
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
this->read_single(*frame_indices.prev, node_cache, zone_behavior);
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
}
else {
Fix #112094: pass through simulation before first simulated frame This is more expected than outputting empty data.
2023-09-14 12:02:13 +02:00
this->output_pass_through(zone_behavior);
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
}
Geometry Nodes: add simulation support 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
2023-05-03 13:18:51 +02:00
}
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
void read_single(const int frame_index,
Cleanup: make name more specific for simulations This is necessary for the bake node (#115466).
2023-12-01 17:08:00 +01:00
bake::SimulationNodeCache &node_cache,
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
nodes::SimulationZoneBehavior &zone_behavior) const
{
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
bake::FrameCache &frame_cache = *node_cache.bake.frames[frame_index];
ensure_bake_loaded(node_cache.bake, frame_cache);
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
auto &read_single_info = zone_behavior.output.emplace<sim_output::ReadSingle>();
Geometry Nodes: simplify bake state api This introduces `BakeState` and `BakeStateRef` to replace the use of `Map<int, BakeItem pointer>` in various places.
2023-09-01 11:23:53 +02:00
read_single_info.state = frame_cache.state;
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
}
void read_interpolated(const int prev_frame_index,
const int next_frame_index,
Cleanup: make name more specific for simulations This is necessary for the bake node (#115466).
2023-12-01 17:08:00 +01:00
bake::SimulationNodeCache &node_cache,
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
nodes::SimulationZoneBehavior &zone_behavior) const
{
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
bake::FrameCache &prev_frame_cache = *node_cache.bake.frames[prev_frame_index];
bake::FrameCache &next_frame_cache = *node_cache.bake.frames[next_frame_index];
ensure_bake_loaded(node_cache.bake, prev_frame_cache);
ensure_bake_loaded(node_cache.bake, next_frame_cache);
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
auto &read_interpolated_info = zone_behavior.output.emplace<sim_output::ReadInterpolated>();
read_interpolated_info.mix_factor = (float(current_frame_) - float(prev_frame_cache.frame)) /
(float(next_frame_cache.frame) -
float(prev_frame_cache.frame));
Geometry Nodes: simplify bake state api This introduces `BakeState` and `BakeStateRef` to replace the use of `Map<int, BakeItem pointer>` in various places.
2023-09-01 11:23:53 +02:00
read_interpolated_info.prev_state = prev_frame_cache.state;
read_interpolated_info.next_state = next_frame_cache.state;
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
}
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
};
class NodesModifierBakeParams : public nodes::GeoNodesBakeParams {
private:
const NodesModifierData &nmd_;
const ModifierEvalContext &ctx_;
Main *bmain_;
SubFrame current_frame_;
bake::ModifierCache *modifier_cache_;
bool depsgraph_is_active_;
public:
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
struct DataPerNode {
nodes::BakeNodeBehavior behavior;
NodesModifierBakeDataBlockMap data_block_map;
};
mutable Map<int, std::unique_ptr<DataPerNode>> data_by_node_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
NodesModifierBakeParams(NodesModifierData &nmd, const ModifierEvalContext &ctx)
: nmd_(nmd), ctx_(ctx)
{
const Depsgraph *depsgraph = ctx_.depsgraph;
current_frame_ = DEG_get_ctime(depsgraph);
modifier_cache_ = nmd.runtime->cache.get();
depsgraph_is_active_ = DEG_is_active(depsgraph);
bmain_ = DEG_get_bmain(depsgraph);
}
Cleanup: Various clang-tidy warnings in modifiers Pull Request: https://projects.blender.org/blender/blender/pulls/133734
2025-01-26 20:07:57 +01:00
nodes::BakeNodeBehavior *get(const int id) const override
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
{
if (!modifier_cache_) {
return nullptr;
}
std::lock_guard lock{modifier_cache_->mutex};
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
return &this->data_by_node_id
.lookup_or_add_cb(id,
[&]() {
auto data = std::make_unique<DataPerNode>();
data->behavior.data_block_map = &data->data_block_map;
this->init_bake_behavior(
id, data->behavior, data->data_block_map);
return data;
})
->behavior;
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
return nullptr;
}
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
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
private:
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
void init_bake_behavior(const int id,
nodes::BakeNodeBehavior &behavior,
NodesModifierBakeDataBlockMap &data_block_map) const
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
{
Geometry Nodes: improve handling baked data after undo Previously, one could easily "loose" baked data by undoing. The data was not actually deleted, but Blender didn't find it anymore. This happened because `update_existing_bake_caches` was expected to be called after changes to `NodesModifierData.bakes`. However, this was not called after undo. It was also not possible to call this function from `blend_read`, because it required access to the referenced node tree. Now, the bake cache is lazily created during depsgraph evaluation, which partially solves the problem. It can still seem that Blender lost data, but that fixes itself much more quickly after the next evaluation. The remaining issue should be solved a future patch that keeps the bake cache intact over undo steps using `foreach_cache`.
2024-01-29 11:42:34 +01:00
bake::BakeNodeCache &node_cache = *modifier_cache_->bake_cache_by_id.lookup_or_add_cb(
id, []() { return std::make_unique<bake::BakeNodeCache>(); });
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
const NodesModifierBake &bake = *nmd_.find_bake(id);
for (const NodesModifierDataBlock &data_block : Span{bake.data_blocks, bake.data_blocks_num}) {
data_block_map.old_mappings.add(data_block, data_block.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
if (depsgraph_is_active_) {
if (modifier_cache_->requested_bakes.contains(id)) {
/* This node is baked during the current evaluation. */
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
auto &store_info = behavior.behavior.emplace<sim_output::StoreNewState>();
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
store_info.store_fn = [modifier_cache = modifier_cache_,
node_cache = &node_cache,
current_frame = current_frame_](bake::BakeState state) {
std::lock_guard lock{modifier_cache->mutex};
auto frame_cache = std::make_unique<bake::FrameCache>();
frame_cache->frame = current_frame;
frame_cache->state = std::move(state);
auto &frames = node_cache->bake.frames;
Cleanup: BLI: Binary search first_if and last_if utils Cleanup to simplify code by using common terms like _first_ and _last_ in context of predicate applying in a range just like we do for spans and range containers. Pull Request: https://projects.blender.org/blender/blender/pulls/130380
2024-11-19 11:05:57 +01:00
const int insert_index = binary_search::first_if(
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
frames, [&](const std::unique_ptr<bake::FrameCache> &frame_cache) {
return frame_cache->frame > current_frame;
});
frames.insert(insert_index, std::move(frame_cache));
};
return;
}
}
/* Try load baked data. */
if (node_cache.bake.frames.is_empty()) {
if (!node_cache.bake.failed_finding_bake) {
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
if (!try_find_baked_data(bake, node_cache.bake, *bmain_, *ctx_.object, nmd_, 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
node_cache.bake.failed_finding_bake = true;
}
}
}
if (node_cache.bake.frames.is_empty()) {
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
behavior.behavior.emplace<sim_output::PassThrough>();
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
return;
}
const BakeFrameIndices frame_indices = get_bake_frame_indices(node_cache.bake.frames,
current_frame_);
if (frame_indices.current) {
this->read_single(*frame_indices.current, node_cache, behavior);
return;
}
if (frame_indices.prev && frame_indices.next) {
this->read_interpolated(*frame_indices.prev, *frame_indices.next, node_cache, behavior);
return;
}
if (frame_indices.prev) {
this->read_single(*frame_indices.prev, node_cache, behavior);
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
return;
}
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
if (frame_indices.next) {
this->read_single(*frame_indices.next, node_cache, behavior);
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
return;
}
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
BLI_assert_unreachable();
}
void read_single(const int frame_index,
bake::BakeNodeCache &node_cache,
nodes::BakeNodeBehavior &behavior) const
{
bake::FrameCache &frame_cache = *node_cache.bake.frames[frame_index];
ensure_bake_loaded(node_cache.bake, frame_cache);
if (this->check_read_error(frame_cache, behavior)) {
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
return;
}
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
auto &read_single_info = behavior.behavior.emplace<sim_output::ReadSingle>();
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
read_single_info.state = frame_cache.state;
}
void read_interpolated(const int prev_frame_index,
const int next_frame_index,
bake::BakeNodeCache &node_cache,
nodes::BakeNodeBehavior &behavior) const
{
bake::FrameCache &prev_frame_cache = *node_cache.bake.frames[prev_frame_index];
bake::FrameCache &next_frame_cache = *node_cache.bake.frames[next_frame_index];
ensure_bake_loaded(node_cache.bake, prev_frame_cache);
ensure_bake_loaded(node_cache.bake, next_frame_cache);
if (this->check_read_error(prev_frame_cache, behavior) ||
this->check_read_error(next_frame_cache, behavior))
{
Cleanup: centralize bake file saving/loading
2023-09-01 10:59:00 +02:00
return;
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
}
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
auto &read_interpolated_info = behavior.behavior.emplace<sim_output::ReadInterpolated>();
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
read_interpolated_info.mix_factor = (float(current_frame_) - float(prev_frame_cache.frame)) /
(float(next_frame_cache.frame) -
float(prev_frame_cache.frame));
read_interpolated_info.prev_state = prev_frame_cache.state;
read_interpolated_info.next_state = next_frame_cache.state;
}
[[nodiscard]] bool check_read_error(const bake::FrameCache &frame_cache,
nodes::BakeNodeBehavior &behavior) const
{
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
if (frame_cache.meta_data_source && frame_cache.state.items_by_id.is_empty()) {
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
auto &read_error_info = behavior.behavior.emplace<sim_output::ReadError>();
UI: fix and improve a few messages - "can not" -> "cannot" in many places (ambiguous, also see Writing Style guide). - "Bezier" -> "Bézier": proper spelling of the eponym. - Tool keymaps: make "Uv" all caps. - "FFMPEG" -> "FFmpeg" (official spelling) - Use MULTIPLICATION SIGN U+00D7 instead of MULTIPLICATION X U+2715. - "LClick" -> "LMB", "RClick" -> "RMB": this convention is used everywhere else. - "Save rendered the image..." -> "Save the rendered image...": typo. - "Preserve Current retiming": title case for property. - Bend status message: punctuation. - "... class used to define the panel" -> "header": copy-paste error. - "... class used to define the menu" -> "asset": copy-paste error. - "Lights user to display objects..." -> "Lights used...": typo. - "-setaudio require one argument" -> "requires": typo. Some issues reported by Joan Pujolar and Tamar Mebonia. Pull Request: https://projects.blender.org/blender/blender/pulls/117856
2024-02-05 17:08:17 +01:00
read_error_info.message = RPT_("Cannot load the baked data");
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
return true;
}
return false;
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
}
};
Geometry Nodes: add simulation support 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
2023-05-03 13:18:51 +02:00
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
static void add_missing_data_block_mappings(
NodesModifierBake &bake,
const Span<bake::BakeDataBlockID> missing,
FunctionRef<ID *(const bake::BakeDataBlockID &)> get_data_block)
{
const int old_num = bake.data_blocks_num;
const int new_num = old_num + missing.size();
bake.data_blocks = reinterpret_cast<NodesModifierDataBlock *>(
MEM_recallocN(bake.data_blocks, sizeof(NodesModifierDataBlock) * new_num));
for (const int i : missing.index_range()) {
NodesModifierDataBlock &data_block = bake.data_blocks[old_num + i];
const blender::bke::bake::BakeDataBlockID &key = missing[i];
data_block.id_name = BLI_strdup(key.id_name.c_str());
if (!key.lib_name.empty()) {
data_block.lib_name = BLI_strdup(key.lib_name.c_str());
}
data_block.id_type = int(key.type);
ID *id = get_data_block(key);
if (id) {
data_block.id = id;
}
}
bake.data_blocks_num = new_num;
}
void nodes_modifier_data_block_destruct(NodesModifierDataBlock *data_block, const bool do_id_user)
{
MEM_SAFE_FREE(data_block->id_name);
MEM_SAFE_FREE(data_block->lib_name);
if (do_id_user) {
id_us_min(data_block->id);
}
}
/**
* During evaluation we might have baked geometry that contains references to other data-blocks
* (such as materials). We need to make sure that those data-blocks stay dependencies of the
* modifier. Otherwise, the data-block references might not work when the baked data is loaded
* again. Therefor, the dependencies are written back to the original modifier.
*/
static void add_data_block_items_writeback(const ModifierEvalContext &ctx,
NodesModifierData &nmd_eval,
NodesModifierData &nmd_orig,
NodesModifierSimulationParams &simulation_params,
NodesModifierBakeParams &bake_params)
{
Depsgraph *depsgraph = ctx.depsgraph;
Main *bmain = DEG_get_bmain(depsgraph);
struct DataPerBake {
bool reset_first = false;
Map<bake::BakeDataBlockID, ID *> new_mappings;
};
Map<int, DataPerBake> writeback_data;
for (auto item : simulation_params.data_by_zone_id.items()) {
DataPerBake data;
NodesModifierBake &bake = *nmd_eval.find_bake(item.key);
if (item.value->data_block_map.old_mappings.size() < bake.data_blocks_num) {
data.reset_first = true;
}
if (bake::SimulationNodeCache *node_cache = nmd_eval.runtime->cache->get_simulation_node_cache(
item.key))
{
/* Only writeback if the bake node has actually baked anything. */
Fix #129642: material lost after first frame in uncached simulation zone The issue was that some checks didn't handle the no-cache case correctly. Pull Request: https://projects.blender.org/blender/blender/pulls/129959
2024-11-07 14:25:57 +01:00
if (!node_cache->bake.frames.is_empty() || node_cache->prev_cache.has_value()) {
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
data.new_mappings = std::move(item.value->data_block_map.new_mappings);
}
}
if (data.reset_first || !data.new_mappings.is_empty()) {
writeback_data.add(item.key, std::move(data));
}
}
for (auto item : bake_params.data_by_node_id.items()) {
if (bake::BakeNodeCache *node_cache = nmd_eval.runtime->cache->get_bake_node_cache(item.key)) {
/* Only writeback if the bake node has actually baked anything. */
if (!node_cache->bake.frames.is_empty()) {
DataPerBake data;
data.new_mappings = std::move(item.value->data_block_map.new_mappings);
writeback_data.add(item.key, std::move(data));
}
}
}
if (writeback_data.is_empty()) {
/* Nothing to do. */
return;
}
deg::sync_writeback::add(
*depsgraph,
Cleanup: Remove unused capture Pull Request: https://projects.blender.org/blender/blender/pulls/117750
2024-02-02 12:18:32 +01:00
[object_eval = ctx.object,
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
bmain,
&nmd_orig,
&nmd_eval,
writeback_data = std::move(writeback_data)]() {
for (auto item : writeback_data.items()) {
const int bake_id = item.key;
DataPerBake data = item.value;
NodesModifierBake &bake_orig = *nmd_orig.find_bake(bake_id);
NodesModifierBake &bake_eval = *nmd_eval.find_bake(bake_id);
if (data.reset_first) {
/* Reset data-block list on original data. */
dna::array::clear<NodesModifierDataBlock>(&bake_orig.data_blocks,
&bake_orig.data_blocks_num,
&bake_orig.active_data_block,
[](NodesModifierDataBlock *data_block) {
nodes_modifier_data_block_destruct(
data_block, true);
});
/* Reset data-block list on evaluated data. */
dna::array::clear<NodesModifierDataBlock>(&bake_eval.data_blocks,
&bake_eval.data_blocks_num,
&bake_eval.active_data_block,
[](NodesModifierDataBlock *data_block) {
nodes_modifier_data_block_destruct(
data_block, false);
});
}
Vector<bake::BakeDataBlockID> sorted_new_mappings;
sorted_new_mappings.extend(data.new_mappings.keys().begin(),
data.new_mappings.keys().end());
bool needs_reevaluation = false;
/* Add new data block mappings to the original modifier. This may do a name lookup in
* bmain to find the data block if there is not faster way to get it. */
add_missing_data_block_mappings(
bake_orig, sorted_new_mappings, [&](const bake::BakeDataBlockID &key) -> ID * {
ID *id_orig = nullptr;
if (ID *id_eval = data.new_mappings.lookup_default(key, nullptr)) {
Depsgraph: improve type safety when getting evaluated or original ID The goal here is to avoid having to cast to and from `ID` when getting the evaluated or original ID using the depsgraph API, which is often verbose and not type safe. To solve this, there are now `DEG_get_original` and `DEG_get_evaluated` methods which are templated on the type and use a new `is_ID_v` static type check to make sure it's only used with valid types. This allows removing quite some verbosity on all the call sites. I also removed `DEG_get_original_object`, because that does not have to be a special case anymore. Pull Request: https://projects.blender.org/blender/blender/pulls/137629
2025-04-17 13:09:20 +02:00
id_orig = DEG_get_original(id_eval);
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
}
else {
needs_reevaluation = true;
id_orig = BKE_libblock_find_name_and_library(
bmain, short(key.type), key.id_name.c_str(), key.lib_name.c_str());
}
if (id_orig) {
id_us_plus(id_orig);
}
return id_orig;
});
/* Add new data block mappings to the evaluated modifier. In most cases this makes it so
* the evaluated modifier is in the same state as if it were copied from the updated
* original again. The exception is when a missing data block was found that is not in
* the depsgraph currently. */
add_missing_data_block_mappings(
bake_eval, sorted_new_mappings, [&](const bake::BakeDataBlockID &key) -> ID * {
return data.new_mappings.lookup_default(key, nullptr);
});
if (needs_reevaluation) {
Depsgraph: improve type safety when getting evaluated or original ID The goal here is to avoid having to cast to and from `ID` when getting the evaluated or original ID using the depsgraph API, which is often verbose and not type safe. To solve this, there are now `DEG_get_original` and `DEG_get_evaluated` methods which are templated on the type and use a new `is_ID_v` static type check to make sure it's only used with valid types. This allows removing quite some verbosity on all the call sites. I also removed `DEG_get_original_object`, because that does not have to be a special case anymore. Pull Request: https://projects.blender.org/blender/blender/pulls/137629
2025-04-17 13:09:20 +02:00
Object *object_orig = DEG_get_original(object_eval);
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
DEG_id_tag_update(&object_orig->id, ID_RECALC_GEOMETRY);
DEG_relations_tag_update(bmain);
}
}
});
}
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
static void modifyGeometry(ModifierData *md,
const ModifierEvalContext *ctx,
Cleanup: Move GeometrySet and components to proper namespace Move `GeometrySet` and `GeometryComponent` and subclasses to the `blender::bke` namespace. This wasn't done earlier since these were one of the first C++ classes used throughout Blender, but now it is common. Also remove the now-unnecessary C-header, since all users of the geometry set header are now in C++. Pull Request: https://projects.blender.org/blender/blender/pulls/109020
2023-06-15 22:18:28 +02:00
bke::GeometrySet &geometry_set)
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
{
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
using namespace blender;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
NodesModifierData *nmd = reinterpret_cast<NodesModifierData *>(md);
if (nmd->node_group == nullptr) {
return;
}
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
NodesModifierData *nmd_orig = reinterpret_cast<NodesModifierData *>(
BKE_modifier_get_original(ctx->object, &nmd->modifier));
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
Geometry Nodes: Improve performance with many inputs Resolves #136183 To avoid quadratic worst case runtime when gathering values from the modifier properties, build a temporary VectorSet of the modifier's IDProperties. In the file from #136183, this change improves playback performance by 1.4x for me, from 50 to 70ms. Ideally IDProperty groups would have constant time lookup on their own, but that's a much larger change, and this smaller change for just Geometry Nodes is not so invasive. Pull Request: https://projects.blender.org/blender/blender/pulls/136463
2025-03-25 15:40:32 +01:00
nodes::PropertiesVectorSet properties = nodes::build_properties_vector_set(
nmd->settings.properties);
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
const bNodeTree &tree = *nmd->node_group;
Geometry Nodes: Improve performance with many inputs Resolves #136183 To avoid quadratic worst case runtime when gathering values from the modifier properties, build a temporary VectorSet of the modifier's IDProperties. In the file from #136183, this change improves playback performance by 1.4x for me, from 50 to 70ms. Ideally IDProperty groups would have constant time lookup on their own, but that's a much larger change, and this smaller change for just Geometry Nodes is not so invasive. Pull Request: https://projects.blender.org/blender/blender/pulls/136463
2025-03-25 15:40:32 +01:00
check_property_socket_sync(ctx->object, properties, md);
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
Fix #112331: Add update tags directly in bNodeTreeInterface API methods Calling an API function after the node panels patch does not internally tag the node tree with `NTREE_CHANGED_INTERFACE` any more, because the node tree is not directly accessible from `bNodeTreeInterface`. Before node panels the API functions for interfaces could tag the tree directly for later update consideration, which now requires explicit tagging calls. The fix is to add a flag and mutex directly to `bNodeTreeInterface`, so API methods can tag after updates. This mostly copies runtime data concepts from `bNodeTree`. The `ensure_interface_cache` method is equivalent to `ensure_topology_cache` and should be called before accessing `interface_inputs` and similar cache data. Pull Request: https://projects.blender.org/blender/blender/pulls/111741
2023-09-14 14:13:07 +02:00
tree.ensure_topology_cache();
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
const bNode *output_node = tree.group_output_node();
if (output_node == nullptr) {
BKE_modifier_set_error(ctx->object, md, "Node group must have a group output node");
Geometry Nodes: Clarify modifier node group errors This commit adds modifier error messages to some of the cases where the node group is configured improperly. It also clears the geometry set when there is an error with the node group. This is consistent to what we do in nodes themselves, and feels more intuitive than passing the input geometry through the node group silently. Fixes T87142
2021-11-10 10:52:07 -06:00
geometry_set.clear();
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
return;
}
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
Span<const bNodeSocket *> group_outputs = output_node->input_sockets().drop_back(1);
Geometry Nodes: support creating new attributes in modifier This patch allows passing a field to the modifier as output. In the modifier, the user can choose an attribute name. The attribute will be filled with values computed by the field. This only works for realized mesh/curve/point data. As mentioned in T91376, the output domain is selected in the node group itself. We might want to add this functionality to the modifier later as well, but not now. Differential Revision: https://developer.blender.org/D12644
2021-09-27 15:33:48 +02:00
if (group_outputs.is_empty()) {
Geometry Nodes: Clarify modifier node group errors This commit adds modifier error messages to some of the cases where the node group is configured improperly. It also clears the geometry set when there is an error with the node group. This is consistent to what we do in nodes themselves, and feels more intuitive than passing the input geometry through the node group silently. Fixes T87142
2021-11-10 10:52:07 -06:00
BKE_modifier_set_error(ctx->object, md, "Node group must have an output socket");
geometry_set.clear();
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
return;
}
Nodes: move NodeTreeRef functionality into node runtime data The purpose of `NodeTreeRef` was to speed up various queries on a read-only `bNodeTree`. Not that we have runtime data in nodes and sockets, we can also store the result of some queries there. This has some benefits: * No need for a read-only separate node tree data structure which increased complexity. * Makes it easier to reuse cached queries in more parts of Blender that can benefit from it. A downside is that we loose some type safety that we got by having different types for input and output sockets, as well as internal and non-internal links. This patch also refactors `DerivedNodeTree` so that it does not use `NodeTreeRef` anymore, but uses `bNodeTree` directly instead. To provide a convenient API (that is also close to what `NodeTreeRef` has), a new approach is implemented: `bNodeTree`, `bNode`, `bNodeSocket` and `bNodeLink` now have C++ methods declared in `DNA_node_types.h` which are implemented in `BKE_node_runtime.hh`. To make this work, `makesdna` now skips c++ sections when parsing dna header files. No user visible changes are expected. Differential Revision: https://developer.blender.org/D15491
2022-08-31 12:15:57 +02:00
const bNodeSocket *first_output_socket = group_outputs[0];
if (!STREQ(first_output_socket->idname, "NodeSocketGeometry")) {
Geometry Nodes: Clarify modifier node group errors This commit adds modifier error messages to some of the cases where the node group is configured improperly. It also clears the geometry set when there is an error with the node group. This is consistent to what we do in nodes themselves, and feels more intuitive than passing the input geometry through the node group silently. Fixes T87142
2021-11-10 10:52:07 -06:00
BKE_modifier_set_error(ctx->object, md, "Node group's first output must be a geometry");
geometry_set.clear();
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
return;
}
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
const nodes::GeometryNodesLazyFunctionGraphInfo *lf_graph_info =
nodes::ensure_geometry_nodes_lazy_function_graph(tree);
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
if (lf_graph_info == nullptr) {
BKE_modifier_set_error(ctx->object, md, "Cannot evaluate node group");
geometry_set.clear();
return;
}
Fix T95479: geometry nodes crash with cage display Differential Revision: https://developer.blender.org/D14225
2022-03-02 16:10:42 +01:00
bool use_orig_index_verts = false;
bool use_orig_index_edges = false;
Mesh: Rename "polys" to "faces" Implements part of #101689. The "poly" name was chosen to distinguish the `MLoop` + `MPoly` combination from the `MFace` struct it replaced. Those two structures persisted together for a long time, but nowadays `MPoly` is gone, and `MFace` is only used in some legacy code like the particle system. To avoid unnecessarily using a different term, increase consistency with the UI and with BMesh, and generally make code a bit easier to read, this commit replaces the `poly` term with `poly`. Most variables that use the term are renamed too. `Mesh.totface` and `Mesh.fdata` now have a `_legacy` suffix to reduce confusion. In a next step, `pdata` can be renamed to `face_data` as well. Pull Request: https://projects.blender.org/blender/blender/pulls/109819
2023-07-24 22:06:55 +02:00
bool use_orig_index_faces = false;
Cleanup: Make geometry set naming more consistent Remove the "_for_read" suffix from methods to get geometry and geometry components. That should be considered the default, so the suffix just adds unnecessary text. This is consistent with the attribute API and various implicit sharing data access methods. Use "from_mesh" instead of "create_with_mesh". This is consistent with the recently used naming for the `IndexMask` API. Pull Request: https://projects.blender.org/blender/blender/pulls/110738
2023-08-03 17:09:18 +02:00
if (const Mesh *mesh = geometry_set.get_mesh()) {
Cleanup: Rename mesh custom data fields Implements the rest of #101689, after 5e9ea9243b33916e693c. - `vdata` -> `vert_data` - `edata` -> `edge_data` - `pdata` -> `face_data` - `ldata` -> `loop_data` A deeper rename of `loop` to `corner` will be proposed as a next step, and renaming `totvert` and `totedge` can be done separately. Pull Request: https://projects.blender.org/blender/blender/pulls/110432
2023-07-25 21:15:52 +02:00
use_orig_index_verts = CustomData_has_layer(&mesh->vert_data, CD_ORIGINDEX);
use_orig_index_edges = CustomData_has_layer(&mesh->edge_data, CD_ORIGINDEX);
use_orig_index_faces = CustomData_has_layer(&mesh->face_data, CD_ORIGINDEX);
Fix T95479: geometry nodes crash with cage display Differential Revision: https://developer.blender.org/D14225
2022-03-02 16:10:42 +01:00
}
Geometry Nodes: extract global data passed to a geometry nodes invocation to separate struct This avoids some duplication between the modifier and operator evaluation contexts and also makes it easier to make independent from a specific evaluation context (so e.g. the simulation nodes code shouldn't care whether it's used from a modifier or operator. Pull Request: https://projects.blender.org/blender/blender/pulls/115512
2023-11-29 13:22:20 +01:00
nodes::GeoNodesCallData call_data;
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
nodes::GeoNodesModifierData modifier_eval_data{};
modifier_eval_data.depsgraph = ctx->depsgraph;
modifier_eval_data.self_object = ctx->object;
auto eval_log = std::make_unique<geo_log::GeoModifierLog>();
Geometry Nodes: extract global data passed to a geometry nodes invocation to separate struct This avoids some duplication between the modifier and operator evaluation contexts and also makes it easier to make independent from a specific evaluation context (so e.g. the simulation nodes code shouldn't care whether it's used from a modifier or operator. Pull Request: https://projects.blender.org/blender/blender/pulls/115512
2023-11-29 13:22:20 +01:00
call_data.modifier_data = &modifier_eval_data;
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
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
NodesModifierSimulationParams simulation_params(*nmd, *ctx);
Geometry Nodes: extract global data passed to a geometry nodes invocation to separate struct This avoids some duplication between the modifier and operator evaluation contexts and also makes it easier to make independent from a specific evaluation context (so e.g. the simulation nodes code shouldn't care whether it's used from a modifier or operator. Pull Request: https://projects.blender.org/blender/blender/pulls/115512
2023-11-29 13:22:20 +01:00
call_data.simulation_params = &simulation_params;
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
NodesModifierBakeParams bake_params{*nmd, *ctx};
call_data.bake_params = &bake_params;
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
Set<ComputeContextHash> socket_log_contexts;
if (logging_enabled(ctx)) {
Geometry Nodes: extract global data passed to a geometry nodes invocation to separate struct This avoids some duplication between the modifier and operator evaluation contexts and also makes it easier to make independent from a specific evaluation context (so e.g. the simulation nodes code shouldn't care whether it's used from a modifier or operator. Pull Request: https://projects.blender.org/blender/blender/pulls/115512
2023-11-29 13:22:20 +01:00
call_data.eval_log = eval_log.get();
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
find_socket_log_contexts(*nmd, *ctx, socket_log_contexts);
Geometry Nodes: extract global data passed to a geometry nodes invocation to separate struct This avoids some duplication between the modifier and operator evaluation contexts and also makes it easier to make independent from a specific evaluation context (so e.g. the simulation nodes code shouldn't care whether it's used from a modifier or operator. Pull Request: https://projects.blender.org/blender/blender/pulls/115512
2023-11-29 13:22:20 +01:00
call_data.socket_log_contexts = &socket_log_contexts;
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
}
Geometry Nodes: use separate struct for side effect nodes This makes it easier to add another map containing side effect nodes in #112421. No functional changes expected.
2023-09-16 18:57:04 +02:00
nodes::GeoNodesSideEffectNodes side_effect_nodes;
Geometry Nodes: support attaching gizmos to input values This adds support for attaching gizmos for input values. The goal is to make it easier for users to set input values intuitively in the 3D viewport. We went through multiple different possible designs until we settled on the one implemented here. We picked it for it's flexibility and ease of use when using geometry node assets. The core principle in the design is that **gizmos are attached to existing input values instead of being the input value themselves**. This actually fits the existing concept of gizmos in Blender well, but may be a bit unintutitive in a node setup at first. The attachment is done using links in the node editor. The most basic usage of the node is to link a Value node to the new Linear Gizmo node. This attaches the gizmo to the input value and allows you to change it from the 3D view. The attachment is indicated by the gizmo icon in the sockets which are controlled by a gizmo as well as the back-link (notice the double link) when the gizmo is active. The core principle makes it straight forward to control the same node setup from the 3D view with gizmos, or by manually changing input values, or by driving the input values procedurally. If the input value is controlled indirectly by other inputs, it's often possible to **automatically propagate** the gizmo to the actual input. Backpropagation does not work for all nodes, although more nodes can be supported over time. This patch adds the first three gizmo nodes which cover common use cases: * **Linear Gizmo**: Creates a gizmo that controls a float or integer value using a linear movement of e.g. an arrow in the 3D viewport. * **Dial Gizmo**: Creates a circular gizmo in the 3D viewport that can be rotated to change the attached angle input. * **Transform Gizmo**: Creates a simple gizmo for location, rotation and scale. In the future, more built-in gizmos and potentially the ability for custom gizmos could be added. All gizmo nodes have a **Transform** geometry output. Using it is optional but it is recommended when the gizmo is used to control inputs that affect a geometry. When it is used, Blender will automatically transform the gizmos together with the geometry that they control. To achieve this, the output should be merged with the generated geometry using the *Join Geometry* node. The data contained in *Transform* output is not visible geometry, but just internal information that helps Blender to give a better user experience when using gizmos. The gizmo nodes have a multi-input socket. This allows **controlling multiple values** with the same gizmo. Only a small set of **gizmo shapes** is supported initially. It might be extended in the future but one goal is to give the gizmos used by different node group assets a familiar look and feel. A similar constraint exists for **colors**. Currently, one can choose from a fixed set of colors which can be modified in the theme settings. The set of **visible gizmos** is determined by a multiple factors because it's not really feasible to show all possible gizmos at all times. To see any of the geometry nodes gizmos, the "Active Modifier" option has to be enabled in the "Viewport Gizmos" popover. Then all gizmos are drawn for which at least one of the following is true: * The gizmo controls an input of the active modifier of the active object. * The gizmo controls a value in a selected node in an open node editor. * The gizmo controls a pinned value in an open node editor. Pinning works by clicking the gizmo icon next to the value. Pull Request: https://projects.blender.org/blender/blender/pulls/112677
2024-07-10 16:18:47 +02:00
find_side_effect_nodes(*nmd, *ctx, side_effect_nodes, socket_log_contexts);
Geometry Nodes: extract global data passed to a geometry nodes invocation to separate struct This avoids some duplication between the modifier and operator evaluation contexts and also makes it easier to make independent from a specific evaluation context (so e.g. the simulation nodes code shouldn't care whether it's used from a modifier or operator. Pull Request: https://projects.blender.org/blender/blender/pulls/115512
2023-11-29 13:22:20 +01:00
call_data.side_effect_nodes = &side_effect_nodes;
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
Refactor: Geometry Nodes: store tree identifier in tree logger The main goal here is to add `GeoTreeLogger.tree_orig_session_uid`. Previously, it was always possible to derive this information in `ensure_node_warnings`. However, with closures that's not possible in general anymore, because the Evaluate Closure node does not know statically which node tree the closure zone is from that it evaluates. Therefore, this information has to be logged as well. This patch initializes `tree_orig_session_uid` the same way it initializes `parent_node_id`, by scanning the compute context when creating the tree logger. To make this work properly, some extra contextual data had to be stored in some compute contexts. This is just a refactor with no expected functional changes. Node warnings for closures are still not properly logged, because that requires storing source-location data in closures, which will be implemented separately. Pull Request: https://projects.blender.org/blender/blender/pulls/137208
2025-04-10 08:56:02 +02:00
bke::ModifierComputeContext modifier_compute_context{nullptr, *nmd};
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
Geometry Nodes: Improve performance with many inputs Resolves #136183 To avoid quadratic worst case runtime when gathering values from the modifier properties, build a temporary VectorSet of the modifier's IDProperties. In the file from #136183, this change improves playback performance by 1.4x for me, from 50 to 70ms. Ideally IDProperty groups would have constant time lookup on their own, but that's a much larger change, and this smaller change for just Geometry Nodes is not so invasive. Pull Request: https://projects.blender.org/blender/blender/pulls/136463
2025-03-25 15:40:32 +01:00
geometry_set = nodes::execute_geometry_nodes_on_geometry(
tree, properties, modifier_compute_context, call_data, std::move(geometry_set));
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
if (logging_enabled(ctx)) {
Geometry Nodes: add run-time data to geometry nodes modifier This adds a single run-time field and moves the existing run-time data into a new struct. This approach makes it much easier to add new run-time data. Pull Request: https://projects.blender.org/blender/blender/pulls/109905
2023-07-11 12:55:57 +02:00
nmd_orig->runtime->eval_log = std::move(eval_log);
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
}
Fix #125291: crash when applying curves modifier when there is a bake The crash was caused by attempting to write-back to the original data after it has been removed (`add_data_block_items_writeback`). This write-back is already disabled when applying a modifier, however the corresponding flag was only set when applying modifiers on mesh objects. This patch fixes this issue with two small changes: * Rename `MOD_APPLY_TO_BASE_MESH` to `MOD_APPLY_TO_ORIGINAL` to make it more generic. * Pass this flag into modifier evaluation for other geometry types besides meshes in `modifier_apply_obdata`. Pull Request: https://projects.blender.org/blender/blender/pulls/125761
2024-08-01 13:36:43 +02:00
if (DEG_is_active(ctx->depsgraph) && !(ctx->flag & MOD_APPLY_TO_ORIGINAL)) {
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
add_data_block_items_writeback(*ctx, *nmd, *nmd_orig, simulation_params, bake_params);
}
Mesh: Rename "polys" to "faces" Implements part of #101689. The "poly" name was chosen to distinguish the `MLoop` + `MPoly` combination from the `MFace` struct it replaced. Those two structures persisted together for a long time, but nowadays `MPoly` is gone, and `MFace` is only used in some legacy code like the particle system. To avoid unnecessarily using a different term, increase consistency with the UI and with BMesh, and generally make code a bit easier to read, this commit replaces the `poly` term with `poly`. Most variables that use the term are renamed too. `Mesh.totface` and `Mesh.fdata` now have a `_legacy` suffix to reduce confusion. In a next step, `pdata` can be renamed to `face_data` as well. Pull Request: https://projects.blender.org/blender/blender/pulls/109819
2023-07-24 22:06:55 +02:00
if (use_orig_index_verts || use_orig_index_edges || use_orig_index_faces) {
Geometry Nodes: Avoid mesh copy in some cases Accessing a mesh with write access can be costly if it is used elsewhere at the same time because of copy-on-write. When always did that at the end of the modifier calculation, but it's trivial to only do that when we might need actually use the mesh to add original index layers.
2022-12-19 14:24:49 -06:00
if (Mesh *mesh = geometry_set.get_mesh_for_write()) {
/* Add #CD_ORIGINDEX layers if they don't exist already. This is required because the
* #eModifierTypeFlag_SupportsMapping flag is set. If the layers did not exist before, it is
* assumed that the output mesh does not have a mapping to the original mesh. */
if (use_orig_index_verts) {
Mesh: Rename totvert, totedge, and totloop fields Use the standard "elements_num" naming, and use the "corner" name rather than the old "loop" name: `verts_num`, `edges_num`, and `corners_num`. This matches the existing `faces_num` field which was already renamed. Pull Request: https://projects.blender.org/blender/blender/pulls/116350
2023-12-20 02:21:48 +01:00
CustomData_add_layer(&mesh->vert_data, CD_ORIGINDEX, CD_SET_DEFAULT, mesh->verts_num);
Geometry Nodes: Avoid mesh copy in some cases Accessing a mesh with write access can be costly if it is used elsewhere at the same time because of copy-on-write. When always did that at the end of the modifier calculation, but it's trivial to only do that when we might need actually use the mesh to add original index layers.
2022-12-19 14:24:49 -06:00
}
if (use_orig_index_edges) {
Mesh: Rename totvert, totedge, and totloop fields Use the standard "elements_num" naming, and use the "corner" name rather than the old "loop" name: `verts_num`, `edges_num`, and `corners_num`. This matches the existing `faces_num` field which was already renamed. Pull Request: https://projects.blender.org/blender/blender/pulls/116350
2023-12-20 02:21:48 +01:00
CustomData_add_layer(&mesh->edge_data, CD_ORIGINDEX, CD_SET_DEFAULT, mesh->edges_num);
Geometry Nodes: Avoid mesh copy in some cases Accessing a mesh with write access can be costly if it is used elsewhere at the same time because of copy-on-write. When always did that at the end of the modifier calculation, but it's trivial to only do that when we might need actually use the mesh to add original index layers.
2022-12-19 14:24:49 -06:00
}
Mesh: Rename "polys" to "faces" Implements part of #101689. The "poly" name was chosen to distinguish the `MLoop` + `MPoly` combination from the `MFace` struct it replaced. Those two structures persisted together for a long time, but nowadays `MPoly` is gone, and `MFace` is only used in some legacy code like the particle system. To avoid unnecessarily using a different term, increase consistency with the UI and with BMesh, and generally make code a bit easier to read, this commit replaces the `poly` term with `poly`. Most variables that use the term are renamed too. `Mesh.totface` and `Mesh.fdata` now have a `_legacy` suffix to reduce confusion. In a next step, `pdata` can be renamed to `face_data` as well. Pull Request: https://projects.blender.org/blender/blender/pulls/109819
2023-07-24 22:06:55 +02:00
if (use_orig_index_faces) {
Cleanup: Rename mesh custom data fields Implements the rest of #101689, after 5e9ea9243b33916e693c. - `vdata` -> `vert_data` - `edata` -> `edge_data` - `pdata` -> `face_data` - `ldata` -> `loop_data` A deeper rename of `loop` to `corner` will be proposed as a next step, and renaming `totvert` and `totedge` can be done separately. Pull Request: https://projects.blender.org/blender/blender/pulls/110432
2023-07-25 21:15:52 +02:00
CustomData_add_layer(&mesh->face_data, CD_ORIGINDEX, CD_SET_DEFAULT, mesh->faces_num);
Geometry Nodes: Avoid mesh copy in some cases Accessing a mesh with write access can be costly if it is used elsewhere at the same time because of copy-on-write. When always did that at the end of the modifier calculation, but it's trivial to only do that when we might need actually use the mesh to add original index layers.
2022-12-19 14:24:49 -06:00
}
Fix T95479: geometry nodes crash with cage display Differential Revision: https://developer.blender.org/D14225
2022-03-02 16:10:42 +01:00
}
}
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
}
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
static Mesh *modify_mesh(ModifierData *md, const ModifierEvalContext *ctx, Mesh *mesh)
Fix T103294: bring back modifyMesh function for geometry nodes modifier This was removed inrBb1494bcea7b6bb608 under the assumption that it is not needed anymore. Apparently it is, so this commit brings it back.
2022-12-17 14:46:15 +01:00
{
Cleanup: Make geometry set naming more consistent Remove the "_for_read" suffix from methods to get geometry and geometry components. That should be considered the default, so the suffix just adds unnecessary text. This is consistent with the attribute API and various implicit sharing data access methods. Use "from_mesh" instead of "create_with_mesh". This is consistent with the recently used naming for the `IndexMask` API. Pull Request: https://projects.blender.org/blender/blender/pulls/110738
2023-08-03 17:09:18 +02:00
bke::GeometrySet geometry_set = bke::GeometrySet::from_mesh(
Cleanup: Move GeometrySet and components to proper namespace Move `GeometrySet` and `GeometryComponent` and subclasses to the `blender::bke` namespace. This wasn't done earlier since these were one of the first C++ classes used throughout Blender, but now it is common. Also remove the now-unnecessary C-header, since all users of the geometry set header are now in C++. Pull Request: https://projects.blender.org/blender/blender/pulls/109020
2023-06-15 22:18:28 +02:00
mesh, bke::GeometryOwnershipType::Editable);
Fix T103294: bring back modifyMesh function for geometry nodes modifier This was removed inrBb1494bcea7b6bb608 under the assumption that it is not needed anymore. Apparently it is, so this commit brings it back.
2022-12-17 14:46:15 +01:00
modifyGeometry(md, ctx, geometry_set);
Fix #137114: crash due to bad mesh ownership handling When releasing a mesh from a `GeometrySet` one has to take manual control over owner-management. In some cases, the geometry set was not the owner of the mesh, but was just referencing it. This is generally fine in a limited set of circumstances and can avoid copies. However, when taking ownership of the mesh in the geometry set, one has to be sure that the geometry set actually has ownership. This is similar to what is done in e.g. `modifier_modify_mesh_and_geometry_set`. Pull Request: https://projects.blender.org/blender/blender/pulls/137150
2025-04-08 16:11:52 +02:00
bke::MeshComponent &mesh_component = geometry_set.get_component_for_write<bke::MeshComponent>();
if (mesh_component.get() != mesh) {
/* If this is the same as the input mesh, it's not necessary to make a copy of it even if it's
* not owned by the geometry set. That's because we know that the caller manages the ownership
* of the mesh. */
mesh_component.ensure_owns_direct_data();
}
Mesh *new_mesh = mesh_component.release();
Fix T103294: bring back modifyMesh function for geometry nodes modifier This was removed inrBb1494bcea7b6bb608 under the assumption that it is not needed anymore. Apparently it is, so this commit brings it back.
2022-12-17 14:46:15 +01:00
if (new_mesh == nullptr) {
Cleanup: Remove legacy argument from mesh creation functions The legacy `tessface_len` argument was only used for the explode modifier. Remove it and copy the legacy face data manually there.
2023-02-27 11:09:26 -05:00
return BKE_mesh_new_nomain(0, 0, 0, 0);
Fix T103294: bring back modifyMesh function for geometry nodes modifier This was removed inrBb1494bcea7b6bb608 under the assumption that it is not needed anymore. Apparently it is, so this commit brings it back.
2022-12-17 14:46:15 +01:00
}
return new_mesh;
}
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
static void modify_geometry_set(ModifierData *md,
const ModifierEvalContext *ctx,
bke::GeometrySet *geometry_set)
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
{
modifyGeometry(md, ctx, *geometry_set);
}
Geometry Nodes: Add Grease Pencil layer name search This makes it possible to search layer names in the `Named Layer Selection` node as well as boolean modifier inputs that are marked as a `Layer Selection`. The layer selection UI is slightly updated: * Use a slightly larger default width for the `Named Layer Selection` node. * Use the layer icon in the field that search for layer names. * Use `Layer` placeholder string Pull Request: https://projects.blender.org/blender/blender/pulls/137273
2025-04-18 12:35:49 +02:00
struct SocketSearchData {
Fix part of T89313: Attribute search crash during animation playback During animation playback, data-blocks are reallocated, so storing pointers to the resulting data is not okay. Instead, the data should be retrieved from the context. This works when the applied search item is the "dummy" item added for non-matches. However, it still crashes for every other item, because the memory is owned by the modifier value log, which has been freed by the time the exec function runs. The next part of the solution is to allow uiSearchItems to own memory for the search items.
2021-11-05 11:19:12 -05:00
uint32_t object_session_uid;
char modifier_name[MAX_NAME];
char socket_identifier[MAX_NAME];
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
bool is_output;
};
/* This class must not have a destructor, since it is used by buttons and freed with #MEM_freeN. */
Geometry Nodes: Add Grease Pencil layer name search This makes it possible to search layer names in the `Named Layer Selection` node as well as boolean modifier inputs that are marked as a `Layer Selection`. The layer selection UI is slightly updated: * Use a slightly larger default width for the `Named Layer Selection` node. * Use the layer icon in the field that search for layer names. * Use `Layer` placeholder string Pull Request: https://projects.blender.org/blender/blender/pulls/137273
2025-04-18 12:35:49 +02:00
BLI_STATIC_ASSERT(std::is_trivially_destructible_v<SocketSearchData>, "");
struct DrawGroupInputsContext {
const bContext &C;
NodesModifierData &nmd;
nodes::PropertiesVectorSet properties;
PointerRNA *md_ptr;
PointerRNA *bmain_ptr;
Array<bool> input_usages;
};
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
Fix T89313: Attribute search crash with animation playback rBc473b2ce8bdbf8fa42 improved the situation somewhat, but attribute search still crashes during animation playback, because the UI search data references stale memory. The proper solution is to allow the search to own data rather than just referencing it, but I would prefer not to do that for 3.0. In the meantime, just disable attribute search when animation is playing. Differential Revision: https://developer.blender.org/D13179
2021-11-10 15:43:18 -06:00
static NodesModifierData *get_modifier_data(Main &bmain,
const wmWindowManager &wm,
Geometry Nodes: Add Grease Pencil layer name search This makes it possible to search layer names in the `Named Layer Selection` node as well as boolean modifier inputs that are marked as a `Layer Selection`. The layer selection UI is slightly updated: * Use a slightly larger default width for the `Named Layer Selection` node. * Use the layer icon in the field that search for layer names. * Use `Layer` placeholder string Pull Request: https://projects.blender.org/blender/blender/pulls/137273
2025-04-18 12:35:49 +02:00
const SocketSearchData &data)
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
{
Fix T89313: Attribute search crash with animation playback rBc473b2ce8bdbf8fa42 improved the situation somewhat, but attribute search still crashes during animation playback, because the UI search data references stale memory. The proper solution is to allow the search to own data rather than just referencing it, but I would prefer not to do that for 3.0. In the meantime, just disable attribute search when animation is playing. Differential Revision: https://developer.blender.org/D13179
2021-11-10 15:43:18 -06:00
if (ED_screen_animation_playing(&wm)) {
/* Work around an issue where the attribute search exec function has stale pointers when data
* is reallocated when evaluating the node tree, causing a crash. This would be solved by
* allowing the UI search data to own arbitrary memory rather than just referencing it. */
return nullptr;
}
Core: rename Session UUID to Session UID `UUID` generally stands for "universally unique identifier". The session identifier that we use is neither universally unique, nor does it follow the standard. Therefor, the term "session uuid" is confusing and should be replaced. In #116888 we briefly talked about a better name and ended up with "session uid". The reason for "uid" instead of "id" is that the latter is a very overloaded term in Blender already. This patch changes all uses of "uuid" to "uid" where it's used in the context of a "session uid". It's not always trivial to see whether a specific mention of "uuid" refers to an actual uuid or something else. Therefore, I might have missed some renames. I can't think of an automated way to differentiate the case. BMesh also uses the term "uuid" sometimes in a the wrong context (e.g. `UUIDFaceStepItem`) but there it also does not mean "session uid", so it's *not* changed by this patch. Pull Request: https://projects.blender.org/blender/blender/pulls/117350
2024-01-22 13:47:13 +01:00
const Object *object = (Object *)BKE_libblock_find_session_uid(
Fix part of T89313: Attribute search crash during animation playback During animation playback, data-blocks are reallocated, so storing pointers to the resulting data is not okay. Instead, the data should be retrieved from the context. This works when the applied search item is the "dummy" item added for non-matches. However, it still crashes for every other item, because the memory is owned by the modifier value log, which has been freed by the time the exec function runs. The next part of the solution is to allow uiSearchItems to own memory for the search items.
2021-11-05 11:19:12 -05:00
&bmain, ID_OB, data.object_session_uid);
if (object == nullptr) {
return nullptr;
}
ModifierData *md = BKE_modifiers_findby_name(object, data.modifier_name);
if (md == nullptr) {
return nullptr;
}
BLI_assert(md->type == eModifierType_Nodes);
return reinterpret_cast<NodesModifierData *>(md);
}
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
static geo_log::GeoTreeLog *get_root_tree_log(const NodesModifierData &nmd)
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
{
Geometry Nodes: add run-time data to geometry nodes modifier This adds a single run-time field and moves the existing run-time data into a new struct. This approach makes it much easier to add new run-time data. Pull Request: https://projects.blender.org/blender/blender/pulls/109905
2023-07-11 12:55:57 +02:00
if (!nmd.runtime->eval_log) {
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
return nullptr;
}
Refactor: Geometry Nodes: store tree identifier in tree logger The main goal here is to add `GeoTreeLogger.tree_orig_session_uid`. Previously, it was always possible to derive this information in `ensure_node_warnings`. However, with closures that's not possible in general anymore, because the Evaluate Closure node does not know statically which node tree the closure zone is from that it evaluates. Therefore, this information has to be logged as well. This patch initializes `tree_orig_session_uid` the same way it initializes `parent_node_id`, by scanning the compute context when creating the tree logger. To make this work properly, some extra contextual data had to be stored in some compute contexts. This is just a refactor with no expected functional changes. Node warnings for closures are still not properly logged, because that requires storing source-location data in closures, which will be implemented separately. Pull Request: https://projects.blender.org/blender/blender/pulls/137208
2025-04-10 08:56:02 +02:00
bke::ModifierComputeContext compute_context{nullptr, nmd};
Geometry Nodes: add run-time data to geometry nodes modifier This adds a single run-time field and moves the existing run-time data into a new struct. This approach makes it much easier to add new run-time data. Pull Request: https://projects.blender.org/blender/blender/pulls/109905
2023-07-11 12:55:57 +02:00
return &nmd.runtime->eval_log->get_tree_log(compute_context.hash());
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
}
Fix part of T89313: Attribute search crash during animation playback During animation playback, data-blocks are reallocated, so storing pointers to the resulting data is not okay. Instead, the data should be retrieved from the context. This works when the applied search item is the "dummy" item added for non-matches. However, it still crashes for every other item, because the memory is owned by the modifier value log, which has been freed by the time the exec function runs. The next part of the solution is to allow uiSearchItems to own memory for the search items.
2021-11-05 11:19:12 -05:00
static void attribute_search_update_fn(
const bContext *C, void *arg, const char *str, uiSearchItems *items, const bool is_first)
{
Geometry Nodes: Add Grease Pencil layer name search This makes it possible to search layer names in the `Named Layer Selection` node as well as boolean modifier inputs that are marked as a `Layer Selection`. The layer selection UI is slightly updated: * Use a slightly larger default width for the `Named Layer Selection` node. * Use the layer icon in the field that search for layer names. * Use `Layer` placeholder string Pull Request: https://projects.blender.org/blender/blender/pulls/137273
2025-04-18 12:35:49 +02:00
SocketSearchData &data = *static_cast<SocketSearchData *>(arg);
Fix T89313: Attribute search crash with animation playback rBc473b2ce8bdbf8fa42 improved the situation somewhat, but attribute search still crashes during animation playback, because the UI search data references stale memory. The proper solution is to allow the search to own data rather than just referencing it, but I would prefer not to do that for 3.0. In the meantime, just disable attribute search when animation is playing. Differential Revision: https://developer.blender.org/D13179
2021-11-10 15:43:18 -06:00
const NodesModifierData *nmd = get_modifier_data(*CTX_data_main(C), *CTX_wm_manager(C), data);
Fix part of T89313: Attribute search crash during animation playback During animation playback, data-blocks are reallocated, so storing pointers to the resulting data is not okay. Instead, the data should be retrieved from the context. This works when the applied search item is the "dummy" item added for non-matches. However, it still crashes for every other item, because the memory is owned by the modifier value log, which has been freed by the time the exec function runs. The next part of the solution is to allow uiSearchItems to own memory for the search items.
2021-11-05 11:19:12 -05:00
if (nmd == nullptr) {
return;
}
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
if (nmd->node_group == nullptr) {
Fix part of T89313: Attribute search crash during animation playback During animation playback, data-blocks are reallocated, so storing pointers to the resulting data is not okay. Instead, the data should be retrieved from the context. This works when the applied search item is the "dummy" item added for non-matches. However, it still crashes for every other item, because the memory is owned by the modifier value log, which has been freed by the time the exec function runs. The next part of the solution is to allow uiSearchItems to own memory for the search items.
2021-11-05 11:19:12 -05:00
return;
}
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
geo_log::GeoTreeLog *tree_log = get_root_tree_log(*nmd);
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
if (tree_log == nullptr) {
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
return;
}
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
tree_log->ensure_existing_attributes();
nmd->node_group->ensure_topology_cache();
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
Vector<const bNodeSocket *> sockets_to_check;
if (data.is_output) {
for (const bNode *node : nmd->node_group->nodes_by_type("NodeGroupOutput")) {
for (const bNodeSocket *socket : node->input_sockets()) {
if (socket->type == SOCK_GEOMETRY) {
sockets_to_check.append(socket);
}
}
}
}
else {
Cleanup: add utility method to get group input nodes
2022-12-13 17:25:37 +01:00
for (const bNode *node : nmd->node_group->group_input_nodes()) {
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
for (const bNodeSocket *socket : node->output_sockets()) {
if (socket->type == SOCK_GEOMETRY) {
sockets_to_check.append(socket);
}
}
}
}
Set<StringRef> names;
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
Vector<const geo_log::GeometryAttributeInfo *> attributes;
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
for (const bNodeSocket *socket : sockets_to_check) {
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
const geo_log::ValueLog *value_log = tree_log->find_socket_value_log(*socket);
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
if (value_log == nullptr) {
continue;
}
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
if (const auto *geo_log = dynamic_cast<const geo_log::GeometryInfoLog *>(value_log)) {
for (const geo_log::GeometryAttributeInfo &attribute : geo_log->attributes) {
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
if (names.add(attribute.name)) {
attributes.append(&attribute);
}
}
}
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
}
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
ui::attribute_search_add_items(str, data.is_output, attributes.as_span(), items, is_first);
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
}
static void attribute_search_exec_fn(bContext *C, void *data_v, void *item_v)
{
if (item_v == nullptr) {
return;
}
Geometry Nodes: Add Grease Pencil layer name search This makes it possible to search layer names in the `Named Layer Selection` node as well as boolean modifier inputs that are marked as a `Layer Selection`. The layer selection UI is slightly updated: * Use a slightly larger default width for the `Named Layer Selection` node. * Use the layer icon in the field that search for layer names. * Use `Layer` placeholder string Pull Request: https://projects.blender.org/blender/blender/pulls/137273
2025-04-18 12:35:49 +02:00
SocketSearchData &data = *static_cast<SocketSearchData *>(data_v);
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
const auto &item = *static_cast<const geo_log::GeometryAttributeInfo *>(item_v);
Fix T89313: Attribute search crash with animation playback rBc473b2ce8bdbf8fa42 improved the situation somewhat, but attribute search still crashes during animation playback, because the UI search data references stale memory. The proper solution is to allow the search to own data rather than just referencing it, but I would prefer not to do that for 3.0. In the meantime, just disable attribute search when animation is playing. Differential Revision: https://developer.blender.org/D13179
2021-11-10 15:43:18 -06:00
const NodesModifierData *nmd = get_modifier_data(*CTX_data_main(C), *CTX_wm_manager(C), data);
Fix part of T89313: Attribute search crash during animation playback During animation playback, data-blocks are reallocated, so storing pointers to the resulting data is not okay. Instead, the data should be retrieved from the context. This works when the applied search item is the "dummy" item added for non-matches. However, it still crashes for every other item, because the memory is owned by the modifier value log, which has been freed by the time the exec function runs. The next part of the solution is to allow uiSearchItems to own memory for the search items.
2021-11-05 11:19:12 -05:00
if (nmd == nullptr) {
return;
}
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
const std::string attribute_prop_name = data.socket_identifier +
Cleanup: Use constexpr for geometry nodes string, avoid .c_str()
2024-12-04 12:12:29 -05:00
nodes::input_attribute_name_suffix;
Fix part of T89313: Attribute search crash during animation playback During animation playback, data-blocks are reallocated, so storing pointers to the resulting data is not okay. Instead, the data should be retrieved from the context. This works when the applied search item is the "dummy" item added for non-matches. However, it still crashes for every other item, because the memory is owned by the modifier value log, which has been freed by the time the exec function runs. The next part of the solution is to allow uiSearchItems to own memory for the search items.
2021-11-05 11:19:12 -05:00
IDProperty &name_property = *IDP_GetPropertyFromGroup(nmd->settings.properties,
Cleanup: Use constexpr for geometry nodes string, avoid .c_str()
2024-12-04 12:12:29 -05:00
attribute_prop_name);
BKE_idprop: string size argument consistency, fix off by one errors The length passed to IDP_NewString included the nil terminator unlike IDP_AssignString. Callers to IDP_AssignString from MOD_nodes.cc passed in an invalid size for e.g. There where also callers passing in the strlen(..) of the value unnecessarily. Resolve with the following changes: - Add `*MaxSize()` versions of IDP_AssignString & IDP_NewString which take a size argument. - Remove the size argument from the existing functions as most callers don't need to clamp the length of the string, avoid calculating & passing in length values when they're unnecessary. - When clamping the size is needed, both functions now include the nil byte in the size since this is the convention for BLI_string and other BLI API's dealing with nil terminated strings, it avoids having to pass in `sizeof(value) - 1`.
2023-05-02 15:07:55 +10:00
IDP_AssignString(&name_property, item.name.c_str());
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
ED_undo_push(C, "Assign Attribute Name");
}
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
static void add_attribute_search_button(DrawGroupInputsContext &ctx,
Fix part of T89313: Attribute search crash during animation playback During animation playback, data-blocks are reallocated, so storing pointers to the resulting data is not okay. Instead, the data should be retrieved from the context. This works when the applied search item is the "dummy" item added for non-matches. However, it still crashes for every other item, because the memory is owned by the modifier value log, which has been freed by the time the exec function runs. The next part of the solution is to allow uiSearchItems to own memory for the search items.
2021-11-05 11:19:12 -05:00
uiLayout *layout,
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
const StringRefNull rna_path_attribute_name,
Nodes: Panels integration with blend files and UI Part 3/3 of #109135, #110272 Switch to new node group interfaces and deprecate old DNA and API. This completes support for panels in node drawing and in node group interface declarations in particular. The new node group interface DNA and RNA code has been added in parts 1 and 2 (#110885, #110952) but has not be enabled yet. This commit completes the integration by * enabling the new RNA API * using the new API in UI * read/write new interfaces from blend files * add versioning for backward compatibility * add forward-compatible writing code to reconstruct old interfaces All places accessing node group interface declarations should now be using the new API. A runtime cache has been added that allows simple linear access to socket inputs and outputs even when a panel hierarchy is used. Old DNA has been deprecated and should only be accessed for versioning (inputs/outputs renamed to inputs_legacy/outputs_legacy to catch errors). Versioning code ensures both backward and forward compatibility of existing files. The API for old interfaces is removed. The new API is very similar but is defined on the `ntree.interface` instead of the `ntree` directly. Breaking change notifications and detailed instructions for migrating will be added. A python test has been added for the node group API functions. This includes new functionality such as creating panels and moving items between different levels. This patch does not yet contain panel representations in the modifier UI. This has been tested in a separate branch and will be added with a later PR (#108565). Pull Request: https://projects.blender.org/blender/blender/pulls/111348
2023-08-30 12:37:21 +02:00
const bNodeTreeInterfaceSocket &socket,
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
const bool is_output)
{
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
if (!ctx.nmd.runtime->eval_log) {
Refactor: UI: Replace uiItemR with class method uiLayout::prop This converts the public `uiItemR` function to an object oriented API (`uiLayout::prop`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138617
2025-05-08 20:45:37 +02:00
layout->prop(ctx.md_ptr, rna_path_attribute_name, UI_ITEM_NONE, "", ICON_NONE);
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
return;
}
uiBlock *block = uiLayoutGetBlock(layout);
uiBut *but = uiDefIconTextButR(block,
UI_BTYPE_SEARCH_MENU,
0,
ICON_NONE,
"",
0,
0,
10 * UI_UNIT_X, /* Dummy value, replaced by layout system. */
UI_UNIT_Y,
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
ctx.md_ptr,
Cleanup: Use StringRef and std::optional for UI string arguments - Gives O(1) access to string length in more cases - Convenient string manipulation functions - Clarify difference between "no string" and "empty string" - Avoid the need for raw pointers in the API - Shows which API string arguments are optional Pull Request: https://projects.blender.org/blender/blender/pulls/131473
2024-12-06 14:08:10 +01:00
rna_path_attribute_name,
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
0,
0.0f,
0.0f,
Cleanup: Use StringRef for uiBut tooltips And replace nullptr arguments for tooltips in UI button creation functions with std::nullopt. Though the distinction between "no tooltip" and "empty tooltip" doesn't seem to exist, it seems safer to keep the distinction since it existed with null before.
2025-02-14 15:12:48 -05:00
StringRef(socket.description));
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
const Object *object = ed::object::context_object(&ctx.C);
Fix part of T89313: Attribute search crash during animation playback During animation playback, data-blocks are reallocated, so storing pointers to the resulting data is not okay. Instead, the data should be retrieved from the context. This works when the applied search item is the "dummy" item added for non-matches. However, it still crashes for every other item, because the memory is owned by the modifier value log, which has been freed by the time the exec function runs. The next part of the solution is to allow uiSearchItems to own memory for the search items.
2021-11-05 11:19:12 -05:00
BLI_assert(object != nullptr);
if (object == nullptr) {
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
return;
}
Geometry Nodes: Add Grease Pencil layer name search This makes it possible to search layer names in the `Named Layer Selection` node as well as boolean modifier inputs that are marked as a `Layer Selection`. The layer selection UI is slightly updated: * Use a slightly larger default width for the `Named Layer Selection` node. * Use the layer icon in the field that search for layer names. * Use `Layer` placeholder string Pull Request: https://projects.blender.org/blender/blender/pulls/137273
2025-04-18 12:35:49 +02:00
SocketSearchData *data = MEM_callocN<SocketSearchData>(__func__);
Core: rename Session UUID to Session UID `UUID` generally stands for "universally unique identifier". The session identifier that we use is neither universally unique, nor does it follow the standard. Therefor, the term "session uuid" is confusing and should be replaced. In #116888 we briefly talked about a better name and ended up with "session uid". The reason for "uid" instead of "id" is that the latter is a very overloaded term in Blender already. This patch changes all uses of "uuid" to "uid" where it's used in the context of a "session uid". It's not always trivial to see whether a specific mention of "uuid" refers to an actual uuid or something else. Therefore, I might have missed some renames. I can't think of an automated way to differentiate the case. BMesh also uses the term "uuid" sometimes in a the wrong context (e.g. `UUIDFaceStepItem`) but there it also does not mean "session uid", so it's *not* changed by this patch. Pull Request: https://projects.blender.org/blender/blender/pulls/117350
2024-01-22 13:47:13 +01:00
data->object_session_uid = object->id.session_uid;
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
STRNCPY(data->modifier_name, ctx.nmd.modifier.name);
Fix part of T89313: Attribute search crash during animation playback During animation playback, data-blocks are reallocated, so storing pointers to the resulting data is not okay. Instead, the data should be retrieved from the context. This works when the applied search item is the "dummy" item added for non-matches. However, it still crashes for every other item, because the memory is owned by the modifier value log, which has been freed by the time the exec function runs. The next part of the solution is to allow uiSearchItems to own memory for the search items.
2021-11-05 11:19:12 -05:00
STRNCPY(data->socket_identifier, socket.identifier);
data->is_output = is_output;
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
UI_but_func_search_set_results_are_suggestions(but, true);
UI_but_func_search_set_sep_string(but, UI_MENU_ARROW_SEP);
UI_but_func_search_set(but,
nullptr,
attribute_search_update_fn,
static_cast<void *>(data),
true,
nullptr,
attribute_search_exec_fn,
nullptr);
Geometry Nodes: Don't allow UI attributes as modifier field inputs This is an extension of 4669178fc3786e1, applying the same changes to attributes chosen in the field inputs of the geometry nodes modifier. If a UI/internal attribute is used, the attribute name button will have a red alert. Adding a disabled hint is currently a bit more complex. Also hide UI attributes in attribute search for the named attribute node. Part of D14934
2022-05-31 18:52:27 +02:00
char *attribute_name = RNA_string_get_alloc(
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
ctx.md_ptr, rna_path_attribute_name.c_str(), nullptr, 0, nullptr);
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
const bool access_allowed = bke::allow_procedural_attribute_access(attribute_name);
Geometry Nodes: Don't allow UI attributes as modifier field inputs This is an extension of 4669178fc3786e1, applying the same changes to attributes chosen in the field inputs of the geometry nodes modifier. If a UI/internal attribute is used, the attribute name button will have a red alert. Adding a disabled hint is currently a bit more complex. Also hide UI attributes in attribute search for the named attribute node. Part of D14934
2022-05-31 18:52:27 +02:00
MEM_freeN(attribute_name);
if (!access_allowed) {
UI_but_flag_enable(but, UI_BUT_REDALERT);
}
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
}
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
static void add_attribute_search_or_value_buttons(DrawGroupInputsContext &ctx,
Fix part of T89313: Attribute search crash during animation playback During animation playback, data-blocks are reallocated, so storing pointers to the resulting data is not okay. Instead, the data should be retrieved from the context. This works when the applied search item is the "dummy" item added for non-matches. However, it still crashes for every other item, because the memory is owned by the modifier value log, which has been freed by the time the exec function runs. The next part of the solution is to allow uiSearchItems to own memory for the search items.
2021-11-05 11:19:12 -05:00
uiLayout *layout,
Cleanup: Avoid reformatting geometry nodes property names, use fmt
2024-12-04 12:37:54 -05:00
const StringRef socket_id_esc,
const StringRefNull rna_path,
Nodes: Panels integration with blend files and UI Part 3/3 of #109135, #110272 Switch to new node group interfaces and deprecate old DNA and API. This completes support for panels in node drawing and in node group interface declarations in particular. The new node group interface DNA and RNA code has been added in parts 1 and 2 (#110885, #110952) but has not be enabled yet. This commit completes the integration by * enabling the new RNA API * using the new API in UI * read/write new interfaces from blend files * add versioning for backward compatibility * add forward-compatible writing code to reconstruct old interfaces All places accessing node group interface declarations should now be using the new API. A runtime cache has been added that allows simple linear access to socket inputs and outputs even when a panel hierarchy is used. Old DNA has been deprecated and should only be accessed for versioning (inputs/outputs renamed to inputs_legacy/outputs_legacy to catch errors). Versioning code ensures both backward and forward compatibility of existing files. The API for old interfaces is removed. The new API is very similar but is defined on the `ntree.interface` instead of the `ntree` directly. Breaking change notifications and detailed instructions for migrating will be added. A python test has been added for the node group API functions. This includes new functionality such as creating panels and moving items between different levels. This patch does not yet contain panel representations in the modifier UI. This has been tested in a separate branch and will be added with a later PR (#108565). Pull Request: https://projects.blender.org/blender/blender/pulls/111348
2023-08-30 12:37:21 +02:00
const bNodeTreeInterfaceSocket &socket)
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
{
Cleanup: Move BKE_node to namespace Move all header file into namespace. Unnecessary namespaces was removed from implementations file. Part of forward declarations in header was moved in the top part of file just to do not have a lot of separate namespaces. Pull Request: https://projects.blender.org/blender/blender/pulls/121637
2024-05-13 16:07:12 +02:00
const bke::bNodeSocketType *typeinfo = socket.socket_typeinfo();
Nodes: Panels integration with blend files and UI Part 3/3 of #109135, #110272 Switch to new node group interfaces and deprecate old DNA and API. This completes support for panels in node drawing and in node group interface declarations in particular. The new node group interface DNA and RNA code has been added in parts 1 and 2 (#110885, #110952) but has not be enabled yet. This commit completes the integration by * enabling the new RNA API * using the new API in UI * read/write new interfaces from blend files * add versioning for backward compatibility * add forward-compatible writing code to reconstruct old interfaces All places accessing node group interface declarations should now be using the new API. A runtime cache has been added that allows simple linear access to socket inputs and outputs even when a panel hierarchy is used. Old DNA has been deprecated and should only be accessed for versioning (inputs/outputs renamed to inputs_legacy/outputs_legacy to catch errors). Versioning code ensures both backward and forward compatibility of existing files. The API for old interfaces is removed. The new API is very similar but is defined on the `ntree.interface` instead of the `ntree` directly. Breaking change notifications and detailed instructions for migrating will be added. A python test has been added for the node group API functions. This includes new functionality such as creating panels and moving items between different levels. This patch does not yet contain panel representations in the modifier UI. This has been tested in a separate branch and will be added with a later PR (#108565). Pull Request: https://projects.blender.org/blender/blender/pulls/111348
2023-08-30 12:37:21 +02:00
const eNodeSocketDatatype type = typeinfo ? eNodeSocketDatatype(typeinfo->type) : SOCK_CUSTOM;
Cleanup: Avoid reformatting geometry nodes property names, use fmt
2024-12-04 12:37:54 -05:00
const std::string rna_path_attribute_name = fmt::format(
"[\"{}{}\"]", socket_id_esc, nodes::input_attribute_name_suffix);
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
Geometry Nodes: Fix alignment of exposed properties in the modifier The spacing and alignment of the properties in the geometry nodes modifier could vary depending on the type of the socket or whether the input can accept attributes. Wrapping each property in its own `row` layout allows us to make the spacing and alignment between them consistent. Reviewed By: Hans Goudey Differential Revision: http://developer.blender.org/D16417
2022-11-08 19:09:28 +01:00
/* We're handling this manually in this case. */
uiLayoutSetPropDecorate(layout, false);
Refactor: UI: Replace uiLayoutSplit with class method uiLayout::split This converts the public `uiLayoutSplit` function to an object oriented API (`uiLayout::split`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::split` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Pull Request: https://projects.blender.org/blender/blender/pulls/138361
2025-05-03 20:51:42 +02:00
uiLayout *split = &layout->split(0.4f, false);
Refactor: UI: Replace uiLayoutRow with class method uiLayout::row This converts the public `uiLayoutRow` function to an object oriented API (`uiLayout::row`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::row` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/137979
2025-04-25 19:45:25 +02:00
uiLayout *name_row = &split->row(false);
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
uiLayoutSetAlignment(name_row, UI_LAYOUT_ALIGN_RIGHT);
Geometry Nodes: Adjust modifier UI to put field toggles on the right This also fixes the layout of boolean properties with the field toggle visible. This was discussed in the most recent geometry nodes submodule meeting.
2023-01-20 17:41:34 -06:00
Fix #119557: XYZ labels on vector outputs missing if Single Value is disabled Pull Request: https://projects.blender.org/blender/blender/pulls/132144
2025-01-07 15:48:43 +01:00
uiLayout *prop_row = nullptr;
Geometry Nodes: Improve performance with many inputs Resolves #136183 To avoid quadratic worst case runtime when gathering values from the modifier properties, build a temporary VectorSet of the modifier's IDProperties. In the file from #136183, this change improves playback performance by 1.4x for me, from 50 to 70ms. Ideally IDProperty groups would have constant time lookup on their own, but that's a much larger change, and this smaller change for just Geometry Nodes is not so invasive. Pull Request: https://projects.blender.org/blender/blender/pulls/136463
2025-03-25 15:40:32 +01:00
const std::optional<StringRef> attribute_name = nodes::input_attribute_name_get(ctx.properties,
socket);
Nodes: Panels integration with blend files and UI Part 3/3 of #109135, #110272 Switch to new node group interfaces and deprecate old DNA and API. This completes support for panels in node drawing and in node group interface declarations in particular. The new node group interface DNA and RNA code has been added in parts 1 and 2 (#110885, #110952) but has not be enabled yet. This commit completes the integration by * enabling the new RNA API * using the new API in UI * read/write new interfaces from blend files * add versioning for backward compatibility * add forward-compatible writing code to reconstruct old interfaces All places accessing node group interface declarations should now be using the new API. A runtime cache has been added that allows simple linear access to socket inputs and outputs even when a panel hierarchy is used. Old DNA has been deprecated and should only be accessed for versioning (inputs/outputs renamed to inputs_legacy/outputs_legacy to catch errors). Versioning code ensures both backward and forward compatibility of existing files. The API for old interfaces is removed. The new API is very similar but is defined on the `ntree.interface` instead of the `ntree` directly. Breaking change notifications and detailed instructions for migrating will be added. A python test has been added for the node group API functions. This includes new functionality such as creating panels and moving items between different levels. This patch does not yet contain panel representations in the modifier UI. This has been tested in a separate branch and will be added with a later PR (#108565). Pull Request: https://projects.blender.org/blender/blender/pulls/111348
2023-08-30 12:37:21 +02:00
if (type == SOCK_BOOLEAN && !attribute_name) {
Refactor: UI: Replace uiItemL with class method uiLayout::label This converts the public `uiItemL` function to an object oriented API (`uiLayout::label`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138608
2025-05-08 17:21:08 +02:00
name_row->label("", ICON_NONE);
Refactor: UI: Replace uiLayoutRow with class method uiLayout::row This converts the public `uiLayoutRow` function to an object oriented API (`uiLayout::row`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::row` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/137979
2025-04-25 19:45:25 +02:00
prop_row = &split->row(true);
Geometry Nodes: Use checkbox for exposed boolean sockets This uses the changes from ef68a37e5d55e17adf4c to create IDProperties for exposed boolean sockets with a boolean type instead of an integer with a [0,1] range. Existing properties and values are converted automatically. For forward compatibility, the properties are switched to the integer type for saving. Otherwise older versions crash immediately when opening a newer file. The "Use Attribute" IDProperties aren't changed here, since that wouldn't have a visible benefit. Differential Revision: https://developer.blender.org/D12816
2023-01-20 17:36:07 -06:00
}
else {
Refactor: UI: Replace uiLayoutRow with class method uiLayout::row This converts the public `uiLayoutRow` function to an object oriented API (`uiLayout::row`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::row` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/137979
2025-04-25 19:45:25 +02:00
prop_row = &layout->row(true);
Geometry Nodes: Use checkbox for exposed boolean sockets This uses the changes from ef68a37e5d55e17adf4c to create IDProperties for exposed boolean sockets with a boolean type instead of an integer with a [0,1] range. Existing properties and values are converted automatically. For forward compatibility, the properties are switched to the integer type for saving. Otherwise older versions crash immediately when opening a newer file. The "Use Attribute" IDProperties aren't changed here, since that wouldn't have a visible benefit. Differential Revision: https://developer.blender.org/D12816
2023-01-20 17:36:07 -06:00
}
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
Nodes: Panels integration with blend files and UI Part 3/3 of #109135, #110272 Switch to new node group interfaces and deprecate old DNA and API. This completes support for panels in node drawing and in node group interface declarations in particular. The new node group interface DNA and RNA code has been added in parts 1 and 2 (#110885, #110952) but has not be enabled yet. This commit completes the integration by * enabling the new RNA API * using the new API in UI * read/write new interfaces from blend files * add versioning for backward compatibility * add forward-compatible writing code to reconstruct old interfaces All places accessing node group interface declarations should now be using the new API. A runtime cache has been added that allows simple linear access to socket inputs and outputs even when a panel hierarchy is used. Old DNA has been deprecated and should only be accessed for versioning (inputs/outputs renamed to inputs_legacy/outputs_legacy to catch errors). Versioning code ensures both backward and forward compatibility of existing files. The API for old interfaces is removed. The new API is very similar but is defined on the `ntree.interface` instead of the `ntree` directly. Breaking change notifications and detailed instructions for migrating will be added. A python test has been added for the node group API functions. This includes new functionality such as creating panels and moving items between different levels. This patch does not yet contain panel representations in the modifier UI. This has been tested in a separate branch and will be added with a later PR (#108565). Pull Request: https://projects.blender.org/blender/blender/pulls/111348
2023-08-30 12:37:21 +02:00
if (type == SOCK_BOOLEAN) {
Geometry Nodes: Adjust modifier UI to put field toggles on the right This also fixes the layout of boolean properties with the field toggle visible. This was discussed in the most recent geometry nodes submodule meeting.
2023-01-20 17:41:34 -06:00
uiLayoutSetPropSep(prop_row, false);
uiLayoutSetAlignment(prop_row, UI_LAYOUT_ALIGN_EXPAND);
}
Fix #110516: Geometry nodes use attribute toggle boolean values broken The toggle was added before boolean IDProperties were added. The fix is to support both integer types and boolean types, similar to a recent change for other inputs, 9f30555faf92117fe9c8. Pull Request: https://projects.blender.org/blender/blender/pulls/111433
2023-08-24 13:36:25 +02:00
if (attribute_name) {
Refactor: UI: Replace uiItemL with class method uiLayout::label This converts the public `uiItemL` function to an object oriented API (`uiLayout::label`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138608
2025-05-08 17:21:08 +02:00
name_row->label(socket.name ? IFACE_(socket.name) : "", ICON_NONE);
Refactor: UI: Replace uiLayoutRow with class method uiLayout::row This converts the public `uiLayoutRow` function to an object oriented API (`uiLayout::row`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::row` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/137979
2025-04-25 19:45:25 +02:00
prop_row = &split->row(true);
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
add_attribute_search_button(ctx, prop_row, rna_path_attribute_name, socket, false);
Refactor: UI: Replace uiItemL with class method uiLayout::label This converts the public `uiItemL` function to an object oriented API (`uiLayout::label`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138608
2025-05-08 17:21:08 +02:00
layout->label("", ICON_BLANK1);
Geometry Nodes: Adjust modifier UI to put field toggles on the right This also fixes the layout of boolean properties with the field toggle visible. This was discussed in the most recent geometry nodes submodule meeting.
2023-01-20 17:41:34 -06:00
}
else {
Fix #119557: XYZ labels on vector outputs missing if Single Value is disabled Pull Request: https://projects.blender.org/blender/blender/pulls/132144
2025-01-07 15:48:43 +01:00
const char *name = socket.name ? IFACE_(socket.name) : "";
Refactor: UI: Replace uiItemR with class method uiLayout::prop This converts the public `uiItemR` function to an object oriented API (`uiLayout::prop`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138617
2025-05-08 20:45:37 +02:00
prop_row->prop(ctx.md_ptr, rna_path, UI_ITEM_NONE, name, ICON_NONE);
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
uiItemDecoratorR(layout, ctx.md_ptr, rna_path.c_str(), -1);
Geometry Nodes: Use checkbox for exposed boolean sockets This uses the changes from ef68a37e5d55e17adf4c to create IDProperties for exposed boolean sockets with a boolean type instead of an integer with a [0,1] range. Existing properties and values are converted automatically. For forward compatibility, the properties are switched to the integer type for saving. Otherwise older versions crash immediately when opening a newer file. The "Use Attribute" IDProperties aren't changed here, since that wouldn't have a visible benefit. Differential Revision: https://developer.blender.org/D12816
2023-01-20 17:36:07 -06:00
}
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
PointerRNA props;
Geometry Nodes: Fix alignment of exposed properties in the modifier The spacing and alignment of the properties in the geometry nodes modifier could vary depending on the type of the socket or whether the input can accept attributes. Wrapping each property in its own `row` layout allows us to make the spacing and alignment between them consistent. Reviewed By: Hans Goudey Differential Revision: http://developer.blender.org/D16417
2022-11-08 19:09:28 +01:00
uiItemFullO(prop_row,
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
"object.geometry_nodes_input_attribute_toggle",
"",
ICON_SPREADSHEET,
nullptr,
WM_OP_INVOKE_DEFAULT,
Cleanup: use typed enum for UI_ITEM_* flags Using an int lead to confusion with other flags often used with buttons. For e.g. these flags could be easily confused with uiItem::flag.
2023-07-29 15:06:33 +10:00
UI_ITEM_NONE,
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
&props);
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
RNA_string_set(&props, "modifier_name", ctx.nmd.modifier.name);
Fix #110516: Geometry nodes use attribute toggle boolean values broken The toggle was added before boolean IDProperties were added. The fix is to support both integer types and boolean types, similar to a recent change for other inputs, 9f30555faf92117fe9c8. Pull Request: https://projects.blender.org/blender/blender/pulls/111433
2023-08-24 13:36:25 +02:00
RNA_string_set(&props, "input_name", socket.identifier);
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
}
Geometry Nodes: Add Grease Pencil layer name search This makes it possible to search layer names in the `Named Layer Selection` node as well as boolean modifier inputs that are marked as a `Layer Selection`. The layer selection UI is slightly updated: * Use a slightly larger default width for the `Named Layer Selection` node. * Use the layer icon in the field that search for layer names. * Use `Layer` placeholder string Pull Request: https://projects.blender.org/blender/blender/pulls/137273
2025-04-18 12:35:49 +02:00
static void layer_name_search_update_fn(
const bContext *C, void *arg, const char *str, uiSearchItems *items, const bool is_first)
{
const SocketSearchData &data = *static_cast<SocketSearchData *>(arg);
const NodesModifierData *nmd = get_modifier_data(*CTX_data_main(C), *CTX_wm_manager(C), data);
if (nmd == nullptr) {
return;
}
if (nmd->node_group == nullptr) {
return;
}
geo_log::GeoTreeLog *tree_log = get_root_tree_log(*nmd);
if (tree_log == nullptr) {
return;
}
tree_log->ensure_layer_names();
nmd->node_group->ensure_topology_cache();
Vector<const bNodeSocket *> sockets_to_check;
for (const bNode *node : nmd->node_group->group_input_nodes()) {
for (const bNodeSocket *socket : node->output_sockets()) {
if (socket->type == SOCK_GEOMETRY) {
sockets_to_check.append(socket);
}
}
}
Set<StringRef> names;
Vector<const std::string *> layer_names;
for (const bNodeSocket *socket : sockets_to_check) {
const geo_log::ValueLog *value_log = tree_log->find_socket_value_log(*socket);
if (value_log == nullptr) {
continue;
}
if (const auto *geo_log = dynamic_cast<const geo_log::GeometryInfoLog *>(value_log)) {
if (const std::optional<geo_log::GeometryInfoLog::GreasePencilInfo> &grease_pencil_info =
geo_log->grease_pencil_info)
{
for (const std::string &name : grease_pencil_info->layer_names) {
if (names.add(name)) {
layer_names.append(&name);
}
}
}
}
}
BLI_assert(items);
ui::grease_pencil_layer_search_add_items(str, layer_names.as_span(), *items, is_first);
}
static void layer_name_search_exec_fn(bContext *C, void *data_v, void *item_v)
{
const SocketSearchData &data = *static_cast<SocketSearchData *>(data_v);
const std::string *item = static_cast<std::string *>(item_v);
if (item == nullptr) {
return;
}
const NodesModifierData *nmd = get_modifier_data(*CTX_data_main(C), *CTX_wm_manager(C), data);
if (nmd == nullptr) {
return;
}
IDProperty &name_property = *IDP_GetPropertyFromGroup(nmd->settings.properties,
data.socket_identifier);
IDP_AssignString(&name_property, item->c_str());
ED_undo_push(C, "Assign Layer Name");
}
static void add_layer_name_search_button(DrawGroupInputsContext &ctx,
uiLayout *layout,
const StringRefNull socket_id_esc,
const bNodeTreeInterfaceSocket &socket)
{
const std::string rna_path = fmt::format("[\"{}\"]", socket_id_esc);
if (!ctx.nmd.runtime->eval_log) {
Refactor: UI: Replace uiItemR with class method uiLayout::prop This converts the public `uiItemR` function to an object oriented API (`uiLayout::prop`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138617
2025-05-08 20:45:37 +02:00
layout->prop(ctx.md_ptr, rna_path, UI_ITEM_NONE, "", ICON_NONE);
Geometry Nodes: Add Grease Pencil layer name search This makes it possible to search layer names in the `Named Layer Selection` node as well as boolean modifier inputs that are marked as a `Layer Selection`. The layer selection UI is slightly updated: * Use a slightly larger default width for the `Named Layer Selection` node. * Use the layer icon in the field that search for layer names. * Use `Layer` placeholder string Pull Request: https://projects.blender.org/blender/blender/pulls/137273
2025-04-18 12:35:49 +02:00
return;
}
uiLayoutSetPropDecorate(layout, false);
Refactor: UI: Replace uiLayoutSplit with class method uiLayout::split This converts the public `uiLayoutSplit` function to an object oriented API (`uiLayout::split`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::split` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Pull Request: https://projects.blender.org/blender/blender/pulls/138361
2025-05-03 20:51:42 +02:00
uiLayout *split = &layout->split(0.4f, false);
Refactor: UI: Replace uiLayoutRow with class method uiLayout::row This converts the public `uiLayoutRow` function to an object oriented API (`uiLayout::row`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::row` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/137979
2025-04-25 19:45:25 +02:00
uiLayout *name_row = &split->row(false);
Geometry Nodes: Add Grease Pencil layer name search This makes it possible to search layer names in the `Named Layer Selection` node as well as boolean modifier inputs that are marked as a `Layer Selection`. The layer selection UI is slightly updated: * Use a slightly larger default width for the `Named Layer Selection` node. * Use the layer icon in the field that search for layer names. * Use `Layer` placeholder string Pull Request: https://projects.blender.org/blender/blender/pulls/137273
2025-04-18 12:35:49 +02:00
uiLayoutSetAlignment(name_row, UI_LAYOUT_ALIGN_RIGHT);
Refactor: UI: Replace uiItemL with class method uiLayout::label This converts the public `uiItemL` function to an object oriented API (`uiLayout::label`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138608
2025-05-08 17:21:08 +02:00
name_row->label(socket.name ? IFACE_(socket.name) : "", ICON_NONE);
Refactor: UI: Replace uiLayoutRow with class method uiLayout::row This converts the public `uiLayoutRow` function to an object oriented API (`uiLayout::row`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::row` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/137979
2025-04-25 19:45:25 +02:00
uiLayout *prop_row = &split->row(true);
Geometry Nodes: Add Grease Pencil layer name search This makes it possible to search layer names in the `Named Layer Selection` node as well as boolean modifier inputs that are marked as a `Layer Selection`. The layer selection UI is slightly updated: * Use a slightly larger default width for the `Named Layer Selection` node. * Use the layer icon in the field that search for layer names. * Use `Layer` placeholder string Pull Request: https://projects.blender.org/blender/blender/pulls/137273
2025-04-18 12:35:49 +02:00
uiBlock *block = uiLayoutGetBlock(prop_row);
uiBut *but = uiDefIconTextButR(block,
UI_BTYPE_SEARCH_MENU,
0,
ICON_OUTLINER_DATA_GP_LAYER,
"",
0,
0,
10 * UI_UNIT_X, /* Dummy value, replaced by layout system. */
UI_UNIT_Y,
ctx.md_ptr,
rna_path,
0,
0.0f,
0.0f,
StringRef(socket.description));
UI_but_placeholder_set(but, "Layer");
Refactor: UI: Replace uiItemL with class method uiLayout::label This converts the public `uiItemL` function to an object oriented API (`uiLayout::label`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138608
2025-05-08 17:21:08 +02:00
layout->label("", ICON_BLANK1);
Geometry Nodes: Add Grease Pencil layer name search This makes it possible to search layer names in the `Named Layer Selection` node as well as boolean modifier inputs that are marked as a `Layer Selection`. The layer selection UI is slightly updated: * Use a slightly larger default width for the `Named Layer Selection` node. * Use the layer icon in the field that search for layer names. * Use `Layer` placeholder string Pull Request: https://projects.blender.org/blender/blender/pulls/137273
2025-04-18 12:35:49 +02:00
const Object *object = ed::object::context_object(&ctx.C);
BLI_assert(object != nullptr);
if (object == nullptr) {
return;
}
SocketSearchData *data = MEM_callocN<SocketSearchData>(__func__);
data->object_session_uid = object->id.session_uid;
STRNCPY(data->modifier_name, ctx.nmd.modifier.name);
STRNCPY(data->socket_identifier, socket.identifier);
UI_but_func_search_set_results_are_suggestions(but, true);
UI_but_func_search_set_sep_string(but, UI_MENU_ARROW_SEP);
UI_but_func_search_set(but,
nullptr,
layer_name_search_update_fn,
static_cast<void *>(data),
true,
nullptr,
layer_name_search_exec_fn,
nullptr);
}
Refactor: UI: Replace uiItemR with class method uiLayout::prop This converts the public `uiItemR` function to an object oriented API (`uiLayout::prop`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138617
2025-05-08 20:45:37 +02:00
/* Drawing the properties manually with #uiLayout::prop instead of #uiDefAutoButsRNA allows using
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
* the node socket identifier for the property names, since they are unique, but also having
Cleanup: comment blocks, trailing space in comments
2021-06-24 15:56:58 +10:00
* the correct label displayed in the UI. */
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
static void draw_property_for_socket(DrawGroupInputsContext &ctx,
Fix part of T89313: Attribute search crash during animation playback During animation playback, data-blocks are reallocated, so storing pointers to the resulting data is not okay. Instead, the data should be retrieved from the context. This works when the applied search item is the "dummy" item added for non-matches. However, it still crashes for every other item, because the memory is owned by the modifier value log, which has been freed by the time the exec function runs. The next part of the solution is to allow uiSearchItems to own memory for the search items.
2021-11-05 11:19:12 -05:00
uiLayout *layout,
Fix #116515: Single Value Only applies to wrong input in geometry nodes modifier The counting of input sockets did not take closed panels into account correctly.
2024-01-09 11:01:12 +01:00
const bNodeTreeInterfaceSocket &socket)
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
{
Nodes: Panels integration with blend files and UI Part 3/3 of #109135, #110272 Switch to new node group interfaces and deprecate old DNA and API. This completes support for panels in node drawing and in node group interface declarations in particular. The new node group interface DNA and RNA code has been added in parts 1 and 2 (#110885, #110952) but has not be enabled yet. This commit completes the integration by * enabling the new RNA API * using the new API in UI * read/write new interfaces from blend files * add versioning for backward compatibility * add forward-compatible writing code to reconstruct old interfaces All places accessing node group interface declarations should now be using the new API. A runtime cache has been added that allows simple linear access to socket inputs and outputs even when a panel hierarchy is used. Old DNA has been deprecated and should only be accessed for versioning (inputs/outputs renamed to inputs_legacy/outputs_legacy to catch errors). Versioning code ensures both backward and forward compatibility of existing files. The API for old interfaces is removed. The new API is very similar but is defined on the `ntree.interface` instead of the `ntree` directly. Breaking change notifications and detailed instructions for migrating will be added. A python test has been added for the node group API functions. This includes new functionality such as creating panels and moving items between different levels. This patch does not yet contain panel representations in the modifier UI. This has been tested in a separate branch and will be added with a later PR (#108565). Pull Request: https://projects.blender.org/blender/blender/pulls/111348
2023-08-30 12:37:21 +02:00
const StringRefNull identifier = socket.identifier;
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
/* The property should be created in #MOD_nodes_update_interface with the correct type. */
Geometry Nodes: Improve performance with many inputs Resolves #136183 To avoid quadratic worst case runtime when gathering values from the modifier properties, build a temporary VectorSet of the modifier's IDProperties. In the file from #136183, this change improves playback performance by 1.4x for me, from 50 to 70ms. Ideally IDProperty groups would have constant time lookup on their own, but that's a much larger change, and this smaller change for just Geometry Nodes is not so invasive. Pull Request: https://projects.blender.org/blender/blender/pulls/136463
2025-03-25 15:40:32 +01:00
IDProperty *property = ctx.properties.lookup_key_default_as(identifier, nullptr);
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
/* IDProperties can be removed with python, so there could be a situation where
* there isn't a property for a socket or it doesn't have the correct type. */
Refactor: Move geometry nodes execute implementation for reusability For node group operators (#101778), it helps to reuse the existing geometry nodes execution. This commit adds a new moves most of the geometry computation to the nodes module and gives the modifier (and in the future the operator) a callback to setup the execution context. Pull Request: https://projects.blender.org/blender/blender/pulls/108482
2023-06-12 13:31:09 +02:00
if (property == nullptr || !nodes::id_property_type_matches_socket(socket, *property)) {
Cleanup: Reduce indentation by returning early
2021-04-29 10:46:55 -05:00
return;
}
Fix missing string escape for RNA path creation
2020-12-14 18:44:04 +11:00
Cleanup: Geometry Nodes: simplify property name escaping
2025-05-13 05:30:54 +02:00
const std::string socket_id_esc = BLI_str_escape(identifier.c_str());
const std::string rna_path = fmt::format("[\"{}\"]", socket_id_esc);
Geometry Nodes: Enable exposing object and collection sockets This patch allows connecting wires for object and collection socket types to the "Group Input" node, which exposes them to be adjusted in the modifier. Thanks to @angavrilov's recent work in rB8964c02348f6, it is now possible to edit pointer IDProperties in the interface when they are drawn with `uiItemPointerR`. This patch is composed of a few changes: - Add code to create pointer properties in the modifier settings for object and collection sockets, and also to draw them in the UI. - Also search through the modifier's `IDProperty` settings to find IDs used by the modifier. - Change the setting's UI layout to support the change. Differential Revision: https://developer.blender.org/D10056
2021-01-13 08:13:57 -06:00
Nodes: automatically gray out input values that don't affect the output This patch automatically grays out input values which can't affect the output currently. It works with inputs of group nodes, geometry nodes modifiers and node tools. To achieve this, it analyses the node tree and partially evaluates it to figure out which group inputs are currently not linked to an output or are disabled by e.g. some switch node. Original proposal: https://devtalk.blender.org/t/dynamic-socket-visibility/31874 Related info in blog post: https://code.blender.org/2023/11/geometry-nodes-workshop-november-2023/#dynamic-socket-visibility Follow up task for designing a UI that allows hiding sockets: #132706 Limitations: * The inferencing does not update correctly when a socket starts being animated/driven. I haven't found a good way to invalidate the cache in a good way reliably yet. It's only a very short term problem though. It fixes itself after the next modification of the node tree and is only noticeable when animating some specific sockets such as the switch node condition. * Whether a socket is grayed out is not exposed in the Python API yet. That will be done separately. * Only a partial evaluation is done to determine if an input affects an output. There should be no cases where a socket is found to be unused when it can actually affect the output. However, there can be cases where a socket is inferenced to be used even if it is not due to some complex condition. Depending on the exact circumstances, this can either be improved or the condition in the node tree should be simplified. Pull Request: https://projects.blender.org/blender/blender/pulls/132219
2025-01-21 12:53:24 +01:00
const int input_index = ctx.nmd.node_group->interface_input_index(socket);
Refactor: UI: Replace uiLayoutRow with class method uiLayout::row This converts the public `uiLayoutRow` function to an object oriented API (`uiLayout::row`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::row` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/137979
2025-04-25 19:45:25 +02:00
uiLayout *row = &layout->row(true);
Geometry Nodes: Fix alignment of exposed properties in the modifier The spacing and alignment of the properties in the geometry nodes modifier could vary depending on the type of the socket or whether the input can accept attributes. Wrapping each property in its own `row` layout allows us to make the spacing and alignment between them consistent. Reviewed By: Hans Goudey Differential Revision: http://developer.blender.org/D16417
2022-11-08 19:09:28 +01:00
uiLayoutSetPropDecorate(row, true);
Nodes: automatically gray out input values that don't affect the output This patch automatically grays out input values which can't affect the output currently. It works with inputs of group nodes, geometry nodes modifiers and node tools. To achieve this, it analyses the node tree and partially evaluates it to figure out which group inputs are currently not linked to an output or are disabled by e.g. some switch node. Original proposal: https://devtalk.blender.org/t/dynamic-socket-visibility/31874 Related info in blog post: https://code.blender.org/2023/11/geometry-nodes-workshop-november-2023/#dynamic-socket-visibility Follow up task for designing a UI that allows hiding sockets: #132706 Limitations: * The inferencing does not update correctly when a socket starts being animated/driven. I haven't found a good way to invalidate the cache in a good way reliably yet. It's only a very short term problem though. It fixes itself after the next modification of the node tree and is only noticeable when animating some specific sockets such as the switch node condition. * Whether a socket is grayed out is not exposed in the Python API yet. That will be done separately. * Only a partial evaluation is done to determine if an input affects an output. There should be no cases where a socket is found to be unused when it can actually affect the output. However, there can be cases where a socket is inferenced to be used even if it is not due to some complex condition. Depending on the exact circumstances, this can either be improved or the condition in the node tree should be simplified. Pull Request: https://projects.blender.org/blender/blender/pulls/132219
2025-01-21 12:53:24 +01:00
uiLayoutSetActive(row, ctx.input_usages[input_index]);
Fix #116515: Single Value Only applies to wrong input in geometry nodes modifier The counting of input sockets did not take closed panels into account correctly.
2024-01-09 11:01:12 +01:00
Refactor: UI: Replace uiItemR with class method uiLayout::prop This converts the public `uiItemR` function to an object oriented API (`uiLayout::prop`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138617
2025-05-08 20:45:37 +02:00
/* Use #uiItemPointerR to draw pointer properties because #uiLayout::prop would not have enough
Cleanup: Reduce indentation by returning early
2021-04-29 10:46:55 -05:00
* information about what type of ID to select for editing the values. This is because
* pointer IDProperties contain no information about their type. */
Cleanup: Move BKE_node to namespace Move all header file into namespace. Unnecessary namespaces was removed from implementations file. Part of forward declarations in header was moved in the top part of file just to do not have a lot of separate namespaces. Pull Request: https://projects.blender.org/blender/blender/pulls/121637
2024-05-13 16:07:12 +02:00
const bke::bNodeSocketType *typeinfo = socket.socket_typeinfo();
Nodes: Panels integration with blend files and UI Part 3/3 of #109135, #110272 Switch to new node group interfaces and deprecate old DNA and API. This completes support for panels in node drawing and in node group interface declarations in particular. The new node group interface DNA and RNA code has been added in parts 1 and 2 (#110885, #110952) but has not be enabled yet. This commit completes the integration by * enabling the new RNA API * using the new API in UI * read/write new interfaces from blend files * add versioning for backward compatibility * add forward-compatible writing code to reconstruct old interfaces All places accessing node group interface declarations should now be using the new API. A runtime cache has been added that allows simple linear access to socket inputs and outputs even when a panel hierarchy is used. Old DNA has been deprecated and should only be accessed for versioning (inputs/outputs renamed to inputs_legacy/outputs_legacy to catch errors). Versioning code ensures both backward and forward compatibility of existing files. The API for old interfaces is removed. The new API is very similar but is defined on the `ntree.interface` instead of the `ntree` directly. Breaking change notifications and detailed instructions for migrating will be added. A python test has been added for the node group API functions. This includes new functionality such as creating panels and moving items between different levels. This patch does not yet contain panel representations in the modifier UI. This has been tested in a separate branch and will be added with a later PR (#108565). Pull Request: https://projects.blender.org/blender/blender/pulls/111348
2023-08-30 12:37:21 +02:00
const eNodeSocketDatatype type = typeinfo ? eNodeSocketDatatype(typeinfo->type) : SOCK_CUSTOM;
I18n: translate socket properties in the Modifier Properties editor Each node group asset exposes various properties through sockets. Although they can generally be considered user-created data, for built-in assets they are also part of the UI and should be translated--especially since more modifiers should be migrated to Geometry Nodes in the future. This commit enables the translation of those properties in the Modifier Properties editor. Pull Request: https://projects.blender.org/blender/blender/pulls/114256
2023-10-23 00:14:18 +02:00
const char *name = socket.name ? IFACE_(socket.name) : "";
Nodes: Panels integration with blend files and UI Part 3/3 of #109135, #110272 Switch to new node group interfaces and deprecate old DNA and API. This completes support for panels in node drawing and in node group interface declarations in particular. The new node group interface DNA and RNA code has been added in parts 1 and 2 (#110885, #110952) but has not be enabled yet. This commit completes the integration by * enabling the new RNA API * using the new API in UI * read/write new interfaces from blend files * add versioning for backward compatibility * add forward-compatible writing code to reconstruct old interfaces All places accessing node group interface declarations should now be using the new API. A runtime cache has been added that allows simple linear access to socket inputs and outputs even when a panel hierarchy is used. Old DNA has been deprecated and should only be accessed for versioning (inputs/outputs renamed to inputs_legacy/outputs_legacy to catch errors). Versioning code ensures both backward and forward compatibility of existing files. The API for old interfaces is removed. The new API is very similar but is defined on the `ntree.interface` instead of the `ntree` directly. Breaking change notifications and detailed instructions for migrating will be added. A python test has been added for the node group API functions. This includes new functionality such as creating panels and moving items between different levels. This patch does not yet contain panel representations in the modifier UI. This has been tested in a separate branch and will be added with a later PR (#108565). Pull Request: https://projects.blender.org/blender/blender/pulls/111348
2023-08-30 12:37:21 +02:00
switch (type) {
Cleanup: Reduce indentation by returning early
2021-04-29 10:46:55 -05:00
case SOCK_OBJECT: {
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
uiItemPointerR(row, ctx.md_ptr, rna_path, ctx.bmain_ptr, "objects", name, ICON_OBJECT_DATA);
Cleanup: Reduce indentation by returning early
2021-04-29 10:46:55 -05:00
break;
}
case SOCK_COLLECTION: {
Geometry Nodes: Fix alignment of exposed properties in the modifier The spacing and alignment of the properties in the geometry nodes modifier could vary depending on the type of the socket or whether the input can accept attributes. Wrapping each property in its own `row` layout allows us to make the spacing and alignment between them consistent. Reviewed By: Hans Goudey Differential Revision: http://developer.blender.org/D16417
2022-11-08 19:09:28 +01:00
uiItemPointerR(
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
row, ctx.md_ptr, rna_path, ctx.bmain_ptr, "collections", name, ICON_OUTLINER_COLLECTION);
Cleanup: Reduce indentation by returning early
2021-04-29 10:46:55 -05:00
break;
Geometry Nodes: Enable exposing object and collection sockets This patch allows connecting wires for object and collection socket types to the "Group Input" node, which exposes them to be adjusted in the modifier. Thanks to @angavrilov's recent work in rB8964c02348f6, it is now possible to edit pointer IDProperties in the interface when they are drawn with `uiItemPointerR`. This patch is composed of a few changes: - Add code to create pointer properties in the modifier settings for object and collection sockets, and also to draw them in the UI. - Also search through the modifier's `IDProperty` settings to find IDs used by the modifier. - Change the setting's UI layout to support the change. Differential Revision: https://developer.blender.org/D10056
2021-01-13 08:13:57 -06:00
}
Geometry Nodes: Expose texture and material inputs to modifier This allows choosing material and texture sockets for the group input node in the modifier. Note that currently grease pencil materials are displayed in the list, even though grease pencil data is not supported yet by geometry nodes. That is more complicated to fix in this case, since we use IDProperties to store the dynamic exposed inputs. Differential Revision: https://developer.blender.org/D11393
2021-05-27 11:06:08 -04:00
case SOCK_MATERIAL: {
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
uiItemPointerR(row, ctx.md_ptr, rna_path, ctx.bmain_ptr, "materials", name, ICON_MATERIAL);
Geometry Nodes: Expose texture and material inputs to modifier This allows choosing material and texture sockets for the group input node in the modifier. Note that currently grease pencil materials are displayed in the list, even though grease pencil data is not supported yet by geometry nodes. That is more complicated to fix in this case, since we use IDProperties to store the dynamic exposed inputs. Differential Revision: https://developer.blender.org/D11393
2021-05-27 11:06:08 -04:00
break;
}
case SOCK_TEXTURE: {
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
uiItemPointerR(row, ctx.md_ptr, rna_path, ctx.bmain_ptr, "textures", name, ICON_TEXTURE);
Geometry Nodes: Expose texture and material inputs to modifier This allows choosing material and texture sockets for the group input node in the modifier. Note that currently grease pencil materials are displayed in the list, even though grease pencil data is not supported yet by geometry nodes. That is more complicated to fix in this case, since we use IDProperties to store the dynamic exposed inputs. Differential Revision: https://developer.blender.org/D11393
2021-05-27 11:06:08 -04:00
break;
}
Nodes: add boilerplate for image sockets The sockets are not exposed in any nodes yet. They work similar to the Object/Collection/Texture sockets, which also just reference a data block. Based on rB207472930834 Reviewed By: JacquesLucke Differential Revision: https://developer.blender.org/D12861
2021-10-14 14:18:24 +01:00
case SOCK_IMAGE: {
Geometry Nodes: support opening images in modifier Previously, it was unnecessarily complicated to open an image that is passed into Geometry Nodes. Pull Request: https://projects.blender.org/blender/blender/pulls/135352
2025-03-04 23:59:22 +01:00
uiTemplateID(row,
&ctx.C,
ctx.md_ptr,
rna_path,
"image.new",
"image.open",
nullptr,
UI_TEMPLATE_ID_FILTER_ALL,
false,
name);
Nodes: add boilerplate for image sockets The sockets are not exposed in any nodes yet. They work similar to the Object/Collection/Texture sockets, which also just reference a data block. Based on rB207472930834 Reviewed By: JacquesLucke Differential Revision: https://developer.blender.org/D12861
2021-10-14 14:18:24 +01:00
break;
}
Nodes: support expanded menus in node group interface Previously, menu sockets were always drawn as dropdown. This patch adds the ability to draw them expanded instead. As before, in the node editor, only the expanded menu is drawn, without the label. There is simply not enough space for both. However, in the modifier and operator settings the label is drawn currently. We'll probably need to add a separate `Hide Label` option (similar to `Hide Value`) for group inputs that support it. That would also help a lot with e.g. object sockets. Pull Request: https://projects.blender.org/blender/blender/pulls/138387
2025-05-08 04:31:09 +02:00
case SOCK_MENU: {
if (socket.flag & NODE_INTERFACE_SOCKET_MENU_EXPANDED) {
Fix: Geometry Nodes: empty expanded menu entries in modifier Work around an issue with expanded menus that exists for a long time already. I briefly tried fixing it, but does not seem straight forward unfortunately without breaking stuff. Also see the comment in `ui_item_enum_expand_exec`.
2025-05-14 14:04:11 +02:00
/* Use a single space when the name is empty to work around a bug with expanded enums. Also
* see #ui_item_enum_expand_exec. */
row->prop(ctx.md_ptr,
rna_path,
UI_ITEM_R_EXPAND,
StringRef(name).is_empty() ? " " : name,
ICON_NONE);
Nodes: support expanded menus in node group interface Previously, menu sockets were always drawn as dropdown. This patch adds the ability to draw them expanded instead. As before, in the node editor, only the expanded menu is drawn, without the label. There is simply not enough space for both. However, in the modifier and operator settings the label is drawn currently. We'll probably need to add a separate `Hide Label` option (similar to `Hide Value`) for group inputs that support it. That would also help a lot with e.g. object sockets. Pull Request: https://projects.blender.org/blender/blender/pulls/138387
2025-05-08 04:31:09 +02:00
}
else {
Refactor: UI: Replace uiItemR with class method uiLayout::prop This converts the public `uiItemR` function to an object oriented API (`uiLayout::prop`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138617
2025-05-08 20:45:37 +02:00
row->prop(ctx.md_ptr, rna_path, UI_ITEM_NONE, name, ICON_NONE);
Nodes: support expanded menus in node group interface Previously, menu sockets were always drawn as dropdown. This patch adds the ability to draw them expanded instead. As before, in the node editor, only the expanded menu is drawn, without the label. There is simply not enough space for both. However, in the modifier and operator settings the label is drawn currently. We'll probably need to add a separate `Hide Label` option (similar to `Hide Value`) for group inputs that support it. That would also help a lot with e.g. object sockets. Pull Request: https://projects.blender.org/blender/blender/pulls/138387
2025-05-08 04:31:09 +02:00
}
break;
}
GPv3: Layer Selection modifier input Known limitations to be addressed separately: * We are not warning/keeping track of the named layers. * There is no lookup for layers (groups) yet. Ref !113908.
2023-10-20 14:51:30 +02:00
case SOCK_BOOLEAN: {
if (is_layer_selection_field(socket)) {
Geometry Nodes: Add Grease Pencil layer name search This makes it possible to search layer names in the `Named Layer Selection` node as well as boolean modifier inputs that are marked as a `Layer Selection`. The layer selection UI is slightly updated: * Use a slightly larger default width for the `Named Layer Selection` node. * Use the layer icon in the field that search for layer names. * Use `Layer` placeholder string Pull Request: https://projects.blender.org/blender/blender/pulls/137273
2025-04-18 12:35:49 +02:00
add_layer_name_search_button(ctx, row, socket_id_esc, socket);
/* Adds a spacing at the end of the row. */
Refactor: UI: Replace uiItemL with class method uiLayout::label This converts the public `uiItemL` function to an object oriented API (`uiLayout::label`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138608
2025-05-08 17:21:08 +02:00
row->label("", ICON_BLANK1);
GPv3: Layer Selection modifier input Known limitations to be addressed separately: * We are not warning/keeping track of the named layers. * There is no lookup for layers (groups) yet. Ref !113908.
2023-10-20 14:51:30 +02:00
break;
}
ATTR_FALLTHROUGH;
}
Geometry Nodes: Add a toggle to use attributes as input values This adds a toggle to node group inputs exposed in the modifier to use an attribute instead of a single value. When the toggle is pressed, the button switches to a text button to choose an attribute name. Attribute search isn't implemented here yet. One confusing thing is that some values can't be driven by attributes at all, like the size of a primitive node. In that case, we should have a node warning, but that will be separate since it's more general. We can also have an option to turn off this toggle in node group input settings. The two new properties for each input are stored with the same name as the value, but with `"_use_attribute"` and `"_attribute_name"`` suffixes. The properties are not added for socket types that don't support attribute input, like object sockets. Differential Revision: https://developer.blender.org/D12504
2021-09-16 20:49:10 -05:00
default: {
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
if (nodes::input_has_attribute_toggle(*ctx.nmd.node_group, input_index)) {
add_attribute_search_or_value_buttons(ctx, row, socket_id_esc, rna_path, socket);
Geometry Nodes: Add a toggle to use attributes as input values This adds a toggle to node group inputs exposed in the modifier to use an attribute instead of a single value. When the toggle is pressed, the button switches to a text button to choose an attribute name. Attribute search isn't implemented here yet. One confusing thing is that some values can't be driven by attributes at all, like the size of a primitive node. In that case, we should have a node warning, but that will be separate since it's more general. We can also have an option to turn off this toggle in node group input settings. The two new properties for each input are stored with the same name as the value, but with `"_use_attribute"` and `"_attribute_name"`` suffixes. The properties are not added for socket types that don't support attribute input, like object sockets. Differential Revision: https://developer.blender.org/D12504
2021-09-16 20:49:10 -05:00
}
else {
Refactor: UI: Replace uiItemR with class method uiLayout::prop This converts the public `uiItemR` function to an object oriented API (`uiLayout::prop`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138617
2025-05-08 20:45:37 +02:00
row->prop(ctx.md_ptr, rna_path, UI_ITEM_NONE, name, ICON_NONE);
Geometry Nodes: Add a toggle to use attributes as input values This adds a toggle to node group inputs exposed in the modifier to use an attribute instead of a single value. When the toggle is pressed, the button switches to a text button to choose an attribute name. Attribute search isn't implemented here yet. One confusing thing is that some values can't be driven by attributes at all, like the size of a primitive node. In that case, we should have a node warning, but that will be separate since it's more general. We can also have an option to turn off this toggle in node group input settings. The two new properties for each input are stored with the same name as the value, but with `"_use_attribute"` and `"_attribute_name"`` suffixes. The properties are not added for socket types that don't support attribute input, like object sockets. Differential Revision: https://developer.blender.org/D12504
2021-09-16 20:49:10 -05:00
}
}
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
}
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
if (!nodes::input_has_attribute_toggle(*ctx.nmd.node_group, input_index)) {
Refactor: UI: Replace uiItemL with class method uiLayout::label This converts the public `uiItemL` function to an object oriented API (`uiLayout::label`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138608
2025-05-08 17:21:08 +02:00
row->label("", ICON_BLANK1);
Geometry Nodes: Adjust modifier UI to put field toggles on the right This also fixes the layout of boolean properties with the field toggle visible. This was discussed in the most recent geometry nodes submodule meeting.
2023-01-20 17:41:34 -06:00
}
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
}
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
static void draw_property_for_output_socket(DrawGroupInputsContext &ctx,
Fix part of T89313: Attribute search crash during animation playback During animation playback, data-blocks are reallocated, so storing pointers to the resulting data is not okay. Instead, the data should be retrieved from the context. This works when the applied search item is the "dummy" item added for non-matches. However, it still crashes for every other item, because the memory is owned by the modifier value log, which has been freed by the time the exec function runs. The next part of the solution is to allow uiSearchItems to own memory for the search items.
2021-11-05 11:19:12 -05:00
uiLayout *layout,
Nodes: Panels integration with blend files and UI Part 3/3 of #109135, #110272 Switch to new node group interfaces and deprecate old DNA and API. This completes support for panels in node drawing and in node group interface declarations in particular. The new node group interface DNA and RNA code has been added in parts 1 and 2 (#110885, #110952) but has not be enabled yet. This commit completes the integration by * enabling the new RNA API * using the new API in UI * read/write new interfaces from blend files * add versioning for backward compatibility * add forward-compatible writing code to reconstruct old interfaces All places accessing node group interface declarations should now be using the new API. A runtime cache has been added that allows simple linear access to socket inputs and outputs even when a panel hierarchy is used. Old DNA has been deprecated and should only be accessed for versioning (inputs/outputs renamed to inputs_legacy/outputs_legacy to catch errors). Versioning code ensures both backward and forward compatibility of existing files. The API for old interfaces is removed. The new API is very similar but is defined on the `ntree.interface` instead of the `ntree` directly. Breaking change notifications and detailed instructions for migrating will be added. A python test has been added for the node group API functions. This includes new functionality such as creating panels and moving items between different levels. This patch does not yet contain panel representations in the modifier UI. This has been tested in a separate branch and will be added with a later PR (#108565). Pull Request: https://projects.blender.org/blender/blender/pulls/111348
2023-08-30 12:37:21 +02:00
const bNodeTreeInterfaceSocket &socket)
Geometry Nodes: support creating new attributes in modifier This patch allows passing a field to the modifier as output. In the modifier, the user can choose an attribute name. The attribute will be filled with values computed by the field. This only works for realized mesh/curve/point data. As mentioned in T91376, the output domain is selected in the node group itself. We might want to add this functionality to the modifier later as well, but not now. Differential Revision: https://developer.blender.org/D12644
2021-09-27 15:33:48 +02:00
{
Nodes: Panels integration with blend files and UI Part 3/3 of #109135, #110272 Switch to new node group interfaces and deprecate old DNA and API. This completes support for panels in node drawing and in node group interface declarations in particular. The new node group interface DNA and RNA code has been added in parts 1 and 2 (#110885, #110952) but has not be enabled yet. This commit completes the integration by * enabling the new RNA API * using the new API in UI * read/write new interfaces from blend files * add versioning for backward compatibility * add forward-compatible writing code to reconstruct old interfaces All places accessing node group interface declarations should now be using the new API. A runtime cache has been added that allows simple linear access to socket inputs and outputs even when a panel hierarchy is used. Old DNA has been deprecated and should only be accessed for versioning (inputs/outputs renamed to inputs_legacy/outputs_legacy to catch errors). Versioning code ensures both backward and forward compatibility of existing files. The API for old interfaces is removed. The new API is very similar but is defined on the `ntree.interface` instead of the `ntree` directly. Breaking change notifications and detailed instructions for migrating will be added. A python test has been added for the node group API functions. This includes new functionality such as creating panels and moving items between different levels. This patch does not yet contain panel representations in the modifier UI. This has been tested in a separate branch and will be added with a later PR (#108565). Pull Request: https://projects.blender.org/blender/blender/pulls/111348
2023-08-30 12:37:21 +02:00
const StringRefNull identifier = socket.identifier;
char socket_id_esc[MAX_NAME * 2];
BLI_str_escape(socket_id_esc, identifier.c_str(), sizeof(socket_id_esc));
Cleanup: Avoid reformatting geometry nodes property names, use fmt
2024-12-04 12:37:54 -05:00
const std::string rna_path_attribute_name = fmt::format(
"[\"{}{}\"]", socket_id_esc, nodes::input_attribute_name_suffix);
Geometry Nodes: support creating new attributes in modifier This patch allows passing a field to the modifier as output. In the modifier, the user can choose an attribute name. The attribute will be filled with values computed by the field. This only works for realized mesh/curve/point data. As mentioned in T91376, the output domain is selected in the node group itself. We might want to add this functionality to the modifier later as well, but not now. Differential Revision: https://developer.blender.org/D12644
2021-09-27 15:33:48 +02:00
Refactor: UI: Replace uiLayoutSplit with class method uiLayout::split This converts the public `uiLayoutSplit` function to an object oriented API (`uiLayout::split`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::split` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Pull Request: https://projects.blender.org/blender/blender/pulls/138361
2025-05-03 20:51:42 +02:00
uiLayout *split = &layout->split(0.4f, false);
Refactor: UI: Replace uiLayoutRow with class method uiLayout::row This converts the public `uiLayoutRow` function to an object oriented API (`uiLayout::row`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::row` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/137979
2025-04-25 19:45:25 +02:00
uiLayout *name_row = &split->row(false);
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
uiLayoutSetAlignment(name_row, UI_LAYOUT_ALIGN_RIGHT);
Refactor: UI: Replace uiItemL with class method uiLayout::label This converts the public `uiItemL` function to an object oriented API (`uiLayout::label`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138608
2025-05-08 17:21:08 +02:00
name_row->label(socket.name ? socket.name : "", ICON_NONE);
Geometry Nodes: Attribute search in the modifier This adds attribute search to the geometry nodes modifier for the input and output attributes. The "New" search item is only shown for the output attributes. Some of the attribute search code is extracted to a new file in the interface code, to avoid some code duplication. The UI code required two fixes so that the search would work for dynamic length strings (IDProperties do not have a fixed size). Since this does changes to the UI layout of the modifier, I also addressed T91485 here. Differential Revisiion: https://developer.blender.org/D12788
2021-10-21 13:54:48 -05:00
Refactor: UI: Replace uiLayoutRow with class method uiLayout::row This converts the public `uiLayoutRow` function to an object oriented API (`uiLayout::row`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::row` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/137979
2025-04-25 19:45:25 +02:00
uiLayout *row = &split->row(true);
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
add_attribute_search_button(ctx, row, rna_path_attribute_name, socket, true);
Geometry Nodes: support creating new attributes in modifier This patch allows passing a field to the modifier as output. In the modifier, the user can choose an attribute name. The attribute will be filled with values computed by the field. This only works for realized mesh/curve/point data. As mentioned in T91376, the output domain is selected in the node group itself. We might want to add this functionality to the modifier later as well, but not now. Differential Revision: https://developer.blender.org/D12644
2021-09-27 15:33:48 +02:00
}
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
static NodesModifierPanel *find_panel_by_id(NodesModifierData &nmd, const int id)
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
{
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
for (const int i : IndexRange(nmd.panels_num)) {
if (nmd.panels[i].id == id) {
return &nmd.panels[i];
}
Geometry Nodes: Hide node group selector for asset modifiers When adding modifiers from assets in the new modifier menu, switching the node group the modifier uses afterwards will not be common. The goal is to replace the builtin modifier directly. In that case it's easier to just add a new modifier. The "Empty Modifier" item makes it easy to choose an arbitrary node group anyway. Combined with hiding the two sub-panels when they are unnecessary, many node-modifiers will look just as clean as their builtin counterparts. The option to show the data-block selector is added to the menu in the node header so it's still accessible though. Pull Request: https://projects.blender.org/blender/blender/pulls/111995
2023-09-07 14:47:40 +02:00
}
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
return nullptr;
}
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
Cleanuo: typo
2024-12-23 12:21:00 +01:00
static bool interface_panel_has_socket(const bNodeTreeInterfacePanel &interface_panel)
Fix #129087: don't show empty panels in geometry nodes modifier If a panel is detected to be empty, it is hidden automatically now. This is the same behavior as in group nodes.
2024-10-21 15:47:16 +02:00
{
for (const bNodeTreeInterfaceItem *item : interface_panel.items()) {
if (item->item_type == NODE_INTERFACE_SOCKET) {
Fix #130922: GN: Hide empty panel in modifier UI `interace_panel_has_socket` should return true when panel has at least a socket of type input or hidden in modifier. That way, panel drawing code won't be executed. Pull Request: https://projects.blender.org/blender/blender/pulls/130958
2024-12-01 07:37:06 +01:00
const bNodeTreeInterfaceSocket &socket = *reinterpret_cast<const bNodeTreeInterfaceSocket *>(
item);
if ((socket.flag &
(NODE_INTERFACE_SOCKET_HIDE_IN_MODIFIER | NODE_INTERFACE_SOCKET_OUTPUT)) == 0)
{
return true;
}
Fix #129087: don't show empty panels in geometry nodes modifier If a panel is detected to be empty, it is hidden automatically now. This is the same behavior as in group nodes.
2024-10-21 15:47:16 +02:00
}
if (item->item_type == NODE_INTERFACE_PANEL) {
Cleanuo: typo
2024-12-23 12:21:00 +01:00
if (interface_panel_has_socket(*reinterpret_cast<const bNodeTreeInterfacePanel *>(item))) {
Fix #129087: don't show empty panels in geometry nodes modifier If a panel is detected to be empty, it is hidden automatically now. This is the same behavior as in group nodes.
2024-10-21 15:47:16 +02:00
return true;
}
}
}
return false;
}
Nodes: automatically gray out input values that don't affect the output This patch automatically grays out input values which can't affect the output currently. It works with inputs of group nodes, geometry nodes modifiers and node tools. To achieve this, it analyses the node tree and partially evaluates it to figure out which group inputs are currently not linked to an output or are disabled by e.g. some switch node. Original proposal: https://devtalk.blender.org/t/dynamic-socket-visibility/31874 Related info in blog post: https://code.blender.org/2023/11/geometry-nodes-workshop-november-2023/#dynamic-socket-visibility Follow up task for designing a UI that allows hiding sockets: #132706 Limitations: * The inferencing does not update correctly when a socket starts being animated/driven. I haven't found a good way to invalidate the cache in a good way reliably yet. It's only a very short term problem though. It fixes itself after the next modification of the node tree and is only noticeable when animating some specific sockets such as the switch node condition. * Whether a socket is grayed out is not exposed in the Python API yet. That will be done separately. * Only a partial evaluation is done to determine if an input affects an output. There should be no cases where a socket is found to be unused when it can actually affect the output. However, there can be cases where a socket is inferenced to be used even if it is not due to some complex condition. Depending on the exact circumstances, this can either be improved or the condition in the node tree should be simplified. Pull Request: https://projects.blender.org/blender/blender/pulls/132219
2025-01-21 12:53:24 +01:00
static bool interface_panel_affects_output(DrawGroupInputsContext &ctx,
const bNodeTreeInterfacePanel &panel)
{
for (const bNodeTreeInterfaceItem *item : panel.items()) {
if (item->item_type == NODE_INTERFACE_SOCKET) {
const auto &socket = *reinterpret_cast<const bNodeTreeInterfaceSocket *>(item);
Fix #135633: Freeze/crash using a specific Geometry Node group as modifier `interface_input_index` was called for an output socket. Also filter out inputs that aren't exposed in the modifier, similar to a few lines above. Pull Request: https://projects.blender.org/blender/blender/pulls/135641
2025-03-07 18:46:53 +01:00
if (socket.flag & NODE_INTERFACE_SOCKET_HIDE_IN_MODIFIER) {
continue;
}
if (!(socket.flag & NODE_INTERFACE_SOCKET_INPUT)) {
continue;
}
Nodes: automatically gray out input values that don't affect the output This patch automatically grays out input values which can't affect the output currently. It works with inputs of group nodes, geometry nodes modifiers and node tools. To achieve this, it analyses the node tree and partially evaluates it to figure out which group inputs are currently not linked to an output or are disabled by e.g. some switch node. Original proposal: https://devtalk.blender.org/t/dynamic-socket-visibility/31874 Related info in blog post: https://code.blender.org/2023/11/geometry-nodes-workshop-november-2023/#dynamic-socket-visibility Follow up task for designing a UI that allows hiding sockets: #132706 Limitations: * The inferencing does not update correctly when a socket starts being animated/driven. I haven't found a good way to invalidate the cache in a good way reliably yet. It's only a very short term problem though. It fixes itself after the next modification of the node tree and is only noticeable when animating some specific sockets such as the switch node condition. * Whether a socket is grayed out is not exposed in the Python API yet. That will be done separately. * Only a partial evaluation is done to determine if an input affects an output. There should be no cases where a socket is found to be unused when it can actually affect the output. However, there can be cases where a socket is inferenced to be used even if it is not due to some complex condition. Depending on the exact circumstances, this can either be improved or the condition in the node tree should be simplified. Pull Request: https://projects.blender.org/blender/blender/pulls/132219
2025-01-21 12:53:24 +01:00
const int input_index = ctx.nmd.node_group->interface_input_index(socket);
if (ctx.input_usages[input_index]) {
return true;
}
}
else if (item->item_type == NODE_INTERFACE_PANEL) {
const auto &sub_interface_panel = *reinterpret_cast<const bNodeTreeInterfacePanel *>(item);
if (interface_panel_affects_output(ctx, sub_interface_panel)) {
return true;
}
}
}
return false;
}
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
static void draw_interface_panel_content(DrawGroupInputsContext &ctx,
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
uiLayout *layout,
Nodes: support boolean inputs as toggles in panel headers Adds the option to create a boolean socket that can be used as a panel toggle. This allows creating simpler and more compact node group UIs when a panel can be "disabled". The toggle input is a normal input socket that is just drawn a bit differently in the UI. Whether a boolean is a toggle input or not does not affect evaluation. Also see #133936 for guides on how to add and remove panel toggles. Pull Request: https://projects.blender.org/blender/blender/pulls/133936
2025-02-28 19:07:02 +01:00
const bNodeTreeInterfacePanel &interface_panel,
const bool skip_first = false)
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
{
Nodes: support boolean inputs as toggles in panel headers Adds the option to create a boolean socket that can be used as a panel toggle. This allows creating simpler and more compact node group UIs when a panel can be "disabled". The toggle input is a normal input socket that is just drawn a bit differently in the UI. Whether a boolean is a toggle input or not does not affect evaluation. Also see #133936 for guides on how to add and remove panel toggles. Pull Request: https://projects.blender.org/blender/blender/pulls/133936
2025-02-28 19:07:02 +01:00
for (const bNodeTreeInterfaceItem *item : interface_panel.items().drop_front(skip_first ? 1 : 0))
{
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
if (item->item_type == NODE_INTERFACE_PANEL) {
const auto &sub_interface_panel = *reinterpret_cast<const bNodeTreeInterfacePanel *>(item);
Cleanuo: typo
2024-12-23 12:21:00 +01:00
if (!interface_panel_has_socket(sub_interface_panel)) {
Fix #129087: don't show empty panels in geometry nodes modifier If a panel is detected to be empty, it is hidden automatically now. This is the same behavior as in group nodes.
2024-10-21 15:47:16 +02:00
continue;
}
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
NodesModifierPanel *panel = find_panel_by_id(ctx.nmd, sub_interface_panel.identifier);
Refactor: RNA: add `discrete` suffix to `RNA_pointer_create`. This is a noisy preliminary step to the 'RNA ancestors' change. The rename helps clearly tell what each `pointer_create` function does. Pull Request: https://projects.blender.org/blender/blender/pulls/133475
2025-01-24 16:45:32 +01:00
PointerRNA panel_ptr = RNA_pointer_create_discrete(
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
ctx.md_ptr->owner_id, &RNA_NodesModifierPanel, panel);
Nodes: support boolean inputs as toggles in panel headers Adds the option to create a boolean socket that can be used as a panel toggle. This allows creating simpler and more compact node group UIs when a panel can be "disabled". The toggle input is a normal input socket that is just drawn a bit differently in the UI. Whether a boolean is a toggle input or not does not affect evaluation. Also see #133936 for guides on how to add and remove panel toggles. Pull Request: https://projects.blender.org/blender/blender/pulls/133936
2025-02-28 19:07:02 +01:00
PanelLayout panel_layout;
bool skip_first = false;
/* Check if the panel should have a toggle in the header. */
const bNodeTreeInterfaceSocket *toggle_socket = sub_interface_panel.header_toggle_socket();
if (toggle_socket && !(toggle_socket->flag & NODE_INTERFACE_SOCKET_HIDE_IN_MODIFIER)) {
const StringRefNull identifier = toggle_socket->identifier;
Geometry Nodes: Improve performance with many inputs Resolves #136183 To avoid quadratic worst case runtime when gathering values from the modifier properties, build a temporary VectorSet of the modifier's IDProperties. In the file from #136183, this change improves playback performance by 1.4x for me, from 50 to 70ms. Ideally IDProperty groups would have constant time lookup on their own, but that's a much larger change, and this smaller change for just Geometry Nodes is not so invasive. Pull Request: https://projects.blender.org/blender/blender/pulls/136463
2025-03-25 15:40:32 +01:00
IDProperty *property = ctx.properties.lookup_key_default_as(identifier, nullptr);
Nodes: support boolean inputs as toggles in panel headers Adds the option to create a boolean socket that can be used as a panel toggle. This allows creating simpler and more compact node group UIs when a panel can be "disabled". The toggle input is a normal input socket that is just drawn a bit differently in the UI. Whether a boolean is a toggle input or not does not affect evaluation. Also see #133936 for guides on how to add and remove panel toggles. Pull Request: https://projects.blender.org/blender/blender/pulls/133936
2025-02-28 19:07:02 +01:00
/* IDProperties can be removed with python, so there could be a situation where
* there isn't a property for a socket or it doesn't have the correct type. */
if (property == nullptr ||
!nodes::id_property_type_matches_socket(*toggle_socket, *property))
{
continue;
}
char socket_id_esc[MAX_NAME * 2];
BLI_str_escape(socket_id_esc, identifier.c_str(), sizeof(socket_id_esc));
char rna_path[sizeof(socket_id_esc) + 4];
SNPRINTF(rna_path, "[\"%s\"]", socket_id_esc);
Refactor: UI: Replace uiLayoutPanelPropWithBoolHeader with class method This converts the public uiLayoutPanelPropWithBoolHeader function to an object oriented API (`uiLayout::panel_prop_with_bool_header`), following similar changes to the uiLayout API. Pull Request: https://projects.blender.org/blender/blender/pulls/138523
2025-05-07 02:55:25 +02:00
panel_layout = layout->panel_prop_with_bool_header(
&ctx.C, &panel_ptr, "is_open", ctx.md_ptr, rna_path, IFACE_(sub_interface_panel.name));
Nodes: support boolean inputs as toggles in panel headers Adds the option to create a boolean socket that can be used as a panel toggle. This allows creating simpler and more compact node group UIs when a panel can be "disabled". The toggle input is a normal input socket that is just drawn a bit differently in the UI. Whether a boolean is a toggle input or not does not affect evaluation. Also see #133936 for guides on how to add and remove panel toggles. Pull Request: https://projects.blender.org/blender/blender/pulls/133936
2025-02-28 19:07:02 +01:00
skip_first = true;
}
else {
Refactor: UI: Replace uiLayoutPanelProp with class method uiLayout::panel_prop This converts the public `uiLayoutPanelProp` function to an object oriented API (`uiLayout::panel_prop`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Pull Request: https://projects.blender.org/blender/blender/pulls/138501
2025-05-06 17:13:30 +02:00
panel_layout = layout->panel_prop(&ctx.C, &panel_ptr, "is_open");
Refactor: UI: Replace uiItemL with class method uiLayout::label This converts the public `uiItemL` function to an object oriented API (`uiLayout::label`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138608
2025-05-08 17:21:08 +02:00
panel_layout.header->label(IFACE_(sub_interface_panel.name), ICON_NONE);
Nodes: support boolean inputs as toggles in panel headers Adds the option to create a boolean socket that can be used as a panel toggle. This allows creating simpler and more compact node group UIs when a panel can be "disabled". The toggle input is a normal input socket that is just drawn a bit differently in the UI. Whether a boolean is a toggle input or not does not affect evaluation. Also see #133936 for guides on how to add and remove panel toggles. Pull Request: https://projects.blender.org/blender/blender/pulls/133936
2025-02-28 19:07:02 +01:00
}
Nodes: automatically gray out input values that don't affect the output This patch automatically grays out input values which can't affect the output currently. It works with inputs of group nodes, geometry nodes modifiers and node tools. To achieve this, it analyses the node tree and partially evaluates it to figure out which group inputs are currently not linked to an output or are disabled by e.g. some switch node. Original proposal: https://devtalk.blender.org/t/dynamic-socket-visibility/31874 Related info in blog post: https://code.blender.org/2023/11/geometry-nodes-workshop-november-2023/#dynamic-socket-visibility Follow up task for designing a UI that allows hiding sockets: #132706 Limitations: * The inferencing does not update correctly when a socket starts being animated/driven. I haven't found a good way to invalidate the cache in a good way reliably yet. It's only a very short term problem though. It fixes itself after the next modification of the node tree and is only noticeable when animating some specific sockets such as the switch node condition. * Whether a socket is grayed out is not exposed in the Python API yet. That will be done separately. * Only a partial evaluation is done to determine if an input affects an output. There should be no cases where a socket is found to be unused when it can actually affect the output. However, there can be cases where a socket is inferenced to be used even if it is not due to some complex condition. Depending on the exact circumstances, this can either be improved or the condition in the node tree should be simplified. Pull Request: https://projects.blender.org/blender/blender/pulls/132219
2025-01-21 12:53:24 +01:00
if (!interface_panel_affects_output(ctx, sub_interface_panel)) {
uiLayoutSetActive(panel_layout.header, false);
}
Nodes: show panel description when hovering over panel headers We already have the `description` property on panels but are currently not displaying it when hovering over a panel header. With this patch, the descriptions will be shown in group nodes as well as the geometry nodes modifier. I had to do two lower level changes for layout panels because it didn't work with tooltips properly. * Tooltips make the label in the panel header interactive, but clicking to open/close the panel should still work. * The tooltip should disappear when clicking on the header. This is consistent with tooltips in other places. Pull Request: https://projects.blender.org/blender/blender/pulls/127852
2024-09-20 16:24:09 +02:00
uiLayoutSetTooltipFunc(
panel_layout.header,
Cleanup: Use StringRef for uiBut tooltips And replace nullptr arguments for tooltips in UI button creation functions with std::nullopt. Though the distinction between "no tooltip" and "empty tooltip" doesn't seem to exist, it seems safer to keep the distinction since it existed with null before.
2025-02-14 15:12:48 -05:00
[](bContext * /*C*/, void *panel_arg, const StringRef /*tip*/) -> std::string {
Nodes: show panel description when hovering over panel headers We already have the `description` property on panels but are currently not displaying it when hovering over a panel header. With this patch, the descriptions will be shown in group nodes as well as the geometry nodes modifier. I had to do two lower level changes for layout panels because it didn't work with tooltips properly. * Tooltips make the label in the panel header interactive, but clicking to open/close the panel should still work. * The tooltip should disappear when clicking on the header. This is consistent with tooltips in other places. Pull Request: https://projects.blender.org/blender/blender/pulls/127852
2024-09-20 16:24:09 +02:00
const auto *panel = static_cast<bNodeTreeInterfacePanel *>(panel_arg);
return StringRef(panel->description);
},
const_cast<bNodeTreeInterfacePanel *>(&sub_interface_panel),
nullptr,
nullptr);
if (panel_layout.body) {
Nodes: support boolean inputs as toggles in panel headers Adds the option to create a boolean socket that can be used as a panel toggle. This allows creating simpler and more compact node group UIs when a panel can be "disabled". The toggle input is a normal input socket that is just drawn a bit differently in the UI. Whether a boolean is a toggle input or not does not affect evaluation. Also see #133936 for guides on how to add and remove panel toggles. Pull Request: https://projects.blender.org/blender/blender/pulls/133936
2025-02-28 19:07:02 +01:00
draw_interface_panel_content(ctx, panel_layout.body, sub_interface_panel, skip_first);
Geometry Nodes: Add option to hide input in modifier When building a node group that's meant to be used directly in the node editor as well as in the modifier, it's useful to be able to have some inputs that are only meant for the node editor, like inputs that only make sense when combined with other nodes. In the future we might have the ability to only display certain assets in the modifier and the node editor, but until then this simple solution allows a bit more customization. Pull Request #104517
2023-02-11 16:11:10 +01:00
}
Geometry Nodes: support creating new attributes in modifier This patch allows passing a field to the modifier as output. In the modifier, the user can choose an attribute name. The attribute will be filled with values computed by the field. This only works for realized mesh/curve/point data. As mentioned in T91376, the output domain is selected in the node group itself. We might want to add this functionality to the modifier later as well, but not now. Differential Revision: https://developer.blender.org/D12644
2021-09-27 15:33:48 +02:00
}
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
else {
const auto &interface_socket = *reinterpret_cast<const bNodeTreeInterfaceSocket *>(item);
if (interface_socket.flag & NODE_INTERFACE_SOCKET_INPUT) {
if (!(interface_socket.flag & NODE_INTERFACE_SOCKET_HIDE_IN_MODIFIER)) {
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
draw_property_for_socket(ctx, layout, interface_socket);
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
}
Geometry Nodes: Display Node Warnings in Modifier With this commit, node warnings added to nodes during evaluation (not "Info" warnings) will also draw in the modifier. In the future there could be a "search for this node" button as well. Differential Revision: https://developer.blender.org/D11983
2021-07-22 17:53:35 -04:00
}
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
}
Geometry Nodes: Display Node Warnings in Modifier With this commit, node warnings added to nodes during evaluation (not "Info" warnings) will also draw in the modifier. In the future there could be a "search for this node" button as well. Differential Revision: https://developer.blender.org/D11983
2021-07-22 17:53:35 -04:00
}
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
}
Geometry Nodes: reorganize panels in modifier The goal is to simplify the interface of the geometry nodes modifier while also making it more scalable. This allows creating better looking modifiers which feel more built-in. No functionality is removed by this patch. The following changes are done: * The `Output Attributes` panel is hidden when there are no output attributes. * The `Internal Dependencies` panel is replaced by a new `Manage` panel that contains all the stuff that is common to all geometry nodes modifiers. It contains new `Bake` and `Named Attributes` panels for now. Potential next steps: * Merge `Output Attributes` panel with the rest of the input list. * Support hiding the `Manage` panel under some circumstances. Pull Request: https://projects.blender.org/blender/blender/pulls/117170
2024-01-17 13:40:30 +01:00
static bool has_output_attribute(const NodesModifierData &nmd)
{
if (!nmd.node_group) {
return false;
}
for (const bNodeTreeInterfaceSocket *interface_socket : nmd.node_group->interface_outputs()) {
Cleanup: Move BKE_node to namespace Move all header file into namespace. Unnecessary namespaces was removed from implementations file. Part of forward declarations in header was moved in the top part of file just to do not have a lot of separate namespaces. Pull Request: https://projects.blender.org/blender/blender/pulls/121637
2024-05-13 16:07:12 +02:00
const bke::bNodeSocketType *typeinfo = interface_socket->socket_typeinfo();
Geometry Nodes: reorganize panels in modifier The goal is to simplify the interface of the geometry nodes modifier while also making it more scalable. This allows creating better looking modifiers which feel more built-in. No functionality is removed by this patch. The following changes are done: * The `Output Attributes` panel is hidden when there are no output attributes. * The `Internal Dependencies` panel is replaced by a new `Manage` panel that contains all the stuff that is common to all geometry nodes modifiers. It contains new `Bake` and `Named Attributes` panels for now. Potential next steps: * Merge `Output Attributes` panel with the rest of the input list. * Support hiding the `Manage` panel under some circumstances. Pull Request: https://projects.blender.org/blender/blender/pulls/117170
2024-01-17 13:40:30 +01:00
const eNodeSocketDatatype type = typeinfo ? eNodeSocketDatatype(typeinfo->type) : SOCK_CUSTOM;
if (nodes::socket_type_has_attribute_toggle(type)) {
return true;
}
}
return false;
}
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
static void draw_output_attributes_panel(DrawGroupInputsContext &ctx, uiLayout *layout)
Geometry Nodes: Move output attribute names to a subpanel In a sub-panel it will be clearer that they are outputs, since they just look like more inputs now. Unfortunately it is not possible to make sub-panels display conditionally currently, so the output sub-panel will always be visible whether or not it is empty. Differential Revision: https://developer.blender.org/D12653
2021-09-27 13:04:58 -05:00
{
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
if (ctx.nmd.node_group != nullptr && ctx.nmd.settings.properties != nullptr) {
for (const bNodeTreeInterfaceSocket *socket : ctx.nmd.node_group->interface_outputs()) {
Cleanup: Move BKE_node to namespace Move all header file into namespace. Unnecessary namespaces was removed from implementations file. Part of forward declarations in header was moved in the top part of file just to do not have a lot of separate namespaces. Pull Request: https://projects.blender.org/blender/blender/pulls/121637
2024-05-13 16:07:12 +02:00
const bke::bNodeSocketType *typeinfo = socket->socket_typeinfo();
Nodes: Panels integration with blend files and UI Part 3/3 of #109135, #110272 Switch to new node group interfaces and deprecate old DNA and API. This completes support for panels in node drawing and in node group interface declarations in particular. The new node group interface DNA and RNA code has been added in parts 1 and 2 (#110885, #110952) but has not be enabled yet. This commit completes the integration by * enabling the new RNA API * using the new API in UI * read/write new interfaces from blend files * add versioning for backward compatibility * add forward-compatible writing code to reconstruct old interfaces All places accessing node group interface declarations should now be using the new API. A runtime cache has been added that allows simple linear access to socket inputs and outputs even when a panel hierarchy is used. Old DNA has been deprecated and should only be accessed for versioning (inputs/outputs renamed to inputs_legacy/outputs_legacy to catch errors). Versioning code ensures both backward and forward compatibility of existing files. The API for old interfaces is removed. The new API is very similar but is defined on the `ntree.interface` instead of the `ntree` directly. Breaking change notifications and detailed instructions for migrating will be added. A python test has been added for the node group API functions. This includes new functionality such as creating panels and moving items between different levels. This patch does not yet contain panel representations in the modifier UI. This has been tested in a separate branch and will be added with a later PR (#108565). Pull Request: https://projects.blender.org/blender/blender/pulls/111348
2023-08-30 12:37:21 +02:00
const eNodeSocketDatatype type = typeinfo ? eNodeSocketDatatype(typeinfo->type) :
SOCK_CUSTOM;
if (nodes::socket_type_has_attribute_toggle(type)) {
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
draw_property_for_output_socket(ctx, layout, *socket);
Geometry Nodes: Move output attribute names to a subpanel In a sub-panel it will be clearer that they are outputs, since they just look like more inputs now. Unfortunately it is not possible to make sub-panels display conditionally currently, so the output sub-panel will always be visible whether or not it is empty. Differential Revision: https://developer.blender.org/D12653
2021-09-27 13:04:58 -05:00
}
}
}
}
Geometry Nodes: reorganize panels in modifier The goal is to simplify the interface of the geometry nodes modifier while also making it more scalable. This allows creating better looking modifiers which feel more built-in. No functionality is removed by this patch. The following changes are done: * The `Output Attributes` panel is hidden when there are no output attributes. * The `Internal Dependencies` panel is replaced by a new `Manage` panel that contains all the stuff that is common to all geometry nodes modifiers. It contains new `Bake` and `Named Attributes` panels for now. Potential next steps: * Merge `Output Attributes` panel with the rest of the input list. * Support hiding the `Manage` panel under some circumstances. Pull Request: https://projects.blender.org/blender/blender/pulls/117170
2024-01-17 13:40:30 +01:00
static void draw_bake_panel(uiLayout *layout, PointerRNA *modifier_ptr)
Geometry Nodes: show used named attributes in modifier This adds a new subpanel to the geometry nodes modifier which is just used to display information about used attributes. * A new panel is used because adding this information anywhere else clutters the ui too much imo. * The general layout is similar to that in the tooltip. I found it to be more trouble than it's worth to share this code. Possible future improvements: * Don't show the panel if there are no used named attributes. * Add some heuristics to determine which named attributes the user does not have to care about because they are only used in the node group and don't affect anything else. Differential Revision: https://developer.blender.org/D14701
2022-04-21 15:10:07 +02:00
{
Refactor: UI: Replace uiLayoutColumn with class method uiLayout::column This converts the public `uiLayoutColumn` function to an object oriented API (`uiLayout::column`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::column` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Pull Request: https://projects.blender.org/blender/blender/pulls/138034
2025-04-26 21:07:34 +02:00
uiLayout *col = &layout->column(false);
UI: Use property split for geometry nodes modifier bake path
2023-06-12 12:06:14 -04:00
uiLayoutSetPropSep(col, true);
uiLayoutSetPropDecorate(col, false);
Refactor: UI: Replace uiItemR with class method uiLayout::prop This converts the public `uiItemR` function to an object oriented API (`uiLayout::prop`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138617
2025-05-08 20:45:37 +02:00
col->prop(modifier_ptr, "bake_target", UI_ITEM_NONE, std::nullopt, ICON_NONE);
col->prop(modifier_ptr, "bake_directory", UI_ITEM_NONE, IFACE_("Bake Path"), ICON_NONE);
Geometry Nodes: reorganize panels in modifier The goal is to simplify the interface of the geometry nodes modifier while also making it more scalable. This allows creating better looking modifiers which feel more built-in. No functionality is removed by this patch. The following changes are done: * The `Output Attributes` panel is hidden when there are no output attributes. * The `Internal Dependencies` panel is replaced by a new `Manage` panel that contains all the stuff that is common to all geometry nodes modifiers. It contains new `Bake` and `Named Attributes` panels for now. Potential next steps: * Merge `Output Attributes` panel with the rest of the input list. * Support hiding the `Manage` panel under some circumstances. Pull Request: https://projects.blender.org/blender/blender/pulls/117170
2024-01-17 13:40:30 +01:00
}
Geometry Nodes: expose simulation bake path in UI Longer term we want to have a more centralized place where the bake paths can be managed, but this is what we can still add in bcon3. Pull Request: https://projects.blender.org/blender/blender/pulls/108220
2023-05-25 18:56:00 +02:00
Geometry Nodes: reorganize panels in modifier The goal is to simplify the interface of the geometry nodes modifier while also making it more scalable. This allows creating better looking modifiers which feel more built-in. No functionality is removed by this patch. The following changes are done: * The `Output Attributes` panel is hidden when there are no output attributes. * The `Internal Dependencies` panel is replaced by a new `Manage` panel that contains all the stuff that is common to all geometry nodes modifiers. It contains new `Bake` and `Named Attributes` panels for now. Potential next steps: * Merge `Output Attributes` panel with the rest of the input list. * Support hiding the `Manage` panel under some circumstances. Pull Request: https://projects.blender.org/blender/blender/pulls/117170
2024-01-17 13:40:30 +01:00
static void draw_named_attributes_panel(uiLayout *layout, NodesModifierData &nmd)
{
Fix: Geometry Nodes: crash when accessing runtime data while baking Some editors are not redrawn while baking, but the properties editor currently is and therefore needs this special check. Eventually, we should rename or split the `is_rendering` flag to make it more obvious that it also means baking.
2024-12-04 20:00:27 +01:00
if (G.is_rendering) {
/* Avoid accessing this data while baking in a separate thread. */
return;
}
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
geo_log::GeoTreeLog *tree_log = get_root_tree_log(nmd);
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
if (tree_log == nullptr) {
Geometry Nodes: show used named attributes in modifier This adds a new subpanel to the geometry nodes modifier which is just used to display information about used attributes. * A new panel is used because adding this information anywhere else clutters the ui too much imo. * The general layout is similar to that in the tooltip. I found it to be more trouble than it's worth to share this code. Possible future improvements: * Don't show the panel if there are no used named attributes. * Add some heuristics to determine which named attributes the user does not have to care about because they are only used in the node group and don't affect anything else. Differential Revision: https://developer.blender.org/D14701
2022-04-21 15:10:07 +02:00
return;
}
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
tree_log->ensure_used_named_attributes();
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
const Map<StringRefNull, geo_log::NamedAttributeUsage> &usage_by_attribute =
Geometry Nodes: new evaluation system This refactors the geometry nodes evaluation system. No changes for the user are expected. At a high level the goals are: * Support using geometry nodes outside of the geometry nodes modifier. * Support using the evaluator infrastructure for other purposes like field evaluation. * Support more nodes, especially when many of them are disabled behind switch nodes. * Support doing preprocessing on node groups. For more details see T98492. There are fairly detailed comments in the code, but here is a high level overview for how it works now: * There is a new "lazy-function" system. It is similar in spirit to the multi-function system but with different goals. Instead of optimizing throughput for highly parallelizable work, this system is designed to compute only the data that is actually necessary. What data is necessary can be determined dynamically during evaluation. Many lazy-functions can be composed in a graph to form a new lazy-function, which can again be used in a graph etc. * Each geometry node group is converted into a lazy-function graph prior to evaluation. To evaluate geometry nodes, one then just has to evaluate that graph. Node groups are no longer inlined into their parents. Next steps for the evaluation system is to reduce the use of threads in some situations to avoid overhead. Many small node groups don't benefit from multi-threading at all. This is much easier to do now because not everything has to be inlined in one huge node tree anymore. Differential Revision: https://developer.blender.org/D15914
2022-09-13 08:44:26 +02:00
tree_log->used_named_attributes;
Geometry Nodes: show used named attributes in modifier This adds a new subpanel to the geometry nodes modifier which is just used to display information about used attributes. * A new panel is used because adding this information anywhere else clutters the ui too much imo. * The general layout is similar to that in the tooltip. I found it to be more trouble than it's worth to share this code. Possible future improvements: * Don't show the panel if there are no used named attributes. * Add some heuristics to determine which named attributes the user does not have to care about because they are only used in the node group and don't affect anything else. Differential Revision: https://developer.blender.org/D14701
2022-04-21 15:10:07 +02:00
if (usage_by_attribute.is_empty()) {
Refactor: UI: Replace uiItemL with class method uiLayout::label This converts the public `uiItemL` function to an object oriented API (`uiLayout::label`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138608
2025-05-08 17:21:08 +02:00
layout->label(RPT_("No named attributes used"), ICON_INFO);
Geometry Nodes: show used named attributes in modifier This adds a new subpanel to the geometry nodes modifier which is just used to display information about used attributes. * A new panel is used because adding this information anywhere else clutters the ui too much imo. * The general layout is similar to that in the tooltip. I found it to be more trouble than it's worth to share this code. Possible future improvements: * Don't show the panel if there are no used named attributes. * Add some heuristics to determine which named attributes the user does not have to care about because they are only used in the node group and don't affect anything else. Differential Revision: https://developer.blender.org/D14701
2022-04-21 15:10:07 +02:00
return;
}
Fix: use natural string sorting for attribute names
2022-04-25 16:00:43 +02:00
struct NameWithUsage {
StringRefNull name;
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
geo_log::NamedAttributeUsage usage;
Fix: use natural string sorting for attribute names
2022-04-25 16:00:43 +02:00
};
Vector<NameWithUsage> sorted_used_attribute;
Geometry Nodes: show used named attributes in modifier This adds a new subpanel to the geometry nodes modifier which is just used to display information about used attributes. * A new panel is used because adding this information anywhere else clutters the ui too much imo. * The general layout is similar to that in the tooltip. I found it to be more trouble than it's worth to share this code. Possible future improvements: * Don't show the panel if there are no used named attributes. * Add some heuristics to determine which named attributes the user does not have to care about because they are only used in the node group and don't affect anything else. Differential Revision: https://developer.blender.org/D14701
2022-04-21 15:10:07 +02:00
for (auto &&item : usage_by_attribute.items()) {
sorted_used_attribute.append({item.key, item.value});
}
Fix: use natural string sorting for attribute names
2022-04-25 16:00:43 +02:00
std::sort(sorted_used_attribute.begin(),
sorted_used_attribute.end(),
[](const NameWithUsage &a, const NameWithUsage &b) {
Fix: update comparator for std::sort for NamedAttribute This PR applies a fix for the comparator being passed into std::sort to avoid potential Mac / libc++ issues as seen in #119189 Pull Request: https://projects.blender.org/blender/blender/pulls/119385
2024-03-12 17:31:02 +01:00
return BLI_strcasecmp_natural(a.name.c_str(), b.name.c_str()) < 0;
Fix: use natural string sorting for attribute names
2022-04-25 16:00:43 +02:00
});
Geometry Nodes: show used named attributes in modifier This adds a new subpanel to the geometry nodes modifier which is just used to display information about used attributes. * A new panel is used because adding this information anywhere else clutters the ui too much imo. * The general layout is similar to that in the tooltip. I found it to be more trouble than it's worth to share this code. Possible future improvements: * Don't show the panel if there are no used named attributes. * Add some heuristics to determine which named attributes the user does not have to care about because they are only used in the node group and don't affect anything else. Differential Revision: https://developer.blender.org/D14701
2022-04-21 15:10:07 +02:00
Fix: use natural string sorting for attribute names
2022-04-25 16:00:43 +02:00
for (const NameWithUsage &attribute : sorted_used_attribute) {
Cleanup: Use StringRef and std::optional for UI string arguments - Gives O(1) access to string length in more cases - Convenient string manipulation functions - Clarify difference between "no string" and "empty string" - Avoid the need for raw pointers in the API - Shows which API string arguments are optional Pull Request: https://projects.blender.org/blender/blender/pulls/131473
2024-12-06 14:08:10 +01:00
const StringRef attribute_name = attribute.name;
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
const geo_log::NamedAttributeUsage usage = attribute.usage;
Geometry Nodes: show used named attributes in modifier This adds a new subpanel to the geometry nodes modifier which is just used to display information about used attributes. * A new panel is used because adding this information anywhere else clutters the ui too much imo. * The general layout is similar to that in the tooltip. I found it to be more trouble than it's worth to share this code. Possible future improvements: * Don't show the panel if there are no used named attributes. * Add some heuristics to determine which named attributes the user does not have to care about because they are only used in the node group and don't affect anything else. Differential Revision: https://developer.blender.org/D14701
2022-04-21 15:10:07 +02:00
/* #uiLayoutRowWithHeading doesn't seem to work in this case. */
Refactor: UI: Replace uiLayoutSplit with class method uiLayout::split This converts the public `uiLayoutSplit` function to an object oriented API (`uiLayout::split`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::split` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Pull Request: https://projects.blender.org/blender/blender/pulls/138361
2025-05-03 20:51:42 +02:00
uiLayout *split = &layout->split(0.4f, false);
Geometry Nodes: show used named attributes in modifier This adds a new subpanel to the geometry nodes modifier which is just used to display information about used attributes. * A new panel is used because adding this information anywhere else clutters the ui too much imo. * The general layout is similar to that in the tooltip. I found it to be more trouble than it's worth to share this code. Possible future improvements: * Don't show the panel if there are no used named attributes. * Add some heuristics to determine which named attributes the user does not have to care about because they are only used in the node group and don't affect anything else. Differential Revision: https://developer.blender.org/D14701
2022-04-21 15:10:07 +02:00
std::stringstream ss;
Vector<std::string> usages;
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
if ((usage & geo_log::NamedAttributeUsage::Read) != geo_log::NamedAttributeUsage::None) {
I18n: Go over TIP_ and IFACE_ usages, change to RPT_ when relevant The previous commit introduced a new `RPT_()` macro to translate strings which are not tooltips or regular interface elements, but longer reports or statuses. This commit uses the new macro to translate many strings all over the UI. Most of it is a simple replace from `TIP_()` or `IFACE_()` to `RPT_()`, but there are some additional changes: - A few translations inside `BKE_report()` are removed altogether because they are already handled by the translation system. - Messages inside `UI_but_disable()` are no longer translated manually, but they are handled by a new regex in the translation system. Pull Request: https://projects.blender.org/blender/blender/pulls/116804 Pull Request: https://projects.blender.org/blender/blender/pulls/116804
2024-01-11 19:49:03 +01:00
usages.append(IFACE_("Read"));
Geometry Nodes: show used named attributes in modifier This adds a new subpanel to the geometry nodes modifier which is just used to display information about used attributes. * A new panel is used because adding this information anywhere else clutters the ui too much imo. * The general layout is similar to that in the tooltip. I found it to be more trouble than it's worth to share this code. Possible future improvements: * Don't show the panel if there are no used named attributes. * Add some heuristics to determine which named attributes the user does not have to care about because they are only used in the node group and don't affect anything else. Differential Revision: https://developer.blender.org/D14701
2022-04-21 15:10:07 +02:00
}
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
if ((usage & geo_log::NamedAttributeUsage::Write) != geo_log::NamedAttributeUsage::None) {
I18n: Go over TIP_ and IFACE_ usages, change to RPT_ when relevant The previous commit introduced a new `RPT_()` macro to translate strings which are not tooltips or regular interface elements, but longer reports or statuses. This commit uses the new macro to translate many strings all over the UI. Most of it is a simple replace from `TIP_()` or `IFACE_()` to `RPT_()`, but there are some additional changes: - A few translations inside `BKE_report()` are removed altogether because they are already handled by the translation system. - Messages inside `UI_but_disable()` are no longer translated manually, but they are handled by a new regex in the translation system. Pull Request: https://projects.blender.org/blender/blender/pulls/116804 Pull Request: https://projects.blender.org/blender/blender/pulls/116804
2024-01-11 19:49:03 +01:00
usages.append(IFACE_("Write"));
Geometry Nodes: show used named attributes in modifier This adds a new subpanel to the geometry nodes modifier which is just used to display information about used attributes. * A new panel is used because adding this information anywhere else clutters the ui too much imo. * The general layout is similar to that in the tooltip. I found it to be more trouble than it's worth to share this code. Possible future improvements: * Don't show the panel if there are no used named attributes. * Add some heuristics to determine which named attributes the user does not have to care about because they are only used in the node group and don't affect anything else. Differential Revision: https://developer.blender.org/D14701
2022-04-21 15:10:07 +02:00
}
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
if ((usage & geo_log::NamedAttributeUsage::Remove) != geo_log::NamedAttributeUsage::None) {
I18n: Extract and disambiguate a few messages Extract - Cycles denoiser enum. - Extensions user preferences UI. - Node operator poll message from new node function. Improve - Split "(Enabled|Disabled) on startup, overriding the preference." into two messages. Disambiguate - "Add" when describing the action of adding something should use the Operator context. - "Dimensions", in noise textures. - "Transform" as a noun, the matrix transform type of Geometry Nodes, as opposed to the verb to move things in space. - "Parent" as a noun or verb (the parent of an object, to parent an object to another). Some issues reported by Satoshi Yamasaki, deathblood, and Gabriel Gazzán. Pull Request: https://projects.blender.org/blender/blender/pulls/122969
2024-06-13 12:15:55 +02:00
usages.append(CTX_IFACE_(BLT_I18NCONTEXT_OPERATOR_DEFAULT, "Remove"));
Geometry Nodes: show used named attributes in modifier This adds a new subpanel to the geometry nodes modifier which is just used to display information about used attributes. * A new panel is used because adding this information anywhere else clutters the ui too much imo. * The general layout is similar to that in the tooltip. I found it to be more trouble than it's worth to share this code. Possible future improvements: * Don't show the panel if there are no used named attributes. * Add some heuristics to determine which named attributes the user does not have to care about because they are only used in the node group and don't affect anything else. Differential Revision: https://developer.blender.org/D14701
2022-04-21 15:10:07 +02:00
}
for (const int i : usages.index_range()) {
ss << usages[i];
if (i < usages.size() - 1) {
ss << ", ";
}
}
Refactor: UI: Replace uiLayoutRow with class method uiLayout::row This converts the public `uiLayoutRow` function to an object oriented API (`uiLayout::row`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::row` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/137979
2025-04-25 19:45:25 +02:00
uiLayout *row = &split->row(false);
Geometry Nodes: show used named attributes in modifier This adds a new subpanel to the geometry nodes modifier which is just used to display information about used attributes. * A new panel is used because adding this information anywhere else clutters the ui too much imo. * The general layout is similar to that in the tooltip. I found it to be more trouble than it's worth to share this code. Possible future improvements: * Don't show the panel if there are no used named attributes. * Add some heuristics to determine which named attributes the user does not have to care about because they are only used in the node group and don't affect anything else. Differential Revision: https://developer.blender.org/D14701
2022-04-21 15:10:07 +02:00
uiLayoutSetAlignment(row, UI_LAYOUT_ALIGN_RIGHT);
uiLayoutSetActive(row, false);
Refactor: UI: Replace uiItemL with class method uiLayout::label This converts the public `uiItemL` function to an object oriented API (`uiLayout::label`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138608
2025-05-08 17:21:08 +02:00
row->label(ss.str(), ICON_NONE);
Geometry Nodes: show used named attributes in modifier This adds a new subpanel to the geometry nodes modifier which is just used to display information about used attributes. * A new panel is used because adding this information anywhere else clutters the ui too much imo. * The general layout is similar to that in the tooltip. I found it to be more trouble than it's worth to share this code. Possible future improvements: * Don't show the panel if there are no used named attributes. * Add some heuristics to determine which named attributes the user does not have to care about because they are only used in the node group and don't affect anything else. Differential Revision: https://developer.blender.org/D14701
2022-04-21 15:10:07 +02:00
Refactor: UI: Replace uiLayoutRow with class method uiLayout::row This converts the public `uiLayoutRow` function to an object oriented API (`uiLayout::row`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::row` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/137979
2025-04-25 19:45:25 +02:00
row = &split->row(false);
Refactor: UI: Replace uiItemL with class method uiLayout::label This converts the public `uiItemL` function to an object oriented API (`uiLayout::label`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138608
2025-05-08 17:21:08 +02:00
row->label(attribute_name, ICON_NONE);
Geometry Nodes: show used named attributes in modifier This adds a new subpanel to the geometry nodes modifier which is just used to display information about used attributes. * A new panel is used because adding this information anywhere else clutters the ui too much imo. * The general layout is similar to that in the tooltip. I found it to be more trouble than it's worth to share this code. Possible future improvements: * Don't show the panel if there are no used named attributes. * Add some heuristics to determine which named attributes the user does not have to care about because they are only used in the node group and don't affect anything else. Differential Revision: https://developer.blender.org/D14701
2022-04-21 15:10:07 +02:00
}
}
Geometry Nodes: reorganize panels in modifier The goal is to simplify the interface of the geometry nodes modifier while also making it more scalable. This allows creating better looking modifiers which feel more built-in. No functionality is removed by this patch. The following changes are done: * The `Output Attributes` panel is hidden when there are no output attributes. * The `Internal Dependencies` panel is replaced by a new `Manage` panel that contains all the stuff that is common to all geometry nodes modifiers. It contains new `Bake` and `Named Attributes` panels for now. Potential next steps: * Merge `Output Attributes` panel with the rest of the input list. * Support hiding the `Manage` panel under some circumstances. Pull Request: https://projects.blender.org/blender/blender/pulls/117170
2024-01-17 13:40:30 +01:00
static void draw_manage_panel(const bContext *C,
uiLayout *layout,
PointerRNA *modifier_ptr,
NodesModifierData &nmd)
{
Refactor: UI: Replace uiLayoutPanelProp with class method uiLayout::panel_prop This converts the public `uiLayoutPanelProp` function to an object oriented API (`uiLayout::panel_prop`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Pull Request: https://projects.blender.org/blender/blender/pulls/138501
2025-05-06 17:13:30 +02:00
if (uiLayout *panel_layout = layout->panel_prop(
C, modifier_ptr, "open_bake_panel", IFACE_("Bake")))
Geometry Nodes: reorganize panels in modifier The goal is to simplify the interface of the geometry nodes modifier while also making it more scalable. This allows creating better looking modifiers which feel more built-in. No functionality is removed by this patch. The following changes are done: * The `Output Attributes` panel is hidden when there are no output attributes. * The `Internal Dependencies` panel is replaced by a new `Manage` panel that contains all the stuff that is common to all geometry nodes modifiers. It contains new `Bake` and `Named Attributes` panels for now. Potential next steps: * Merge `Output Attributes` panel with the rest of the input list. * Support hiding the `Manage` panel under some circumstances. Pull Request: https://projects.blender.org/blender/blender/pulls/117170
2024-01-17 13:40:30 +01:00
{
draw_bake_panel(panel_layout, modifier_ptr);
}
Refactor: UI: Replace uiLayoutPanelProp with class method uiLayout::panel_prop This converts the public `uiLayoutPanelProp` function to an object oriented API (`uiLayout::panel_prop`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Pull Request: https://projects.blender.org/blender/blender/pulls/138501
2025-05-06 17:13:30 +02:00
if (uiLayout *panel_layout = layout->panel_prop(
C, modifier_ptr, "open_named_attributes_panel", IFACE_("Named Attributes")))
Geometry Nodes: reorganize panels in modifier The goal is to simplify the interface of the geometry nodes modifier while also making it more scalable. This allows creating better looking modifiers which feel more built-in. No functionality is removed by this patch. The following changes are done: * The `Output Attributes` panel is hidden when there are no output attributes. * The `Internal Dependencies` panel is replaced by a new `Manage` panel that contains all the stuff that is common to all geometry nodes modifiers. It contains new `Bake` and `Named Attributes` panels for now. Potential next steps: * Merge `Output Attributes` panel with the rest of the input list. * Support hiding the `Manage` panel under some circumstances. Pull Request: https://projects.blender.org/blender/blender/pulls/117170
2024-01-17 13:40:30 +01:00
{
draw_named_attributes_panel(panel_layout, nmd);
}
}
Geometry Nodes: improve display of node warnings in modifier This does the following changes: * Show info "warnings" in modifier too. Previously those were skipped. The different behavior of info/warning/error messages causes confusion. * Add a new `Warnings` panel that only shows when there are warnings. In its title, it shows how many warnings there are. * In the panel, warnings are sorted by severity and alphabetically. Pull Request: https://projects.blender.org/blender/blender/pulls/128395
2024-10-01 15:31:50 +02:00
static void draw_warnings(const bContext *C,
const NodesModifierData &nmd,
uiLayout *layout,
PointerRNA *md_ptr)
{
Fix: Geometry Nodes: crash when accessing runtime data while baking Some editors are not redrawn while baking, but the properties editor currently is and therefore needs this special check. Eventually, we should rename or split the `is_rendering` flag to make it more obvious that it also means baking.
2024-12-04 20:00:27 +01:00
if (G.is_rendering) {
/* Avoid accessing this data while baking in a separate thread. */
return;
}
Geometry Nodes: improve display of node warnings in modifier This does the following changes: * Show info "warnings" in modifier too. Previously those were skipped. The different behavior of info/warning/error messages causes confusion. * Add a new `Warnings` panel that only shows when there are warnings. In its title, it shows how many warnings there are. * In the panel, warnings are sorted by severity and alphabetically. Pull Request: https://projects.blender.org/blender/blender/pulls/128395
2024-10-01 15:31:50 +02:00
using namespace geo_log;
GeoTreeLog *tree_log = get_root_tree_log(nmd);
if (!tree_log) {
return;
}
Refactor: Geometry Nodes: store tree identifier in tree logger The main goal here is to add `GeoTreeLogger.tree_orig_session_uid`. Previously, it was always possible to derive this information in `ensure_node_warnings`. However, with closures that's not possible in general anymore, because the Evaluate Closure node does not know statically which node tree the closure zone is from that it evaluates. Therefore, this information has to be logged as well. This patch initializes `tree_orig_session_uid` the same way it initializes `parent_node_id`, by scanning the compute context when creating the tree logger. To make this work properly, some extra contextual data had to be stored in some compute contexts. This is just a refactor with no expected functional changes. Node warnings for closures are still not properly logged, because that requires storing source-location data in closures, which will be implemented separately. Pull Request: https://projects.blender.org/blender/blender/pulls/137208
2025-04-10 08:56:02 +02:00
tree_log->ensure_node_warnings(*CTX_data_main(C));
Geometry Nodes: improve display of node warnings in modifier This does the following changes: * Show info "warnings" in modifier too. Previously those were skipped. The different behavior of info/warning/error messages causes confusion. * Add a new `Warnings` panel that only shows when there are warnings. In its title, it shows how many warnings there are. * In the panel, warnings are sorted by severity and alphabetically. Pull Request: https://projects.blender.org/blender/blender/pulls/128395
2024-10-01 15:31:50 +02:00
const int warnings_num = tree_log->all_warnings.size();
if (warnings_num == 0) {
return;
}
Refactor: UI: Replace uiLayoutPanelProp with class method uiLayout::panel_prop This converts the public `uiLayoutPanelProp` function to an object oriented API (`uiLayout::panel_prop`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Pull Request: https://projects.blender.org/blender/blender/pulls/138501
2025-05-06 17:13:30 +02:00
PanelLayout panel = layout->panel_prop(C, md_ptr, "open_warnings_panel");
Refactor: UI: Replace uiItemL with class method uiLayout::label This converts the public `uiItemL` function to an object oriented API (`uiLayout::label`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138608
2025-05-08 17:21:08 +02:00
panel.header->label(fmt::format(fmt::runtime(IFACE_("Warnings ({})")), warnings_num).c_str(),
ICON_NONE);
Geometry Nodes: improve display of node warnings in modifier This does the following changes: * Show info "warnings" in modifier too. Previously those were skipped. The different behavior of info/warning/error messages causes confusion. * Add a new `Warnings` panel that only shows when there are warnings. In its title, it shows how many warnings there are. * In the panel, warnings are sorted by severity and alphabetically. Pull Request: https://projects.blender.org/blender/blender/pulls/128395
2024-10-01 15:31:50 +02:00
if (!panel.body) {
return;
}
Vector<const NodeWarning *> warnings(tree_log->all_warnings.size());
for (const int i : warnings.index_range()) {
warnings[i] = &tree_log->all_warnings[i];
}
std::sort(warnings.begin(), warnings.end(), [](const NodeWarning *a, const NodeWarning *b) {
const int severity_a = node_warning_type_severity(a->type);
const int severity_b = node_warning_type_severity(b->type);
if (severity_a > severity_b) {
return true;
}
if (severity_a < severity_b) {
return false;
}
return BLI_strcasecmp_natural(a->message.c_str(), b->message.c_str()) < 0;
});
Refactor: UI: Replace uiLayoutColumn with class method uiLayout::column This converts the public `uiLayoutColumn` function to an object oriented API (`uiLayout::column`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. `uiLayout::column` now returns an `uiLayout` reference instead of a pointer. New calls to this method should use references too. Pull Request: https://projects.blender.org/blender/blender/pulls/138034
2025-04-26 21:07:34 +02:00
uiLayout *col = &panel.body->column(false);
Geometry Nodes: improve display of node warnings in modifier This does the following changes: * Show info "warnings" in modifier too. Previously those were skipped. The different behavior of info/warning/error messages causes confusion. * Add a new `Warnings` panel that only shows when there are warnings. In its title, it shows how many warnings there are. * In the panel, warnings are sorted by severity and alphabetically. Pull Request: https://projects.blender.org/blender/blender/pulls/128395
2024-10-01 15:31:50 +02:00
for (const NodeWarning *warning : warnings) {
const int icon = node_warning_type_icon(warning->type);
Refactor: UI: Replace uiItemL with class method uiLayout::label This converts the public `uiItemL` function to an object oriented API (`uiLayout::label`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Part of: #117604 Pull Request: https://projects.blender.org/blender/blender/pulls/138608
2025-05-08 17:21:08 +02:00
col->label(warning->message, icon);
Geometry Nodes: improve display of node warnings in modifier This does the following changes: * Show info "warnings" in modifier too. Previously those were skipped. The different behavior of info/warning/error messages causes confusion. * Add a new `Warnings` panel that only shows when there are warnings. In its title, it shows how many warnings there are. * In the panel, warnings are sorted by severity and alphabetically. Pull Request: https://projects.blender.org/blender/blender/pulls/128395
2024-10-01 15:31:50 +02:00
}
}
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
static void panel_draw(const bContext *C, Panel *panel)
{
uiLayout *layout = panel->layout;
PointerRNA *ptr = modifier_panel_get_property_pointers(panel, nullptr);
NodesModifierData *nmd = static_cast<NodesModifierData *>(ptr->data);
uiLayoutSetPropSep(layout, true);
/* Decorators are added manually for supported properties because the
* attribute/value toggle requires a manually built layout anyway. */
uiLayoutSetPropDecorate(layout, false);
if (!(nmd->flag & NODES_MODIFIER_HIDE_DATABLOCK_SELECTOR)) {
Fix #118395: use copy instead of new for geometry nodes in modifiers list Now it behaves the same as the materials list UI. Pull Request: https://projects.blender.org/blender/blender/pulls/118420
2024-02-20 18:43:40 +01:00
const char *newop = (nmd->node_group == nullptr) ? "node.new_geometry_node_group_assign" :
"object.geometry_node_tree_copy_assign";
Cleanup: UI: Use default arguments for rarely used template options These arguments are almost never used. Default arguments can make the invokations quite a bit simpler.
2024-09-17 12:22:18 +02:00
uiTemplateID(layout, C, ptr, "node_group", newop, nullptr, nullptr);
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
}
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
Main *bmain = CTX_data_main(C);
PointerRNA bmain_ptr = RNA_main_pointer_create(bmain);
Geometry Nodes: Improve performance with many inputs Resolves #136183 To avoid quadratic worst case runtime when gathering values from the modifier properties, build a temporary VectorSet of the modifier's IDProperties. In the file from #136183, this change improves playback performance by 1.4x for me, from 50 to 70ms. Ideally IDProperty groups would have constant time lookup on their own, but that's a much larger change, and this smaller change for just Geometry Nodes is not so invasive. Pull Request: https://projects.blender.org/blender/blender/pulls/136463
2025-03-25 15:40:32 +01:00
DrawGroupInputsContext ctx{
*C, *nmd, nodes::build_properties_vector_set(nmd->settings.properties), ptr, &bmain_ptr};
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
if (nmd->node_group != nullptr && nmd->settings.properties != nullptr) {
nmd->node_group->ensure_interface_cache();
Nodes: automatically gray out input values that don't affect the output This patch automatically grays out input values which can't affect the output currently. It works with inputs of group nodes, geometry nodes modifiers and node tools. To achieve this, it analyses the node tree and partially evaluates it to figure out which group inputs are currently not linked to an output or are disabled by e.g. some switch node. Original proposal: https://devtalk.blender.org/t/dynamic-socket-visibility/31874 Related info in blog post: https://code.blender.org/2023/11/geometry-nodes-workshop-november-2023/#dynamic-socket-visibility Follow up task for designing a UI that allows hiding sockets: #132706 Limitations: * The inferencing does not update correctly when a socket starts being animated/driven. I haven't found a good way to invalidate the cache in a good way reliably yet. It's only a very short term problem though. It fixes itself after the next modification of the node tree and is only noticeable when animating some specific sockets such as the switch node condition. * Whether a socket is grayed out is not exposed in the Python API yet. That will be done separately. * Only a partial evaluation is done to determine if an input affects an output. There should be no cases where a socket is found to be unused when it can actually affect the output. However, there can be cases where a socket is inferenced to be used even if it is not due to some complex condition. Depending on the exact circumstances, this can either be improved or the condition in the node tree should be simplified. Pull Request: https://projects.blender.org/blender/blender/pulls/132219
2025-01-21 12:53:24 +01:00
ctx.input_usages.reinitialize(nmd->node_group->interface_inputs().size());
nodes::socket_usage_inference::infer_group_interface_inputs_usage(
Geometry Nodes: Improve performance with many inputs Resolves #136183 To avoid quadratic worst case runtime when gathering values from the modifier properties, build a temporary VectorSet of the modifier's IDProperties. In the file from #136183, this change improves playback performance by 1.4x for me, from 50 to 70ms. Ideally IDProperty groups would have constant time lookup on their own, but that's a much larger change, and this smaller change for just Geometry Nodes is not so invasive. Pull Request: https://projects.blender.org/blender/blender/pulls/136463
2025-03-25 15:40:32 +01:00
*nmd->node_group, ctx.properties, ctx.input_usages);
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
draw_interface_panel_content(ctx, layout, nmd->node_group->tree_interface.root_panel);
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
}
Cleanup: Modifiers: rename function to draw modifier error message The old name `modifier_panel_end` was not great because: * There is no corresponding `*_begin`. * It sounds more magical then it really is (it just draws the error message). * It doesn't even have to be at the end as is sometimes the case when there are subpanels. Pull Request: https://projects.blender.org/blender/blender/pulls/138797
2025-05-13 17:27:30 +02:00
modifier_error_message_draw(layout, ptr);
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
Geometry Nodes: improve display of node warnings in modifier This does the following changes: * Show info "warnings" in modifier too. Previously those were skipped. The different behavior of info/warning/error messages causes confusion. * Add a new `Warnings` panel that only shows when there are warnings. In its title, it shows how many warnings there are. * In the panel, warnings are sorted by severity and alphabetically. Pull Request: https://projects.blender.org/blender/blender/pulls/128395
2024-10-01 15:31:50 +02:00
draw_warnings(C, *nmd, layout, ptr);
Geometry Nodes: reorganize panels in modifier The goal is to simplify the interface of the geometry nodes modifier while also making it more scalable. This allows creating better looking modifiers which feel more built-in. No functionality is removed by this patch. The following changes are done: * The `Output Attributes` panel is hidden when there are no output attributes. * The `Internal Dependencies` panel is replaced by a new `Manage` panel that contains all the stuff that is common to all geometry nodes modifiers. It contains new `Bake` and `Named Attributes` panels for now. Potential next steps: * Merge `Output Attributes` panel with the rest of the input list. * Support hiding the `Manage` panel under some circumstances. Pull Request: https://projects.blender.org/blender/blender/pulls/117170
2024-01-17 13:40:30 +01:00
if (has_output_attribute(*nmd)) {
Refactor: UI: Replace uiLayoutPanelProp with class method uiLayout::panel_prop This converts the public `uiLayoutPanelProp` function to an object oriented API (`uiLayout::panel_prop`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Pull Request: https://projects.blender.org/blender/blender/pulls/138501
2025-05-06 17:13:30 +02:00
if (uiLayout *panel_layout = layout->panel_prop(
C, ptr, "open_output_attributes_panel", IFACE_("Output Attributes")))
Geometry Nodes: reorganize panels in modifier The goal is to simplify the interface of the geometry nodes modifier while also making it more scalable. This allows creating better looking modifiers which feel more built-in. No functionality is removed by this patch. The following changes are done: * The `Output Attributes` panel is hidden when there are no output attributes. * The `Internal Dependencies` panel is replaced by a new `Manage` panel that contains all the stuff that is common to all geometry nodes modifiers. It contains new `Bake` and `Named Attributes` panels for now. Potential next steps: * Merge `Output Attributes` panel with the rest of the input list. * Support hiding the `Manage` panel under some circumstances. Pull Request: https://projects.blender.org/blender/blender/pulls/117170
2024-01-17 13:40:30 +01:00
{
Cleanup: simplify passing context to node functions This helps in the future when passing more data through these functions. For example, socket/panel usage information in #132219.
2024-12-23 12:49:56 +01:00
draw_output_attributes_panel(ctx, panel_layout);
Geometry Nodes: reorganize panels in modifier The goal is to simplify the interface of the geometry nodes modifier while also making it more scalable. This allows creating better looking modifiers which feel more built-in. No functionality is removed by this patch. The following changes are done: * The `Output Attributes` panel is hidden when there are no output attributes. * The `Internal Dependencies` panel is replaced by a new `Manage` panel that contains all the stuff that is common to all geometry nodes modifiers. It contains new `Bake` and `Named Attributes` panels for now. Potential next steps: * Merge `Output Attributes` panel with the rest of the input list. * Support hiding the `Manage` panel under some circumstances. Pull Request: https://projects.blender.org/blender/blender/pulls/117170
2024-01-17 13:40:30 +01:00
}
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
}
Refactor: UI: Replace uiLayoutPanelProp with class method uiLayout::panel_prop This converts the public `uiLayoutPanelProp` function to an object oriented API (`uiLayout::panel_prop`), matching the python API. This reduces the difference between the C++ API with the python version, its also helps while converting code from python to C++ code (or vice-versa), making it almost seamless. Pull Request: https://projects.blender.org/blender/blender/pulls/138501
2025-05-06 17:13:30 +02:00
if (uiLayout *panel_layout = layout->panel_prop(C, ptr, "open_manage_panel", IFACE_("Manage"))) {
Geometry Nodes: reorganize panels in modifier The goal is to simplify the interface of the geometry nodes modifier while also making it more scalable. This allows creating better looking modifiers which feel more built-in. No functionality is removed by this patch. The following changes are done: * The `Output Attributes` panel is hidden when there are no output attributes. * The `Internal Dependencies` panel is replaced by a new `Manage` panel that contains all the stuff that is common to all geometry nodes modifiers. It contains new `Bake` and `Named Attributes` panels for now. Potential next steps: * Merge `Output Attributes` panel with the rest of the input list. * Support hiding the `Manage` panel under some circumstances. Pull Request: https://projects.blender.org/blender/blender/pulls/117170
2024-01-17 13:40:30 +01:00
draw_manage_panel(C, panel_layout, ptr, *nmd);
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
}
}
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
static void panel_register(ARegionType *region_type)
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
{
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
using namespace blender;
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
modifier_panel_register(region_type, eModifierType_Nodes, panel_draw);
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
}
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
static void blend_write(BlendWriter *writer, const ID * /*id_owner*/, const ModifierData *md)
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
{
const NodesModifierData *nmd = reinterpret_cast<const NodesModifierData *>(md);
Refactor modifiers writing code. This changes is needed to give more control to modifiers' writing callback when defined. It will allow to implement better culling of needless data when writing e.g. modifiers from library overrides. Ref. T97967. Reviewed By: brecht, JacquesLucke Differential Revision: https://developer.blender.org/D14939
2022-05-16 16:00:00 +02:00
BLO_write_struct(writer, NodesModifierData, nmd);
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
BLO_write_string(writer, nmd->bake_directory);
Geometry Nodes: store path to simulation bake in modifier This adds `char *simulation_bake_directory` to the nodes modifier. The path is automatically generated the first time the modifier is baked. It is _not_ automatically changed afterwards. The path is relative to the .blend file by default. For now, the path is not exposed in the UI or Python API. This fixes issues where renaming objects/modifiers can cause the baked data to not work anymore. Pull Request: https://projects.blender.org/blender/blender/pulls/108201
2023-05-24 08:45:31 +02:00
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
if (nmd->settings.properties != nullptr) {
Geometry Nodes: Use checkbox for exposed boolean sockets This uses the changes from ef68a37e5d55e17adf4c to create IDProperties for exposed boolean sockets with a boolean type instead of an integer with a [0,1] range. Existing properties and values are converted automatically. For forward compatibility, the properties are switched to the integer type for saving. Otherwise older versions crash immediately when opening a newer file. The "Use Attribute" IDProperties aren't changed here, since that wouldn't have a visible benefit. Differential Revision: https://developer.blender.org/D12816
2023-01-20 17:36:07 -06:00
Map<IDProperty *, IDPropertyUIDataBool *> boolean_props;
Fix T104088: Geometry nodes modifier boolean lost on undo After object-mode undo (memfile undo), the value wan't lost, but the property would be temporarily converted back to integer type in order to be forward compatible. Now only use the forward compatible writing when writing undo steps. Auto-saves and similar files are currently not forward compatible anyway.
2023-01-23 15:06:55 -06:00
if (!BLO_write_is_undo(writer)) {
/* Boolean properties are added automatically for boolean node group inputs. Integer
* properties are automatically converted to boolean sockets where applicable as well.
* However, boolean properties will crash old versions of Blender, so convert them to integer
* properties for writing. The actual value is stored in the same variable for both types */
LISTBASE_FOREACH (IDProperty *, prop, &nmd->settings.properties->data.group) {
if (prop->type == IDP_BOOLEAN) {
boolean_props.add_new(prop, reinterpret_cast<IDPropertyUIDataBool *>(prop->ui_data));
prop->type = IDP_INT;
prop->ui_data = nullptr;
}
Geometry Nodes: Use checkbox for exposed boolean sockets This uses the changes from ef68a37e5d55e17adf4c to create IDProperties for exposed boolean sockets with a boolean type instead of an integer with a [0,1] range. Existing properties and values are converted automatically. For forward compatibility, the properties are switched to the integer type for saving. Otherwise older versions crash immediately when opening a newer file. The "Use Attribute" IDProperties aren't changed here, since that wouldn't have a visible benefit. Differential Revision: https://developer.blender.org/D12816
2023-01-20 17:36:07 -06:00
}
}
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
/* Note that the property settings are based on the socket type info
* and don't necessarily need to be written, but we can't just free them. */
IDP_BlendWrite(writer, nmd->settings.properties);
Geometry Nodes: Use checkbox for exposed boolean sockets This uses the changes from ef68a37e5d55e17adf4c to create IDProperties for exposed boolean sockets with a boolean type instead of an integer with a [0,1] range. Existing properties and values are converted automatically. For forward compatibility, the properties are switched to the integer type for saving. Otherwise older versions crash immediately when opening a newer file. The "Use Attribute" IDProperties aren't changed here, since that wouldn't have a visible benefit. Differential Revision: https://developer.blender.org/D12816
2023-01-20 17:36:07 -06:00
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
BLO_write_struct_array(writer, NodesModifierBake, nmd->bakes_num, nmd->bakes);
for (const NodesModifierBake &bake : Span(nmd->bakes, nmd->bakes_num)) {
BLO_write_string(writer, bake.directory);
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
BLO_write_struct_array(
writer, NodesModifierDataBlock, bake.data_blocks_num, bake.data_blocks);
for (const NodesModifierDataBlock &item : Span(bake.data_blocks, bake.data_blocks_num)) {
BLO_write_string(writer, item.id_name);
BLO_write_string(writer, item.lib_name);
}
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
if (bake.packed) {
BLO_write_struct(writer, NodesModifierPackedBake, bake.packed);
BLO_write_struct_array(
writer, NodesModifierBakeFile, bake.packed->meta_files_num, bake.packed->meta_files);
BLO_write_struct_array(
writer, NodesModifierBakeFile, bake.packed->blob_files_num, bake.packed->blob_files);
const auto write_bake_file = [&](const NodesModifierBakeFile &bake_file) {
BLO_write_string(writer, bake_file.name);
if (bake_file.packed_file) {
BKE_packedfile_blend_write(writer, bake_file.packed_file);
}
};
for (const NodesModifierBakeFile &meta_file :
Span{bake.packed->meta_files, bake.packed->meta_files_num})
{
write_bake_file(meta_file);
}
for (const NodesModifierBakeFile &blob_file :
Span{bake.packed->blob_files, bake.packed->blob_files_num})
{
write_bake_file(blob_file);
}
}
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
}
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
BLO_write_struct_array(writer, NodesModifierPanel, nmd->panels_num, nmd->panels);
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
Fix T104088: Geometry nodes modifier boolean lost on undo After object-mode undo (memfile undo), the value wan't lost, but the property would be temporarily converted back to integer type in order to be forward compatible. Now only use the forward compatible writing when writing undo steps. Auto-saves and similar files are currently not forward compatible anyway.
2023-01-23 15:06:55 -06:00
if (!BLO_write_is_undo(writer)) {
LISTBASE_FOREACH (IDProperty *, prop, &nmd->settings.properties->data.group) {
if (prop->type == IDP_INT) {
if (IDPropertyUIDataBool **ui_data = boolean_props.lookup_ptr(prop)) {
prop->type = IDP_BOOLEAN;
if (ui_data) {
prop->ui_data = reinterpret_cast<IDPropertyUIData *>(*ui_data);
}
Geometry Nodes: Use checkbox for exposed boolean sockets This uses the changes from ef68a37e5d55e17adf4c to create IDProperties for exposed boolean sockets with a boolean type instead of an integer with a [0,1] range. Existing properties and values are converted automatically. For forward compatibility, the properties are switched to the integer type for saving. Otherwise older versions crash immediately when opening a newer file. The "Use Attribute" IDProperties aren't changed here, since that wouldn't have a visible benefit. Differential Revision: https://developer.blender.org/D12816
2023-01-20 17:36:07 -06:00
}
}
}
}
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
}
}
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
static void blend_read(BlendDataReader *reader, ModifierData *md)
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
{
NodesModifierData *nmd = reinterpret_cast<NodesModifierData *>(md);
Refactor: Use typed functions for blend file data reading This makes the read and write API functions match more closely, and adds asserts to check that the data size is as expected. There are still a few places remaining that use BLO_read_data_address and similar generic functions, these should eventually be replaced as well. Pull Request: https://projects.blender.org/blender/blender/pulls/120994
2024-04-24 17:01:22 +02:00
BLO_read_string(reader, &nmd->bake_directory);
Geometry Nodes: Add default attribute name to field inputs/outputs Geometry node group inputs and outputs get a new property that controls the attribute name used for that field input/output when assigning the node group to a modifier for the first time. If the default name is assigned to an input, the default "Use attribute name" is true . In order to properly detect when a node group is first assigned, the modifier now clears its properties when clearing the node group. Ref T96707 Differential Revision: https://developer.blender.org/D14761
2022-04-28 08:39:30 -05:00
if (nmd->node_group == nullptr) {
nmd->settings.properties = nullptr;
}
else {
Refactor: Use typed functions for blend file data reading This makes the read and write API functions match more closely, and adds asserts to check that the data size is as expected. There are still a few places remaining that use BLO_read_data_address and similar generic functions, these should eventually be replaced as well. Pull Request: https://projects.blender.org/blender/blender/pulls/120994
2024-04-24 17:01:22 +02:00
BLO_read_struct(reader, IDProperty, &nmd->settings.properties);
Geometry Nodes: Add default attribute name to field inputs/outputs Geometry node group inputs and outputs get a new property that controls the attribute name used for that field input/output when assigning the node group to a modifier for the first time. If the default name is assigned to an input, the default "Use attribute name" is true . In order to properly detect when a node group is first assigned, the modifier now clears its properties when clearing the node group. Ref T96707 Differential Revision: https://developer.blender.org/D14761
2022-04-28 08:39:30 -05:00
IDP_BlendDataRead(reader, &nmd->settings.properties);
}
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
Refactor: Use typed functions for blend file data reading This makes the read and write API functions match more closely, and adds asserts to check that the data size is as expected. There are still a few places remaining that use BLO_read_data_address and similar generic functions, these should eventually be replaced as well. Pull Request: https://projects.blender.org/blender/blender/pulls/120994
2024-04-24 17:01:22 +02:00
BLO_read_struct_array(reader, NodesModifierBake, nmd->bakes_num, &nmd->bakes);
Fix #123974: handle corrupted file missing baked data more gracefully
2024-07-11 17:25:29 +02:00
if (nmd->bakes_num > 0 && nmd->bakes == nullptr) {
/* This case generally shouldn't be allowed to happen. However, there is a bug report with a
* corrupted .blend file (#123974) that triggers this case. Unfortunately, it's not clear how
* that could have happened. For now, handle this case more gracefully in release builds, while
* still crashing in debug builds. */
nmd->bakes_num = 0;
BLI_assert_unreachable();
}
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
for (NodesModifierBake &bake : MutableSpan(nmd->bakes, nmd->bakes_num)) {
Refactor: Use typed functions for blend file data reading This makes the read and write API functions match more closely, and adds asserts to check that the data size is as expected. There are still a few places remaining that use BLO_read_data_address and similar generic functions, these should eventually be replaced as well. Pull Request: https://projects.blender.org/blender/blender/pulls/120994
2024-04-24 17:01:22 +02:00
BLO_read_string(reader, &bake.directory);
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
Refactor: Use typed functions for blend file data reading This makes the read and write API functions match more closely, and adds asserts to check that the data size is as expected. There are still a few places remaining that use BLO_read_data_address and similar generic functions, these should eventually be replaced as well. Pull Request: https://projects.blender.org/blender/blender/pulls/120994
2024-04-24 17:01:22 +02:00
BLO_read_struct_array(reader, NodesModifierDataBlock, bake.data_blocks_num, &bake.data_blocks);
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
for (NodesModifierDataBlock &data_block : MutableSpan(bake.data_blocks, bake.data_blocks_num))
{
Refactor: Use typed functions for blend file data reading This makes the read and write API functions match more closely, and adds asserts to check that the data size is as expected. There are still a few places remaining that use BLO_read_data_address and similar generic functions, these should eventually be replaced as well. Pull Request: https://projects.blender.org/blender/blender/pulls/120994
2024-04-24 17:01:22 +02:00
BLO_read_string(reader, &data_block.id_name);
BLO_read_string(reader, &data_block.lib_name);
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
}
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
BLO_read_struct(reader, NodesModifierPackedBake, &bake.packed);
if (bake.packed) {
BLO_read_struct_array(
reader, NodesModifierBakeFile, bake.packed->meta_files_num, &bake.packed->meta_files);
BLO_read_struct_array(
reader, NodesModifierBakeFile, bake.packed->blob_files_num, &bake.packed->blob_files);
const auto read_bake_file = [&](NodesModifierBakeFile &bake_file) {
BLO_read_string(reader, &bake_file.name);
if (bake_file.packed_file) {
BKE_packedfile_blend_read(reader, &bake_file.packed_file, "");
}
};
for (NodesModifierBakeFile &meta_file :
MutableSpan{bake.packed->meta_files, bake.packed->meta_files_num})
{
read_bake_file(meta_file);
}
for (NodesModifierBakeFile &blob_file :
MutableSpan{bake.packed->blob_files, bake.packed->blob_files_num})
{
read_bake_file(blob_file);
}
}
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
}
Refactor: Use typed functions for blend file data reading This makes the read and write API functions match more closely, and adds asserts to check that the data size is as expected. There are still a few places remaining that use BLO_read_data_address and similar generic functions, these should eventually be replaced as well. Pull Request: https://projects.blender.org/blender/blender/pulls/120994
2024-04-24 17:01:22 +02:00
BLO_read_struct_array(reader, NodesModifierPanel, nmd->panels_num, &nmd->panels);
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
Geometry Nodes: add run-time data to geometry nodes modifier This adds a single run-time field and moves the existing run-time data into a new struct. This approach makes it much easier to add new run-time data. Pull Request: https://projects.blender.org/blender/blender/pulls/109905
2023-07-11 12:55:57 +02:00
nmd->runtime = MEM_new<NodesModifierRuntime>(__func__);
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
nmd->runtime->cache = std::make_shared<bake::ModifierCache>();
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
}
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
static void copy_data(const ModifierData *md, ModifierData *target, const int flag)
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
{
const NodesModifierData *nmd = reinterpret_cast<const NodesModifierData *>(md);
NodesModifierData *tnmd = reinterpret_cast<NodesModifierData *>(target);
BKE_modifier_copydata_generic(md, target, flag);
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
if (nmd->bakes) {
tnmd->bakes = static_cast<NodesModifierBake *>(MEM_dupallocN(nmd->bakes));
for (const int i : IndexRange(nmd->bakes_num)) {
NodesModifierBake &bake = tnmd->bakes[i];
if (bake.directory) {
bake.directory = BLI_strdup(bake.directory);
}
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
if (bake.data_blocks) {
bake.data_blocks = static_cast<NodesModifierDataBlock *>(MEM_dupallocN(bake.data_blocks));
for (const int i : IndexRange(bake.data_blocks_num)) {
NodesModifierDataBlock &data_block = bake.data_blocks[i];
if (data_block.id_name) {
data_block.id_name = BLI_strdup(data_block.id_name);
}
if (data_block.lib_name) {
data_block.lib_name = BLI_strdup(data_block.lib_name);
}
}
}
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
if (bake.packed) {
bake.packed = static_cast<NodesModifierPackedBake *>(MEM_dupallocN(bake.packed));
const auto copy_bake_files_inplace = [](NodesModifierBakeFile **bake_files,
const int bake_files_num) {
if (!*bake_files) {
return;
}
*bake_files = static_cast<NodesModifierBakeFile *>(MEM_dupallocN(*bake_files));
for (NodesModifierBakeFile &bake_file : MutableSpan{*bake_files, bake_files_num}) {
bake_file.name = BLI_strdup_null(bake_file.name);
if (bake_file.packed_file) {
bake_file.packed_file = BKE_packedfile_duplicate(bake_file.packed_file);
}
}
};
copy_bake_files_inplace(&bake.packed->meta_files, bake.packed->meta_files_num);
copy_bake_files_inplace(&bake.packed->blob_files, bake.packed->blob_files_num);
}
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
}
}
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
if (nmd->panels) {
tnmd->panels = static_cast<NodesModifierPanel *>(MEM_dupallocN(nmd->panels));
}
Geometry Nodes: add run-time data to geometry nodes modifier This adds a single run-time field and moves the existing run-time data into a new struct. This approach makes it much easier to add new run-time data. Pull Request: https://projects.blender.org/blender/blender/pulls/109905
2023-07-11 12:55:57 +02:00
tnmd->runtime = MEM_new<NodesModifierRuntime>(__func__);
Geometry Nodes: use shared_ptr for sharing simulation cache With this the simulation cache pointer is copied over to the evaluated modifier. This allows the original modifier to be removed without breaking the evaluated modifier, which results in better decoupling. This can avoid issues when a non-active depsgraph is evaluated in the background while the user is manipulating the scene. Also, it is now assumed that the simulation cache is always allocated even if there is no simulation (similar to run-time data). This simplifies the code. Pull Request: https://projects.blender.org/blender/blender/pulls/108976
2023-06-14 14:04:02 +02:00
if (flag & LIB_ID_COPY_SET_COPIED_ON_WRITE) {
/* Share the simulation cache between the original and evaluated modifier. */
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
tnmd->runtime->cache = nmd->runtime->cache;
Clear the cache bake directory when duplicating a modifier Duplicating will otherwise keep the same bake directory, which causes a path conflict and requires manual fixing by users. Clearing the path on copy makes it so the default path is generated on baking. This does not change the path when doing internal copies, like - Depsgraph "evaluated" object vs "original" - Appending or linking objects - Making a linked object local Pull Request: https://projects.blender.org/blender/blender/pulls/109014
2023-06-15 17:40:38 +02:00
/* Keep bake path in the evaluated modifier. */
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
tnmd->bake_directory = nmd->bake_directory ? BLI_strdup(nmd->bake_directory) : nullptr;
Geometry Nodes: use shared_ptr for sharing simulation cache With this the simulation cache pointer is copied over to the evaluated modifier. This allows the original modifier to be removed without breaking the evaluated modifier, which results in better decoupling. This can avoid issues when a non-active depsgraph is evaluated in the background while the user is manipulating the scene. Also, it is now assumed that the simulation cache is always allocated even if there is no simulation (similar to run-time data). This simplifies the code. Pull Request: https://projects.blender.org/blender/blender/pulls/108976
2023-06-14 14:04:02 +02:00
}
else {
Geometry Nodes: generalize modifier simulation cache storage names The main goal here is to rename things in a way that makes sense for simulation baking, but also for the upcoming bake node. This also removes some versioning code from 3.6 which initialized the default bake path. Baked data from back then can't be loaded anymore anyway, and the way the default path is generated is different now as well. Pull Request: https://projects.blender.org/blender/blender/pulls/111845
2023-09-03 16:14:11 +02:00
tnmd->runtime->cache = std::make_shared<bake::ModifierCache>();
Clear the cache bake directory when duplicating a modifier Duplicating will otherwise keep the same bake directory, which causes a path conflict and requires manual fixing by users. Clearing the path on copy makes it so the default path is generated on baking. This does not change the path when doing internal copies, like - Depsgraph "evaluated" object vs "original" - Appending or linking objects - Making a linked object local Pull Request: https://projects.blender.org/blender/blender/pulls/109014
2023-06-15 17:40:38 +02:00
/* Clear the bake path when duplicating. */
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
tnmd->bake_directory = nullptr;
Geometry Nodes: use shared_ptr for sharing simulation cache With this the simulation cache pointer is copied over to the evaluated modifier. This allows the original modifier to be removed without breaking the evaluated modifier, which results in better decoupling. This can avoid issues when a non-active depsgraph is evaluated in the background while the user is manipulating the scene. Also, it is now assumed that the simulation cache is always allocated even if there is no simulation (similar to run-time data). This simplifies the code. Pull Request: https://projects.blender.org/blender/blender/pulls/108976
2023-06-14 14:04:02 +02:00
}
Geometry Nodes: refactor logging during geometry nodes evaluation Many ui features for geometry nodes need access to information generated during evaluation: * Node warnings. * Attribute search. * Viewer node. * Socket inspection (not in master yet). The way we logged the required information before had some disadvantages: * Viewer node used a completely separate system from node warnings and attribute search. * Most of the context of logged information is lost when e.g. the same node group is used multiple times. * A global lock was needed every time something is logged. This new implementation solves these problems: * All four mentioned ui features use the same underlying logging system. * All context information for logged values is kept intact. * Every thread has its own local logger. The logged informatiton is combined in the end. Differential Revision: https://developer.blender.org/D11785
2021-07-07 11:20:19 +02:00
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
if (nmd->settings.properties != nullptr) {
tnmd->settings.properties = IDP_CopyProperty_ex(nmd->settings.properties, flag);
}
}
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
void nodes_modifier_packed_bake_free(NodesModifierPackedBake *packed_bake)
{
const auto free_packed_files = [](NodesModifierBakeFile *files, const int files_num) {
for (NodesModifierBakeFile &file : MutableSpan{files, files_num}) {
MEM_SAFE_FREE(file.name);
if (file.packed_file) {
BKE_packedfile_free(file.packed_file);
}
}
MEM_SAFE_FREE(files);
};
free_packed_files(packed_bake->meta_files, packed_bake->meta_files_num);
free_packed_files(packed_bake->blob_files, packed_bake->blob_files_num);
MEM_SAFE_FREE(packed_bake);
}
Fix #132831: memory leak when deleting simulation zone The leak happened because the bake data of the removed zone was only partially freed. Pull Request: https://projects.blender.org/blender/blender/pulls/132867
2025-01-09 18:19:53 +01:00
void nodes_modifier_bake_destruct(NodesModifierBake *bake, const bool do_id_user)
{
MEM_SAFE_FREE(bake->directory);
for (NodesModifierDataBlock &data_block : MutableSpan(bake->data_blocks, bake->data_blocks_num))
{
nodes_modifier_data_block_destruct(&data_block, do_id_user);
}
MEM_SAFE_FREE(bake->data_blocks);
if (bake->packed) {
nodes_modifier_packed_bake_free(bake->packed);
}
}
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
static void free_data(ModifierData *md)
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
{
NodesModifierData *nmd = reinterpret_cast<NodesModifierData *>(md);
if (nmd->settings.properties != nullptr) {
IDP_FreeProperty_ex(nmd->settings.properties, false);
nmd->settings.properties = nullptr;
}
Geometry Nodes: refactor logging during geometry nodes evaluation Many ui features for geometry nodes need access to information generated during evaluation: * Node warnings. * Attribute search. * Viewer node. * Socket inspection (not in master yet). The way we logged the required information before had some disadvantages: * Viewer node used a completely separate system from node warnings and attribute search. * Most of the context of logged information is lost when e.g. the same node group is used multiple times. * A global lock was needed every time something is logged. This new implementation solves these problems: * All four mentioned ui features use the same underlying logging system. * All context information for logged values is kept intact. * Every thread has its own local logger. The logged informatiton is combined in the end. Differential Revision: https://developer.blender.org/D11785
2021-07-07 11:20:19 +02:00
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
for (NodesModifierBake &bake : MutableSpan(nmd->bakes, nmd->bakes_num)) {
Fix #132831: memory leak when deleting simulation zone The leak happened because the bake data of the removed zone was only partially freed. Pull Request: https://projects.blender.org/blender/blender/pulls/132867
2025-01-09 18:19:53 +01:00
nodes_modifier_bake_destruct(&bake, false);
Geometry Nodes: support baking individual simulations Previously, it was only possible to bake all simulations at once. This is great for simple use-cases that, but in more complex setups one can have independent simulations that should also be baked independently. This patch allows baking individual simulation zones. Furthermore, each simulation zone can now also have its own bake path and simulation frame range. By default the simulation frame range is the scene frame range, but it can also be customized on the scene or simulation zone level. The bake path is generated based on the modifier bake path by default, but can be set to another absolute or relative (to the .blend file) path. The timeline drawing has been modified as well to be able to show more information in the case when some simulations are baked and others are not. Instead of showing a line for every simulation, it shows a condensed view of the important information using at most two lines: Is something baked? Is something valid or invalid? Also see #112232. Pull Request: https://projects.blender.org/blender/blender/pulls/112723
2023-09-26 20:30:46 +02:00
}
MEM_SAFE_FREE(nmd->bakes);
Geometry Nodes: support panels in geometry nodes modifier This builds on top of f824476bd5f81f98f9b969661e8e9ac4d50a5521 to show panels in the geometry nodes modifier. It also changes the two existing panels to use the new layout panels. The open-close state of the panels is stored in the modifier itself. It contains a mapping from panel id to the corresponding state flag. Pull Request: https://projects.blender.org/blender/blender/pulls/116472
2023-12-23 16:33:14 +01:00
MEM_SAFE_FREE(nmd->panels);
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
MEM_SAFE_FREE(nmd->bake_directory);
Geometry Nodes: add run-time data to geometry nodes modifier This adds a single run-time field and moves the existing run-time data into a new struct. This approach makes it much easier to add new run-time data. Pull Request: https://projects.blender.org/blender/blender/pulls/109905
2023-07-11 12:55:57 +02:00
MEM_delete(nmd->runtime);
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
}
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
static void required_data_mask(ModifierData * /*md*/, CustomData_MeshMasks *r_cddata_masks)
Geometry Nodes: require vertex groups data in nodes modifier Without this, the modifier evaluation code might remove any vertex groups from the mesh for performance reasons. We can't say for sure whether the node group will need the vertex groups, but it is quite likely. Ref T83357.
2020-12-14 15:28:24 +01:00
{
/* We don't know what the node tree will need. If there are vertex groups, it is likely that the
* node tree wants to access them. */
r_cddata_masks->vmask |= CD_MASK_MDEFORMVERT;
Fix T87087: attributes were removed automatically even though they are still needed The geometry nodes modifier did not specify that it needs all custom data layers. Therefore the modifier evaluation code tagged some layers so that they will not be copied later on by calling `mesh_set_only_copy` in `mesh_calc_modifiers`.
2021-03-31 16:25:23 +02:00
r_cddata_masks->vmask |= CD_MASK_PROP_ALL;
Geometry Nodes: require vertex groups data in nodes modifier Without this, the modifier evaluation code might remove any vertex groups from the mesh for performance reasons. We can't say for sure whether the node group will need the vertex groups, but it is quite likely. Ref T83357.
2020-12-14 15:28:24 +01:00
}
Cleanup: Mode most of MOD_nodes.cc to the blender namespace Avoid introducing another `::modifiers` namespace for now, since it's not clear if we'll want that long term. This just avoids a bunch of boilerplate and makes things easier to read.
2023-03-31 13:19:37 -04:00
} // namespace blender
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
ModifierTypeInfo modifierType_Nodes = {
Modifiers: Add `idname` field to `ModifierTypeInfo` Previously the panel type name of a modifier (e.g. "MOD_PT_Smooth") was created by copying from the ModifierTypeInfos name. This meant that modifiers with the same default name would use the same identifier for the panels. Since different object types (e.g. OB_GREASE_PENCIL and OB_MESH) might want to use the same default modifier name, this PR introduces an idname field in the ModifierTypeInfo struct. This is then used to generate the panel type name. For compatibility reasons, the idname is the same as the name for now. Note: Because the name was used previously, this means that some modifiers have spaces in their panel type name. E.g. "MOD_PT_Volume to Mesh". Pull Request: https://projects.blender.org/blender/blender/pulls/110468
2023-07-26 17:08:14 +02:00
/*idname*/ "GeometryNodes",
Cleanup: comments in struct declarations Use a consistent style for declaring the names of struct members in their declarations. Note that this convention was already used in many places but not everywhere. Remove spaces around the text (matching commented arguments) with the advantage that the the spell checking utility skips these terms. Making it possible to extract & validate these comments automatically. Also use struct names for `bAnimChannelType` & `bConstraintTypeInfo` which were using brief descriptions.
2023-01-16 12:41:11 +11:00
/*name*/ N_("GeometryNodes"),
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
/*struct_name*/ "NodesModifierData",
/*struct_size*/ sizeof(NodesModifierData),
Cleanup: comments in struct declarations Use a consistent style for declaring the names of struct members in their declarations. Note that this convention was already used in many places but not everywhere. Remove spaces around the text (matching commented arguments) with the advantage that the the spell checking utility skips these terms. Making it possible to extract & validate these comments automatically. Also use struct names for `bAnimChannelType` & `bConstraintTypeInfo` which were using brief descriptions.
2023-01-16 12:41:11 +11:00
/*srna*/ &RNA_NodesModifier,
Cleanup: Use enum class for ModifierTypeType
2023-11-14 10:03:56 +01:00
/*type*/ ModifierTypeType::Constructive,
Cleanup: comments in struct declarations Use a consistent style for declaring the names of struct members in their declarations. Note that this convention was already used in many places but not everywhere. Remove spaces around the text (matching commented arguments) with the advantage that the the spell checking utility skips these terms. Making it possible to extract & validate these comments automatically. Also use struct names for `bAnimChannelType` & `bConstraintTypeInfo` which were using brief descriptions.
2023-01-16 12:41:11 +11:00
/*flags*/
Cleanup: Various clang-tidy warnings in modifiers Pull Request: https://projects.blender.org/blender/blender/pulls/133734
2025-01-26 20:07:57 +01:00
(eModifierTypeFlag_AcceptsMesh | eModifierTypeFlag_AcceptsCVs |
eModifierTypeFlag_SupportsEditmode | eModifierTypeFlag_EnableInEditmode |
eModifierTypeFlag_SupportsMapping | eModifierTypeFlag_AcceptsGreasePencil),
Cleanup: comments in struct declarations Use a consistent style for declaring the names of struct members in their declarations. Note that this convention was already used in many places but not everywhere. Remove spaces around the text (matching commented arguments) with the advantage that the the spell checking utility skips these terms. Making it possible to extract & validate these comments automatically. Also use struct names for `bAnimChannelType` & `bConstraintTypeInfo` which were using brief descriptions.
2023-01-16 12:41:11 +11:00
/*icon*/ ICON_GEOMETRY_NODES,
Cleanup: use snake case, especially for structs that define callbacks Use snake case for ShaderFxTypeInfo, ModifierTypeInfo, GpencilModifierTypeInfo & bConstraintTypeInfo.
2023-07-27 12:04:18 +10:00
/*copy_data*/ blender::copy_data,
/*deform_verts*/ nullptr,
/*deform_matrices*/ nullptr,
/*deform_verts_EM*/ nullptr,
/*deform_matrices_EM*/ nullptr,
/*modify_mesh*/ blender::modify_mesh,
/*modify_geometry_set*/ blender::modify_geometry_set,
/*init_data*/ blender::init_data,
/*required_data_mask*/ blender::required_data_mask,
/*free_data*/ blender::free_data,
/*is_disabled*/ blender::is_disabled,
/*update_depsgraph*/ blender::update_depsgraph,
/*depends_on_time*/ blender::depends_on_time,
/*depends_on_normals*/ nullptr,
/*foreach_ID_link*/ blender::foreach_ID_link,
/*foreach_tex_link*/ blender::foreach_tex_link,
/*free_runtime_data*/ nullptr,
/*panel_register*/ blender::panel_register,
/*blend_write*/ blender::blend_write,
/*blend_read*/ blender::blend_read,
Modifiers: add ModifierTypeInfo::foreach_cache callback This allows modifiers to have cache pointers that are preserved over undo steps. I intend to use this for the baked data cache for the geometry nodes modifier. Pull Request: https://projects.blender.org/blender/blender/pulls/117307
2024-01-18 22:51:30 +01:00
/*foreach_cache*/ nullptr,
Geometry Nodes: initial scattering and geometry nodes This is the initial merge from the geometry-nodes branch. Nodes: * Attribute Math * Boolean * Edge Split * Float Compare * Object Info * Point Distribute * Point Instance * Random Attribute * Random Float * Subdivision Surface * Transform * Triangulate It includes the initial evaluation of geometry node groups in the Geometry Nodes modifier. Notes on the Generic attribute access API The API adds an indirection for attribute access. That has the following benefits: * Most code does not have to care about how an attribute is stored internally. This is mainly necessary, because we have to deal with "legacy" attributes such as vertex weights and attributes that are embedded into other structs such as vertex positions. * When reading from an attribute, we generally don't care what domain the attribute is stored on. So we want to abstract away the interpolation that that adapts attributes from one domain to another domain (this is not actually implemented yet). Other possible improvements for later iterations include: * Actually implement interpolation between domains. * Don't use inheritance for the different attribute types. A single class for read access and one for write access might be enough, because we know all the ways in which attributes are stored internally. We don't want more different internal structures in the future. On the contrary, ideally we can consolidate the different storage formats in the future to reduce the need for this indirection. * Remove the need for heap allocations when creating attribute accessors. It includes commits from: * Dalai Felinto * Hans Goudey * Jacques Lucke * Léo Depoix
2020-12-02 13:25:25 +01:00
};
Reference in New Issue Copy Permalink