Attribute Map node #103457

New Issue

Iliya Katushenock · 2022-12-24T20:19:16+01:00

Iliya Katushenock commented

2022-12-24 20:19:16 +01:00

Node for associative indexing of values by an arbitrary number of incoming integer set and lookup keys.

This node must accept the input of a geometry, a random type value, and a set of keys.
The node has evaluation domain parameters.
For the search, a lot of integer keys are introduced. They already belong to the context of the evaluator.
Now, the result is a value whose keys fully match the element of the evaluated geometry.

Text representation of the functionality:

{
  {{0, 1, 55} : A},
  {{0, 2, -0} : B},
  ...
}[{0, 1, 55}] == A

Key intersections:

Value may be outputed that there was an intersection, but give the first value.
Value may be outputted that there was no valid, and return 0.
Mean additional int input to index identical keys (or allow +1 key to search in multi-input)
Ignore the problem by simply returning the first instance

If the keys had no intersection, a validity value may be outputed

Implementation:
Allow field handling for multi-input sockets.
Follow the first working instance of the node, without solving the intersection problem, in order to get feedback from users.

Technical question:
Based on a few experiments {D16256}, it became clear that the best option would be to build maps for each array of keys [Key]{index}
After that, a parallel search in all maps and checking the equality of the found indices for all keys.
There may be more productive solutions, open to suggestions.

Node for associative indexing of values by an arbitrary number of incoming integer set and lookup keys. This node must accept the input of a geometry, a random type value, and a set of keys. The node has evaluation domain parameters. For the search, a lot of integer keys are introduced. They already belong to the context of the evaluator. Now, the result is a value whose keys fully match the element of the evaluated geometry. Text representation of the functionality: ```lang=c++ { {{0, 1, 55} : A}, {{0, 2, -0} : B}, ... }[{0, 1, 55}] == A ``` Key intersections: - Value may be outputed that there was an intersection, but give the first value. - Value may be outputted that there was no valid, and return 0. - Mean additional int input to index identical keys (or allow +1 key to search in multi-input) - Ignore the problem by simply returning the first instance If the keys had no intersection, a validity value may be outputed Implementation: Allow field handling for multi-input sockets. Follow the first working instance of the node, without solving the intersection problem, in order to get feedback from users. Technical question: Based on a few experiments {D16256}, it became clear that the best option would be to build maps for each array of keys `[Key]{index}` After that, a parallel search in all maps and checking the equality of the found indices for all keys. There may be more productive solutions, open to suggestions.

Iliya Katushenock commented

2022-12-24 20:19:16 +01:00

Added subscriber: @mod_moder

Shmuel Israel commented

2022-12-25 05:28:55 +01:00

Added subscriber: @shmuel

Shmuel Israel commented

2022-12-25 05:28:55 +01:00

