Splitting the "Attribute Transfer" node #100010

New Issue

Hans Goudey · 2022-07-26T23:42:32+02:00

Hans Goudey commented

2022-07-26 23:42:32 +02:00

I propose to split the attribute transfer node into multiple smaller nodes.

History

{F13320174 size=full}	{F9904877 size=full}

The original "Attribute Transfer" node was inspired by the "Data Transfer" modifier.
This was before fields, so the workflow was mostly the same as for modifiers but with attribute names instead.
During the fields transition, we discussed changing the design, but there wasn't much time to consider alternatives.
Geometry nodes have changed significantly now, but we're still using the same design.

Problems

{F13320166 size=full}	{F13320168 size=full}	{F13320170 size=full}
There are quite a few problems with the current design:

Naming

After the fields transition, the node does not "Transfer" anything, it only retrieves data or samples it.
This makes the combinations of "Source", "Target", etc. very confusing.
Unlike other nodes, the name is based on a use case rather than what the node actually does.

Scope

With the current design, there is no limit to the scope of the transfer node. Anything that retrieves attributes from a geometry would fit.
When the node is responsible for so much, it gets slower and more confusing to use. I can't say "Try using the transfer attribute node," I have to say, "Try the transfer node in this mode with these options"

Inconsistency

We have other nodes like Raycast and Sample Curve (#91650) that retrieve attributes from a geometry. The current design says that they should be part of this node.
Even the sample volume node (D11353) would theoretically fit here, but the use case is entirely different.
Mixing the old pre-fields design and naming makes everything less intuitive.

Proposal

There are many very different ways to transfer attributes. Each significantly different method should be its own node, and they should be made more generic and flexible where possible.

1 Index	2 Nearest Element	3 Raycast	4 UV	5 Volume	6 Curve Parameter	7 Proximity Interpolated
{F13320229 size=full}	{F13320215 size=full}	{F13320235 size=full}	{F13320243 size=full}	{F13320252 size=full}	{F13320263 size=full}	{F13320279 size=full}

Index-based attribute retrieval is very simple
The "Nearest Element" is a generalization of finding close elements and retrieving their attribute values
The existing raycast node is also a way of retrieving attributes.
UV-based sampling is added in D15440
Volume sampling is added in D11353
#91650 is a task for sampling custom attributes in the sample curve node
The "Sample Mesh Surface" node is probably the place for more advanced methods that take into account other bits of mesh topology, like #97070 maybe.

Open Questions

Where does the "Geometry Proximity" node fit in? I think it should probably be merged with the proximity/interpolated transfer
Can we come up with a better name for "Sample Mesh Surface"?
Is this whole design missing something even more general and flexible?

I propose to split the attribute transfer node into multiple smaller nodes. ## History | {[F13320174](https://archive.blender.org/developer/F13320174/image.png) size=full} | {[F9904877](https://archive.blender.org/developer/F9904877/image.png) size=full} | | -- | -- | The original "Attribute Transfer" node was inspired by the "Data Transfer" modifier. This was before fields, so the workflow was mostly the same as for modifiers but with attribute names instead. During the fields transition, we discussed changing the design, but there wasn't much time to consider alternatives. Geometry nodes have changed significantly now, but we're still using the same design. ## Problems | {[F13320166](https://archive.blender.org/developer/F13320166/image.png) size=full} | {[F13320168](https://archive.blender.org/developer/F13320168/image.png) size=full} | {[F13320170](https://archive.blender.org/developer/F13320170/image.png) size=full} | | -- | -- | -- | There are quite a few problems with the current design: 1. **Naming** * After the fields transition, the node does not "Transfer" anything, it only retrieves data or samples it. * This makes the combinations of "Source", "Target", etc. very confusing. * Unlike other nodes, the name is based on a use case rather than what the node actually does. 2. **Scope** * With the current design, there is no limit to the scope of the transfer node. Anything that retrieves attributes from a geometry would fit. * When the node is responsible for so much, it gets slower and more confusing to use. I can't say "Try using the transfer attribute node," I have to say, "Try the transfer node in this mode with these options" 3. **Inconsistency** * We have other nodes like Raycast and Sample Curve (#91650) that retrieve attributes from a geometry. The current design says that they should be part of this node. * Even the sample volume node ([D11353](https://archive.blender.org/developer/D11353)) would theoretically fit here, but the use case is entirely different. * Mixing the old pre-fields design and naming makes everything less intuitive. ## Proposal There are many very different ways to transfer attributes. Each significantly different method should be its own node, and they should be made more generic and flexible where possible. | **1** Index | **2** Nearest Element | **3** Raycast | **4** UV | **5** Volume | **6** Curve Parameter | **7** Proximity Interpolated | | -- | -- | -- | -- | -- | -- | -- | | {[F13320229](https://archive.blender.org/developer/F13320229/image.png) size=full} | {[F13320215](https://archive.blender.org/developer/F13320215/image.png) size=full} | {[F13320235](https://archive.blender.org/developer/F13320235/image.png) size=full} | {[F13320243](https://archive.blender.org/developer/F13320243/image.png) size=full} | {[F13320252](https://archive.blender.org/developer/F13320252/image.png) size=full} | {[F13320263](https://archive.blender.org/developer/F13320263/image.png) size=full} | {[F13320279](https://archive.blender.org/developer/F13320279/image.png) size=full} 1. Index-based attribute retrieval is very simple 2. The "Nearest Element" is a generalization of finding close elements and retrieving their attribute values 3. The existing raycast node is also a way of retrieving attributes. 4. UV-based sampling is added in [D15440](https://archive.blender.org/developer/D15440) 5. Volume sampling is added in [D11353](https://archive.blender.org/developer/D11353) 6. #91650 is a task for sampling custom attributes in the sample curve node 7. The "Sample Mesh Surface" node is probably the place for more advanced methods that take into account other bits of mesh topology, like #97070 maybe. ## Open Questions * Where does the "Geometry Proximity" node fit in? I think it should probably be merged with the proximity/interpolated transfer * Can we come up with a better name for "Sample Mesh Surface"? * Is this whole design missing something even more general and flexible?

Hans Goudey commented

2022-07-26 23:42:32 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Hans Goudey commented

2022-07-26 23:42:32 +02:00

Added subscriber: @HooglyBoogly

Erindale commented

2022-07-27 00:44:15 +02:00

Added subscriber: @Erindale

Erindale commented

2022-07-27 00:44:15 +02:00

Might just be worth extending the "Sample" naming to Sample at Index and Sample Nearest Element. Raycasting is more of its own thing so that wouldn't want changing names.
I think Geometry Proximity would be in 2. Nearest Element wouldn't it? You can select which specific mesh element you're checking position of or distance to.
Distance is something you can easily find with a vector math node as well although it is very frequently used so would be a shame to drop it.

Might just be worth extending the "Sample" naming to Sample at Index and Sample Nearest Element. Raycasting is more of its own thing so that wouldn't want changing names. I think Geometry Proximity would be in 2. Nearest Element wouldn't it? You can select which specific mesh element you're checking position of or distance to. Distance is something you can easily find with a vector math node as well although it is very frequently used so would be a shame to drop it.

Steffen Dünner commented

2022-07-27 06:23:10 +02:00

Added subscriber: @SteffenD

D0ppelgaenger commented

2022-07-27 09:15:15 +02:00

Added subscriber: @Leo-Luther

D0ppelgaenger commented

2022-07-27 09:15:15 +02:00

A bit of a long shot, but I'll just throw it out there.
If they were to be reworked/changed, could the nearest Element node maybe get a toggle to "exclude self".
The issue so far has always been that you can't get the nearest from the same mesh as you are searching/casting from, because each element is always closest to itself.
With a toggle like this, you'd say give me the nearest element that is not myself, which should then return the nearest neighbor.
As said, a bit of a long shot, but a feature that could come in very handy imao.

A bit of a long shot, but I'll just throw it out there. If they were to be reworked/changed, could the nearest Element node maybe get a toggle to "exclude self". The issue so far has always been that you can't get the nearest from the same mesh as you are searching/casting from, because each element is always closest to itself. With a toggle like this, you'd say give me the nearest element that is not myself, which should then return the nearest neighbor. As said, a bit of a long shot, but a feature that could come in very handy imao.

Zhen Dai commented

2022-07-27 14:19:19 +02:00

Added subscriber: @Zhen-Dai

Zhen Dai commented

2022-07-27 14:19:19 +02:00

Another suggestion: Attribute Transfer is used to facilitate index sorting and selection a lot, can we somehow make that easier?

I use the following pattern a lot in my daily work, there must be a way to simplify and speed up this by default, especially over grouped indices.

https://blender.stackexchange.com/questions/266231/finding-the-index-of-longest-edge-with-geometry-nodes

Another suggestion: Attribute Transfer is used to facilitate index sorting and selection a lot, can we somehow make that easier? I use the following pattern a lot in my daily work, there must be a way to simplify and speed up this by default, especially over grouped indices. https://blender.stackexchange.com/questions/266231/finding-the-index-of-longest-edge-with-geometry-nodes

RedMser commented

2022-07-28 19:43:41 +02:00

Added subscriber: @RedMser

Hans Goudey commented

2022-08-01 20:06:59 +02:00

Might just be worth extending the "Sample" naming to Sample at Index and Sample Nearest Element. Raycasting is more of its own thing so that wouldn't want changing names.

Hmm, so Sample at Index, Sample Nearest Element, Raycast, Sample with UVs, Sample Volume, Sample Curve, Sample Mesh Surface.
I'm still not satisfied with the "Sample Mesh Surface" name. It doesn't distinguish the node from the "Nearest Element" properly. Or maybe that's a problem with the design...

I think Geometry Proximity would be in 2. Nearest Element wouldn't it? You can select which specific mesh element you're checking position of or distance to.
Distance is something you can easily find with a vector math node as well although it is very frequently used so would be a shame to drop it.

Agreed that they could be combined. However, there is a difference between the position of the closest face and the closest position on the closest face, so we'd probably still need the position output.
I would usually tend to remove redundant sockets like "Distance" but it seems fine if it stays too.

If they were to be reworked/changed, could the nearest Element node maybe get a toggle to "exclude self".

Since these nodes are meant to work on a separate geometry from the context geometry, that doesn't really make sense here.
That feature might make more sense in a field input node that doesn't have a geometry input.

Another suggestion: Attribute Transfer is used to facilitate index sorting and selection a lot, can we somehow make that easier?

Doesn't that come back to D13547? Or maybe we need a node to allow sorting somehow.

>Might just be worth extending the "Sample" naming to Sample at Index and Sample Nearest Element. Raycasting is more of its own thing so that wouldn't want changing names. Hmm, so `Sample at Index`, `Sample Nearest Element`, `Raycast`, `Sample with UVs`, `Sample Volume`, `Sample Curve`, `Sample Mesh Surface`. I'm still not satisfied with the "Sample Mesh Surface" name. It doesn't distinguish the node from the "Nearest Element" properly. Or maybe that's a problem with the design... > I think Geometry Proximity would be in 2. Nearest Element wouldn't it? You can select which specific mesh element you're checking position of or distance to. > Distance is something you can easily find with a vector math node as well although it is very frequently used so would be a shame to drop it. Agreed that they could be combined. However, there is a difference between the position **of** the closest face and the closest position **on** the closest face, so we'd probably still need the position output. I would usually tend to remove redundant sockets like "Distance" but it seems fine if it stays too. > If they were to be reworked/changed, could the nearest Element node maybe get a toggle to "exclude self". Since these nodes are meant to work on a separate geometry from the context geometry, that doesn't really make sense here. That feature might make more sense in a field input node that doesn't have a geometry input. > Another suggestion: Attribute Transfer is used to facilitate index sorting and selection a lot, can we somehow make that easier? Doesn't that come back to [D13547](https://archive.blender.org/developer/D13547)? Or maybe we need a node to allow sorting somehow.

Paul Larson commented

2022-08-01 21:44:43 +02:00

Added subscriber: @GeorgiaPacific

Leonard Siebeneicher commented

2022-09-07 15:38:59 +02:00

Added subscriber: @LeonardSiebeneicher

blender-admin commented

2022-09-23 20:56:35 +02:00

This issue was referenced by dedc679eca

This issue was referenced by dedc679ecabb43e79b0160a7c64bbd616adfa829

Michael Soluyanov commented

2022-10-05 12:20:14 +02:00

Added subscriber: @crantisz

Michael Soluyanov commented

2022-10-05 12:20:14 +02:00

I personally like the way how the nodes were grouped into one. The adding menu is huge already, so that grouping nodes with same functionality seems to be good idea, otherwise, why don't you "ungroup" math node and vector math node?

Pauan commented

2022-10-13 00:09:53 +02:00

Added subscriber: @pauanyu_blender

Jacques Lucke commented

2022-10-20 15:16:42 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Jacques Lucke closed this issue

2022-10-20 15:16:42 +02:00

Jacques Lucke self-assigned this 2022-10-20 15:16:42 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Splitting the "Attribute Transfer" node #100010

History

Problems

Proposal

Open Questions