6e5e01e630
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
64 lines
2.7 KiB
C++
64 lines
2.7 KiB
C++
/* SPDX-FileCopyrightText: 2023 Blender Authors
|
|
*
|
|
* SPDX-License-Identifier: GPL-2.0-or-later */
|
|
|
|
#pragma once
|
|
|
|
/**
|
|
* A #ViewerPath is a path to data that is viewed/debugged by the user. It is a list of
|
|
* #ViewerPathElem.
|
|
*
|
|
* This is only used for geometry nodes currently. When the user activates a viewer node the
|
|
* corresponding path contains the following elements:
|
|
* - Object the viewer is activated on.
|
|
* - Modifier that contains the corresponding geometry node group.
|
|
* - Node tree path in case the viewer node is in a nested node group.
|
|
* - Viewer node name.
|
|
*
|
|
* The entire path is necessary (instead of just the combination of node group and viewer name),
|
|
* because the same node group may be used in many different places.
|
|
*
|
|
* This file contains basic functions for creating/deleting a #ViewerPath. For more use-case
|
|
* specific functions look in `ED_viewer_path.hh`.
|
|
*/
|
|
|
|
#include "DNA_viewer_path_types.h"
|
|
|
|
struct BlendWriter;
|
|
struct BlendDataReader;
|
|
struct LibraryForeachIDData;
|
|
|
|
namespace blender::bke::id {
|
|
class IDRemapper;
|
|
}
|
|
|
|
enum ViewerPathEqualFlag {
|
|
VIEWER_PATH_EQUAL_FLAG_IGNORE_ITERATION = (1 << 0),
|
|
};
|
|
|
|
void BKE_viewer_path_init(ViewerPath *viewer_path);
|
|
void BKE_viewer_path_clear(ViewerPath *viewer_path);
|
|
void BKE_viewer_path_copy(ViewerPath *dst, const ViewerPath *src);
|
|
bool BKE_viewer_path_equal(const ViewerPath *a,
|
|
const ViewerPath *b,
|
|
ViewerPathEqualFlag flag = ViewerPathEqualFlag(0));
|
|
void BKE_viewer_path_blend_write(BlendWriter *writer, const ViewerPath *viewer_path);
|
|
void BKE_viewer_path_blend_read_data(BlendDataReader *reader, ViewerPath *viewer_path);
|
|
void BKE_viewer_path_foreach_id(LibraryForeachIDData *data, ViewerPath *viewer_path);
|
|
void BKE_viewer_path_id_remap(ViewerPath *viewer_path,
|
|
const blender::bke::id::IDRemapper &mappings);
|
|
|
|
ViewerPathElem *BKE_viewer_path_elem_new(ViewerPathElemType type);
|
|
IDViewerPathElem *BKE_viewer_path_elem_new_id();
|
|
ModifierViewerPathElem *BKE_viewer_path_elem_new_modifier();
|
|
GroupNodeViewerPathElem *BKE_viewer_path_elem_new_group_node();
|
|
SimulationZoneViewerPathElem *BKE_viewer_path_elem_new_simulation_zone();
|
|
ViewerNodeViewerPathElem *BKE_viewer_path_elem_new_viewer_node();
|
|
RepeatZoneViewerPathElem *BKE_viewer_path_elem_new_repeat_zone();
|
|
ForeachGeometryElementZoneViewerPathElem *BKE_viewer_path_elem_new_foreach_geometry_element_zone();
|
|
ViewerPathElem *BKE_viewer_path_elem_copy(const ViewerPathElem *src);
|
|
bool BKE_viewer_path_elem_equal(const ViewerPathElem *a,
|
|
const ViewerPathElem *b,
|
|
ViewerPathEqualFlag flag = ViewerPathEqualFlag(0));
|
|
void BKE_viewer_path_elem_free(ViewerPathElem *elem);
|