I propose an "Is Valid" boolean output and an additional drop down menu for the key value type [float, integer, vector] (I don't think a boolean key will be useful).
,so you'd have 3 drop downs 1 - domain type, 2 - sampled value type, and 3 - the key type.

Another idea to think about would be an option to have interpretation with keys in-between float and vector values [weighted based on what value they are closest to].

I propose an "Is Valid" boolean output and an additional drop down menu for the key value type [float, integer, vector] (I don't think a boolean key will be useful). ,so you'd have 3 drop downs 1 - domain type, 2 - sampled value type, and 3 - the key type. Another idea to think about would be an option to have interpretation with keys in-between float and vector values [weighted based on what value they are closest to].

Iliya Katushenock commented

2022-12-25 11:04:32 +01:00

No, keys of different types do not make sense. If you really think about it, you can always use a hash node to turn vectors into ints.
Yes, the issue of how to compare vectors and floats without epsilon is important, so it just doesn't make sense.

No, keys of different types do not make sense. If you really think about it, you can always use a hash node to turn vectors into ints. Yes, the issue of how to compare vectors and floats without epsilon is important, so it just doesn't make sense.

Shmuel Israel commented

2022-12-25 22:25:15 +01:00

In #103457#1465583, @mod_moder wrote:
No, keys of different types do not make sense. If you really think about it, you can always use a hash node to turn vectors into ints.
Yes, the issue of how to compare vectors and floats without epsilon is important, so it just doesn't make sense.

what is a hash node?

> In #103457#1465583, @mod_moder wrote: > No, keys of different types do not make sense. If you really think about it, you can always use a hash node to turn vectors into ints. > Yes, the issue of how to compare vectors and floats without epsilon is important, so it just doesn't make sense. what is a hash node?

Iliya Katushenock commented

2022-12-26 06:05:03 +01:00

D15835: Function Node: Hash Value

[D15835: Function Node: Hash Value](https://archive.blender.org/developer/D15835)

Shmuel Israel commented

2022-12-29 01:24:41 +01:00

In #103457#1465583, @mod_moder wrote:
No, keys of different types do not make sense. If you really think about it, you can always use a hash node to turn vectors into ints.
Yes, the issue of how to compare vectors and floats without epsilon is important, so it just doesn't make sense.

I still think it's a good idea to have an option for interpretation which would only work (or work better) with floats and vectors

> In #103457#1465583, @mod_moder wrote: > No, keys of different types do not make sense. If you really think about it, you can always use a hash node to turn vectors into ints. > Yes, the issue of how to compare vectors and floats without epsilon is important, so it just doesn't make sense. I still think it's a good idea to have an option for interpretation which would only work (or work better) with floats and vectors

Iliya Katushenock commented

2022-12-29 06:30:56 +01:00

The nearest values have a geometric meaning. Finding them is best delegated to various kinds of methods for finding the nearest values.

Iliya Katushenock referenced this issue

2023-02-11 17:14:53 +01:00

Geometry Node: Index Map node #104621

Iliya Katushenock added this to the Nodes & Physics project 2023-02-12 13:15:57 +01:00

Iliya Katushenock removed the

Module

Nodes & Physics

label 2023-04-22 14:25:09 +02:00

Iliya Katushenock referenced this issue

2023-04-24 18:42:02 +02:00

Merge by Distance node re-indexes points non-determinstically. #107306

Iliya Katushenock removed the

Status

Needs Triage

label 2023-04-24 18:49:19 +02:00

Shmuel Israel commented

2023-07-31 22:58:35 +02:00

what's the status on this? I don't mean to push, I'm just curious; I've recently had to do some associative transferring (I used the sample nearest method). I remembered this was up for a while and I'm wondering what's up.

Iliya Katushenock commented

2023-07-31 22:59:45 +02:00

Low priority task now..

Shmuel Israel commented

2023-07-31 23:38:23 +02:00

how to up priority? is there a vote thing, get more participants... or is it entirely up to the developers?

Iliya Katushenock commented

2023-08-02 02:04:17 +02:00

Application examples, community interest
And I should probably do a couple of implementation updates..

Application examples, community interest And I should probably do a couple of implementation updates..

Shmuel Israel commented

2023-08-02 14:54:37 +02:00

by application examples do you mean use cases or implementation on your part? because I have a lot of use cases.

Iliya Katushenock commented

2023-08-02 14:56:41 +02:00

Right, it would be much helpful

Shmuel Israel commented

2023-08-02 15:23:17 +02:00

where should I share them?

Iliya Katushenock commented

2023-08-02 15:33:57 +02:00

But this is difficult)
First of all, this can not be done here, because in theory, this is only for discussion of design.
Then, this can't be done on the forum, as it's also discussion-only.
Maybe twitter (although I will have difficulty with that). So first of all, it would be better to do it in the form of videos / screenshots of examples of work in various social networks (YouTube, ...). But for this, I first need to update the node, it has long been outdated, a lot of things in the code have changed in half a year...

But this is difficult) First of all, this can not be done here, because in theory, this is only for discussion of design. Then, this can't be done on the forum, as it's also discussion-only. Maybe twitter (although I will have difficulty with that). So first of all, it would be better to do it in the form of videos / screenshots of examples of work in various social networks (YouTube, ...). But for this, I first need to update the node, it has long been outdated, a lot of things in the code have changed in half a year...

Shmuel Israel commented

2023-08-02 16:59:37 +02:00

D15835: Function Node: Hash Value

btw what happened to this?

> [D15835: Function Node: Hash Value](https://archive.blender.org/developer/D15835) btw what happened to this?

Iliya Katushenock commented

2023-08-02 17:19:36 +02:00

@shmuel https://blender.chat/channel/nodes-physics-module?msg=STRmwN5vaFwkJ5pDS

Charlie Jolly referenced this issue

2023-08-03 17:02:34 +02:00

Function Node: Hash Value #110769

Erindale commented

2023-08-03 22:43:39 +02:00

Looks very promising! I agree with the int key value. Doesn't make much sense to me for floats or vectors, especially if there was a hash node.
Going to be very useful in replacing the current method of set position to field, sample nearest. I assume also much faster.

Looks very promising! I agree with the int key value. Doesn't make much sense to me for floats or vectors, especially if there was a hash node. Going to be very useful in replacing the current method of set position to field, sample nearest. I assume also much faster.

Shmuel Israel commented

2023-08-04 02:15:34 +02:00

may I recommend having two versions of this node like the sample index and evaluate at index, we should have an attribute map node with a geometry input and an attribute map node without a geometry input; maybe call in "evaluate at key" or something.

may I recommend having two versions of this node like the *sample index* and *evaluate at index*, we should have an *attribute map* node **with** a geometry input and an *attribute map* node **without** a geometry input; maybe call in "evaluate at key" or something.

Shmuel Israel commented

2023-08-04 15:08:14 +02:00

design question: should we output the index of the element from this node (/nodes) to be used in sample index (/evaluate at index), or sample the value directly in this node?

performance is very important, so if sampling it directly is faster by any significant margin, then we should go with that, otherwise we can go with a similar idea to the sample nearest - where we output the index.

now thinking about it, an index output sounds like it could be a better idea, especially when sampling multi values...

design question: should we output the index of the element from this node (/nodes) to be used in sample index (/evaluate at index), or sample the value directly in this node? performance is very important, so if sampling it directly is faster by any significant margin, then we should go with that, otherwise we can go with a similar idea to the sample nearest - where we output the index. now thinking about it, an index output sounds like it could be a better idea, especially when sampling multi values...

Iliya Katushenock commented

2023-08-04 15:14:52 +02:00

@shmuel No, if we are not interpolating values, then we should only work with the index.