Change Details

##A task:## The node is designed so that each element can know about its nearest neighbor. In contrast to the already available options, the task of this node is to analyze the same field of points in which they are located. So the problem with recreating this now is that each element considers itself closest to itself. ##Functionality:## Since this node does not require another domain to operate, this node can operate in the field. This node does not take into account the specifics of the geometry, all it needs is a field of points. In such a case, for each position index, one can find the index of another nearest position. ##Implementation design:## For implementation, it is considered to use the `KDTree` structure as a way to search for elements in a narrow space with selection according to the rule and checking for the closest to. --- ##Optional:## - Grouping: Based on the fact that geometry nodes use the group index to separate formal logic between abstractly separated sets of elements, grouping is also considered a useful feature of the node. The search implies two possible groupings: - Input groupings. Isolated search tasks. - Search groups. Isolated search in. If only these groups are counted, then the combinations are: |In/Search| No | Has | | No | Global search | No search. Essentially a mask function. | | Has | Isolated global search | Each group of points searches for the nearest one in its group. | - Inversion: Search can be handy. But if there are many points in each group, it may be necessary to find a neighbor not in another group, but in all the others. Also, if the search group is different from the point group, this means that inversion can mean searching even at other points in the group, but not at any particular group. - Range: The restriction for finding the nearest point can be limited not only by really close points, but also by intentionally remote ones. Or those that are not too far away. This means the ability to specify the maximum and minimum search distance. --- As an easy start to consider user feedback, it makes sense to add features one at a time to have real-time user feedback. In essence, this will only require you to add sockets and menu (as needed). So problems with versioning can be minimal. ##Name for such node:## I suggest Index of Nearest Discussion is open

##A task:## The node is designed so that each element can know about its nearest neighbor. In contrast to the already available options, the task of this node is to analyze the same field of points in which they are located. So the problem with recreating this now is that each element considers itself closest to itself. ##Functionality:## Since this node does not require another domain to operate, this node can operate in the field. This node does not take into account the specifics of the geometry, all it needs is a field of points. In such a case, for each position index, one can find the index of another nearest position. ##Implementation design:## For implementation, it is considered to use the `KDTree` structure as a way to search for elements in a narrow space with selection according to the rule and checking for the closest to. ##Name for such node:## I suggest Index of Nearest Discussion is open

##A task:## The node is designed so that each element can know about its nearest neighbor. In contrast to the already available options, the task of this node is to analyze the same field of points in which they are located. So the problem with recreating this now is that each element considers itself closest to itself. ##Functionality:## Since this node does not require another domain to operate, this node can operate in the field. This node does not take into account the specifics of the geometry, all it needs is a field of points. In such a case, for each position index, one can find the index of another nearest position. ##Implementation design:## For implementation, it is considered to use the `KDTree` structure as a way to search for elements in a narrow space with selection according to the rule and checking for the closest to. --- ##Optional:## - Grouping: Based on the fact that geometry nodes use the group index to separate formal logic between abstractly separated sets of elements, grouping is also considered a useful feature of the node. The search implies two possible groupings: - Input groupings. Isolated search tasks. - Search groups. Isolated search in. If only these groups are counted, then the combinations are: |In/Search| No | Has | | No | Global search | No search. Essentially a mask function. | | Has | Isolated global search | Each group of points searches for the nearest one in its group. | - Inversion: Search can be handy. But if there are many points in each group, it may be necessary to find a neighbor not in another group, but in all the others. Also, if the search group is different from the point group, this means that inversion can mean searching even at other points in the group, but not at any particular group. - Range: The restriction for finding the nearest point can be limited not only by really close points, but also by intentionally remote ones. Or those that are not too far away. This means the ability to specify the maximum and minimum search distance. --- As an easy start to consider user feedback, it makes sense to add features one at a time to have real-time user feedback. In essence, this will only require you to add sockets and menu (as needed). So problems with versioning can be minimal. ##Name for such node:## I suggest Index of Nearest Discussion is open