Geometry Node: Index of Nearest #104619
|
@ -520,6 +520,7 @@ class NODE_MT_category_GEO_UTILITIES_FIELD(Menu):
|
|||
node_add_menu.add_node_type(layout, "GeometryNodeAccumulateField")
|
||||
node_add_menu.add_node_type(layout, "GeometryNodeFieldAtIndex")
|
||||
node_add_menu.add_node_type(layout, "GeometryNodeFieldOnDomain")
|
||||
node_add_menu.add_node_type(layout, "GeometryNodeIndexOfNearest")
|
||||
node_add_menu.draw_assets_for_catalog(layout, self.bl_label)
|
||||
|
||||
|
||||
|
|
|
@ -1541,6 +1541,7 @@ void BKE_nodetree_remove_layer_n(struct bNodeTree *ntree, struct Scene *scene, i
|
|||
#define GEO_NODE_IMAGE 1191
|
||||
#define GEO_NODE_INTERPOLATE_CURVES 1192
|
||||
#define GEO_NODE_EDGES_TO_FACE_GROUPS 1193
|
||||
#define GEO_NODE_INDEX_OF_NEAREST 1194
|
||||
|
||||
/** \} */
|
||||
|
||||
|
|
|
@ -105,6 +105,23 @@ inline void BLI_kdtree_nd_(range_search_cb_cpp)(const KDTree *tree,
|
|||
},
|
||||
const_cast<Fn *>(&fn));
|
||||
}
|
||||
|
||||
template<typename Fn>
|
||||
inline int BLI_kdtree_nd_(find_nearest_cb)(const KDTree *tree,
|
||||
mod_moder marked this conversation as resolved
Outdated
|
||||
const float co[KD_DIMS],
|
||||
KDTreeNearest *r_nearest,
|
||||
const Fn &fn)
|
||||
Jacques Lucke
commented
Can just use Can just use `Fn &&fn`, then you also don't need the const cast below I think.
Iliya Katushenock
commented
Should i also change one other _cpp wrapper above? Should i also change one other _cpp wrapper above?
Jacques Lucke
commented
Just keep other code as is right now. Just keep other code as is right now.
|
||||
{
|
||||
return BLI_kdtree_nd_(find_nearest_cb)(
|
||||
tree,
|
||||
co,
|
||||
[](void *user_data, const int index, const float *co, const float dist_sq) {
|
||||
const Fn &fn = *static_cast<const Fn *>(user_data);
|
||||
return fn(index, co, dist_sq);
|
||||
},
|
||||
const_cast<Fn *>(&fn),
|
||||
r_nearest);
|
||||
}
|
||||
#endif
|
||||
|
||||
#undef _BLI_CONCAT_AUX
|
||||
|
|
|
@ -324,6 +324,7 @@ DefNode(GeometryNode, GEO_NODE_FLIP_FACES, 0, "FLIP_FACES", FlipFaces, "Flip Fac
|
|||
DefNode(GeometryNode, GEO_NODE_GEOMETRY_TO_INSTANCE, 0, "GEOMETRY_TO_INSTANCE", GeometryToInstance, "Geometry to Instance", "Convert each input geometry into an instance, which can be much faster than the Join Geometry node when the inputs are large")
|
||||
DefNode(GeometryNode, GEO_NODE_IMAGE_INFO, 0, "IMAGE_INFO", ImageInfo, "Image Info", "Retrieve information about an image")
|
||||
DefNode(GeometryNode, GEO_NODE_IMAGE_TEXTURE, def_geo_image_texture, "IMAGE_TEXTURE", ImageTexture, "Image Texture", "Sample values from an image texture")
|
||||
DefNode(GeometryNode, GEO_NODE_INDEX_OF_NEAREST, 0, "INDEX_OF_NEAREST", IndexOfNearest, "Index Of Nearest", "Index of nearest element by groups condition")
|
||||
mod_moder marked this conversation as resolved
Outdated
Hans Goudey
commented
For the description, I'd suggest: Adding For the description, I'd suggest:
`Find the nearest element in the a group`
Adding `. Similar to the \"Sample Nearest\" node` might be helpful too.
|
||||
DefNode(GeometryNode, GEO_NODE_IMAGE, def_geo_image, "IMAGE", InputImage, "Image", "Input image")
|
||||
DefNode(GeometryNode, GEO_NODE_INPUT_CURVE_HANDLES, 0, "INPUT_CURVE_HANDLES", InputCurveHandlePositions,"Curve Handle Positions", "Retrieve the position of each Bézier control point's handles")
|
||||
DefNode(GeometryNode, GEO_NODE_INPUT_CURVE_TILT, 0, "INPUT_CURVE_TILT", InputCurveTilt, "Curve Tilt", "Retrieve the angle at each control point used to twist the curve's normal around its tangent")
|
||||
|
|
|
@ -77,6 +77,7 @@ set(SRC
|
|||
nodes/node_geo_geometry_to_instance.cc
|
||||
nodes/node_geo_image_info.cc
|
||||
nodes/node_geo_image_texture.cc
|
||||
nodes/node_geo_index_of_nearest.cc
|
||||
nodes/node_geo_image.cc
|
||||
nodes/node_geo_input_curve_handles.cc
|
||||
nodes/node_geo_input_curve_tilt.cc
|
||||
|
|
|
@ -62,6 +62,7 @@ void register_geometry_nodes()
|
|||
register_node_type_geo_image_info();
|
||||
register_node_type_geo_image_texture();
|
||||
register_node_type_geo_image();
|
||||
register_node_type_geo_index_of_nearest();
|
||||
register_node_type_geo_input_curve_handles();
|
||||
register_node_type_geo_input_curve_tilt();
|
||||
register_node_type_geo_input_id();
|
||||
|
|
|
@ -59,6 +59,7 @@ void register_node_type_geo_geometry_to_instance();
|
|||
void register_node_type_geo_image_info();
|
||||
void register_node_type_geo_image_texture();
|
||||
void register_node_type_geo_image();
|
||||
void register_node_type_geo_index_of_nearest();
|
||||
void register_node_type_geo_input_curve_handles();
|
||||
void register_node_type_geo_input_curve_tilt();
|
||||
void register_node_type_geo_input_id();
|
||||
|
|
|
@ -0,0 +1,185 @@
|
|||
/* SPDX-License-Identifier: GPL-2.0-or-later */
|
||||
|
||||
#include "BKE_attribute_math.hh"
|
||||
|
||||
#include "NOD_socket_search_link.hh"
|
||||
|
||||
#include "BLI_kdtree.h"
|
||||
#include "BLI_multi_value_map.hh"
|
||||
#include "BLI_task.hh"
|
||||
|
||||
#include "BKE_geometry_fields.hh"
|
||||
mod_moder marked this conversation as resolved
Hans Goudey
commented
`BKE_geometry_fields.hh` is already included indirectly by `node_geometry_util.hh`
|
||||
|
||||
#include "node_geometry_util.hh"
|
||||
|
||||
#include "UI_interface.h"
|
||||
mod_moder marked this conversation as resolved
Outdated
Hans Goudey
commented
I think these UI includes are unused I think these UI includes are unused
|
||||
#include "UI_resources.h"
|
||||
|
||||
namespace blender::nodes::node_geo_index_of_nearest_cc {
|
||||
|
||||
static void node_declare(NodeDeclarationBuilder &b)
|
||||
{
|
||||
b.add_input<decl::Vector>("Position").implicit_field(implicit_field_inputs::position);
|
||||
|
||||
b.add_input<decl::Int>("Self Group ID").supports_field().hide_value().default_value(0);
|
||||
mod_moder marked this conversation as resolved
Outdated
Hans Goudey
commented
These identifiers/names are missing the translation macro These identifiers/names are missing the translation macro `N_`
|
||||
b.add_input<decl::Int>("Group ID to Search").supports_field().hide_value().default_value(0);
|
||||
mod_moder marked this conversation as resolved
Outdated
Hans Goudey
commented
We settled on We settled on `Self Group ID` and `Nearest Group ID` in the module meeting.
|
||||
|
||||
b.add_output<decl::Int>("Index").field_source().description(N_("Index of nearest element"));
|
||||
}
|
||||
|
||||
int kdtree_find_neighboard(KDTree_3d *tree, const float3 &position, int index)
|
||||
{
|
||||
mod_moder marked this conversation as resolved
Outdated
Hans Goudey
commented
Pass spans by value Pass spans by value
|
||||
return BLI_kdtree_3d_find_nearest_cb(
|
||||
tree, position, 0, [index](const int other_new_i, const float * /*co*/, float /*dist_sq*/) {
|
||||
if (index == other_new_i) {
|
||||
return 0;
|
||||
}
|
||||
return 1;
|
||||
});
|
||||
}
|
||||
|
||||
class IndexOfNearestFieldInput final : public bke::GeometryFieldInput {
|
||||
private:
|
||||
const Field<float3> positions_;
|
||||
const Field<int> group_;
|
||||
const Field<int> search_group_;
|
||||
|
||||
public:
|
||||
IndexOfNearestFieldInput(const Field<float3> positions,
|
||||
const Field<int> group,
|
||||
const Field<int> search_group)
|
||||
: bke::GeometryFieldInput(CPPType::get<int>(), "Nearest to"),
|
||||
Hans Goudey
commented
I don't think there's a benefit to specifying the capture in a case like this (instead of I don't think there's a benefit to specifying the capture in a case like this (instead of `[&]`)
|
||||
positions_(std::move(positions)),
|
||||
group_(std::move(group)),
|
||||
search_group_(std::move(search_group))
|
||||
{
|
||||
}
|
||||
|
||||
GVArray get_varray_for_context(const bke::GeometryFieldContext &context,
|
||||
IndexMask mask) const final
|
||||
{
|
||||
fn::FieldEvaluator evaluator{context, &mask};
|
||||
evaluator.add(positions_);
|
||||
evaluator.add(group_);
|
||||
evaluator.add(search_group_);
|
||||
evaluator.evaluate();
|
||||
|
||||
Jacques Lucke
commented
Can just use a normal for loop here. The performance benefit of using Can just use a normal for loop here. The performance benefit of using `foreach_index` is negligible, because most time is spend in the kdtree traversal.
|
||||
const VArray<float3> positions = evaluator.get_evaluated<float3>(0);
|
||||
const VArray<int> group = evaluator.get_evaluated<int>(1);
|
||||
const VArray<int> search_group = evaluator.get_evaluated<int>(2);
|
||||
|
||||
const bool group_use = !group.is_single();
|
||||
mod_moder marked this conversation as resolved
Outdated
Hans Goudey
commented
I'd change these names to I'd change these names to `use_group` and `use_search_group` for consistency with your other variable names and because `use` at front sounds more natural.
|
||||
const bool group_to_find_use = !search_group.is_single();
|
||||
|
||||
MultiValueMap<int, int64_t> in_group;
|
||||
MultiValueMap<int, int64_t> out_group;
|
||||
Array<int> indices(mask.min_array_size());
|
||||
|
||||
threading::parallel_invoke((indices.size() > 512) && group_to_find_use && group_use,
|
||||
Hans Goudey
commented
This comment is a bit vague, but I'm finding it hard to keep track of the separate This comment is a bit vague, but I'm finding it hard to keep track of the separate `group_use` and `group_to_find_use` conditions. I wonder if the first condition could be handled with by splitting logic into a separate function, like `SampleCurveFunction` does with its `sample_curve` lambda.
|
||||
[&]() {
|
||||
if (group_use) {
|
||||
mod_moder marked this conversation as resolved
Outdated
Hans Goudey
commented
No strong opinion, but using regular No strong opinion, but using regular `=` assignment seems more consistent here.
|
||||
for (const int64_t i : mask.index_range()) {
|
||||
in_group.add(group[mask[i]], i);
|
||||
}
|
||||
}
|
||||
else {
|
||||
const int group_key = group.get_internal_single();
|
||||
in_group.add_multiple(group_key, {});
|
||||
}
|
||||
},
|
||||
Hans Goudey
commented
It seems like creating a KD tree for every group ID will mean that the KD tree for the same set of search points will potentially be built multiple times. There should probably be some way to avoid building a tree multiple times for the same key. Overall this area looks much cleaner than the last time I checked though! It seems like creating a KD tree for every group ID will mean that the KD tree for the same set of search points will potentially be built multiple times. There should probably be some way to avoid building a tree multiple times for the same key.
Overall this area looks much cleaner than the last time I checked though!
Iliya Katushenock
commented
After you point it out... it seems I made some kind of logical error in the implementation of switching groups when iterating over them. Or not .. i need to redo this part of the code After you point it out... it seems I made some kind of logical error in the implementation of switching groups when iterating over them. Or not .. i need to redo this part of the code
Hans Goudey
commented
Remove empty line between Remove empty line between `group_indexing` declaration and loop that creates it
|
||||
[&]() {
|
||||
if (group_to_find_use) {
|
||||
for (const int64_t i : mask.index_range()) {
|
||||
out_group.add(search_group[mask[i]], i);
|
||||
}
|
||||
mod_moder marked this conversation as resolved
Outdated
Hans Goudey
commented
We can't selectively ignore the mask actually, it may be incorrect to write the output to non-selected indices. So this check really has to be We can't selectively ignore the mask actually, it may be incorrect to write the output to non-selected indices. So this check really has to be `mask.size() == domain_size`
Iliya Katushenock
commented
I see. I see.
Just if domain size is 10000, mask is 9999, is no much sense to compute the cheap mask. I think, is better to just allocate all elements if cheap mask is used.
|
||||
}
|
||||
mod_moder marked this conversation as resolved
Outdated
Hans Goudey
commented
Replace this with Replace this with `const bool mask_is_full = mask.size() == domain_size;`
|
||||
});
|
||||
|
||||
for (int key : in_group.keys()) {
|
||||
mod_moder marked this conversation as resolved
Outdated
Hans Goudey
commented
`int key` -> `const int key`
|
||||
/* Never empty. */
|
||||
const Span<int64_t> self_points = group_use ? in_group.lookup(key) : mask.indices();
|
||||
const Span<int64_t> search_points = group_to_find_use ? out_group.lookup(key) : self_points;
|
||||
|
||||
if (search_points.is_empty()) {
|
||||
indices.as_mutable_span().fill_indices(self_points, 0);
|
||||
continue;
|
||||
mod_moder marked this conversation as resolved
Outdated
Hans Goudey
commented
The result array should never need to be larger than The result array should never need to be larger than `mask.min_array_size()`
|
||||
}
|
||||
|
||||
KDTree_3d *tree = BLI_kdtree_3d_new(search_points.size());
|
||||
for (const int64_t index : search_points) {
|
||||
BLI_kdtree_3d_insert(tree, index, positions[index]);
|
||||
}
|
||||
mod_moder marked this conversation as resolved
Outdated
Jacques Lucke
commented
While forest is used as a technical term for a graph containing multiple trees, I don't think the term should be used for a collection of multiple independent kd trees. Just use While forest is used as a technical term for a graph containing multiple trees, I don't think the term should be used for a collection of multiple independent kd trees. Just use `kdtrees`.
Iliya Katushenock
commented
If i do merge If i do merge `parallel_for`s below, i can delete this vector.
|
||||
|
||||
BLI_kdtree_3d_balance(tree);
|
||||
|
||||
mod_moder marked this conversation as resolved
Outdated
Hans Goudey
commented
I think this should be I think this should be `!mask_is_cheap`
Iliya Katushenock
commented
I was isn't invented the best name, I was isn't invented the best name, `mask_is_cheap` == true if computing of indices make sense and cheap mask is used.
|
||||
threading::parallel_for(self_points.index_range(), 128, [&](const IndexRange range) {
|
||||
Hans Goudey
commented
TBH I think it's better to just use TBH I think it's better to just use `int64_t` here to avoid duplicating the functions above. Eventually when `IndexMask` is refactored, these could benefit from using that, and the `int64_t` will make that more clear too.
|
||||
for (const int64_t index : self_points.slice(range)) {
|
||||
mod_moder marked this conversation as resolved
Outdated
Hans Goudey
commented
`Vector` -> `Array` here
|
||||
const int index_of_nearest = kdtree_find_neighboard(tree, positions[index], index);
|
||||
if (index == -1) {
|
||||
indices[index] = index;
|
||||
}
|
||||
else {
|
||||
Hans Goudey
commented
`domain_size > 1024 && use_cheap_mask` -> `domain_size > 1024 && !mask_is_full`
|
||||
indices[index] = index_of_nearest;
|
||||
Iliya Katushenock
commented
Are Are `grain_size` is a power of 2?
Hans Goudey
commented
They don't need to be powers of two, though I think it can be slightly beneficial. Since these numbers are a bit arbitrary anyway I started using powers of two. They don't need to be powers of two, though I think it can be slightly beneficial. Since these numbers are a bit arbitrary anyway I started using powers of two.
Iliya Katushenock
commented
I remember fixing a bug, only related to the fact that there was no power of 2x. I remember fixing a bug, only related to the fact that there was no power of 2x.
For the blur node, I made the search function for the top bit part in the threading namespace.
|
||||
}
|
||||
}
|
||||
});
|
||||
Iliya Katushenock
commented
Why It seems that trying to use a mask to multiply all user groups by groups from the mask leads to much more overhead in most cases. Why `tree_masks[i]` and `evaluate_masks[i]` is groups with the same id? this isn't sorted somether or protected, that mask isn't avoid all elements of some grouop and create offset for all other groups even all of that added in same order.
It seems that trying to use a mask to multiply all user groups by groups from the mask leads to much more overhead in most cases.
If you don't do some kind of analogue of a tree, then it's like doing a boolean through mask1 * mask2. When there is something like bvh. so I think it's easier to just calculate everything. I'm not sure there are many cases now where the mask can actually be a small part.
Hans Goudey
commented
Oh, great point! I think it's still worth having a separate evaluation mask. Even just the set position node with a small selection would benefit from it, I think kd tree lookups are fairly expensive. I guess both masks have to be created at the same time. Oh, great point! I think it's still worth having a separate evaluation mask. Even just the set position node with a small selection would benefit from it, I think kd tree lookups are fairly expensive. I guess both masks have to be created at the same time.
|
||||
|
||||
BLI_kdtree_3d_free(tree);
|
||||
}
|
||||
|
||||
return VArray<int>::ForContainer(std::move(indices));
|
||||
Hans Goudey
commented
I do think one of these indices could be skipped if the selection is complete I do think one of these indices could be skipped if the selection is complete
Hans Goudey
commented
Use Use `IndexMask` instead of `Span<int64_t>` for these `mask_of_tree` and `mask` variables
|
||||
}
|
||||
mod_moder marked this conversation as resolved
Outdated
Hans Goudey
commented
References typically indicate a lack of ownership, better to stick with a pointer here References typically indicate a lack of ownership, better to stick with a pointer here
|
||||
|
||||
void for_each_field_input_recursive(FunctionRef<void(const FieldInput &)> fn) const
|
||||
Jacques Lucke
commented
Feels like this Feels like this `parallel_for` loop and the one below can be combined into one. This could potentially improve multi-threaded performance.
|
||||
{
|
||||
positions_.node().for_each_field_input_recursive(fn);
|
||||
group_.node().for_each_field_input_recursive(fn);
|
||||
search_group_.node().for_each_field_input_recursive(fn);
|
||||
}
|
||||
|
||||
uint64_t hash() const override
|
||||
{
|
||||
return get_default_hash_3(positions_, group_, search_group_);
|
||||
}
|
||||
|
||||
bool is_equal_to(const fn::FieldNode &other) const override
|
||||
{
|
||||
if (const IndexOfNearestFieldInput *other_field =
|
||||
dynamic_cast<const IndexOfNearestFieldInput *>(&other)) {
|
||||
return positions_ == other_field->positions_ && group_ == other_field->group_ &&
|
||||
search_group_ == other_field->search_group_;
|
||||
}
|
||||
return false;
|
||||
}
|
||||
|
||||
std::optional<eAttrDomain> preferred_domain(const GeometryComponent &component) const override
|
||||
{
|
||||
return bke::try_detect_field_domain(component, positions_);
|
||||
}
|
||||
};
|
||||
|
||||
static void node_geo_exec(GeoNodeExecParams params)
|
||||
{
|
||||
const Field<float3> position = params.extract_input<Field<float3>>("Position");
|
||||
|
||||
const Field<int> self_group = params.extract_input<Field<int>>("Self Group ID");
|
||||
mod_moder marked this conversation as resolved
Outdated
Hans Goudey
commented
If using I think it would be fine to retrieve them directly in If using `std::move` with these variables, don't declare them const.
I think it would be fine to retrieve them directly in `make_shared` though, rather than having temporary variables.
|
||||
const Field<int> search_group = params.extract_input<Field<int>>("Group ID to Search");
|
||||
|
||||
params.set_output("Index",
|
||||
Field<int>{std::make_shared<IndexOfNearestFieldInput>(
|
||||
std::move(position), std::move(self_group), std::move(search_group))});
|
||||
}
|
||||
|
||||
} // namespace blender::nodes::node_geo_index_of_nearest_cc
|
||||
|
||||
void register_node_type_geo_index_of_nearest()
|
||||
{
|
||||
namespace file_ns = blender::nodes::node_geo_index_of_nearest_cc;
|
||||
|
||||
static bNodeType ntype;
|
||||
|
||||
geo_node_type_base(&ntype, GEO_NODE_INDEX_OF_NEAREST, "Index Of Nearest", NODE_CLASS_CONVERTER);
|
||||
ntype.geometry_node_execute = file_ns::node_geo_exec;
|
||||
ntype.declare = file_ns::node_declare;
|
||||
nodeRegisterType(&ntype);
|
||||
}
|
Might as well be consistent with the other function here and use the
_cpp
suffix too.