Geometry Nodes: Writing an attribute of type 'color' directly to the position attribute has no effect. #85864

New Issue

Leon Schittek · 2021-02-22T06:27:34+01:00

Leon Schittek commented

2021-02-22 06:27:34 +01:00

System Information
Operating system: Darwin-18.7.0-x86_64-i386-64bit 64 Bits
Graphics card: Intel Iris OpenGL Engine Intel Inc. 4.1 INTEL-12.10.16

Blender Version
Broken: version: 2.93.0 Alpha, branch: master, commit date: 2021-02-21 23:22, hash: af940c68cb
Worked: (newest version of Blender that worked as expected)

Short description of error
Writing to the position attribute doesn't work when using an attribute of type 'color'.
This means: Directly writing the output of the Attribute Sample Texture node to the position attribute or mixing colors with the Attribute Mix node with the result set to "position" has no effect.
Both cases work for the rotation and scale attributes.
Explicitly converting the color attribute to a vector attribute first using a Vector Math Node works as expected.

position-attribute-bug.mp4

Exact steps for others to reproduce the error
From startup file:

Add a Geometry Nodes modifier to the default cube
Add an Attribute Sample Texture node, plug it in between input and output node. Add a new Texture and set the result to "position".
The position of the vertices will be unaffected.

From the .blend-file in the video:

open the file and plug in different Attribute Sample Texture nodes into the Point Distribute node. The one with the Result set to "position" will have no effect.
sample-texture-position-bug.blend

**System Information** Operating system: Darwin-18.7.0-x86_64-i386-64bit 64 Bits Graphics card: Intel Iris OpenGL Engine Intel Inc. 4.1 INTEL-12.10.16 **Blender Version** Broken: version: 2.93.0 Alpha, branch: master, commit date: 2021-02-21 23:22, hash: `af940c68cb` Worked: (newest version of Blender that worked as expected) **Short description of error** Writing to the position attribute doesn't work when using an attribute of type 'color'. This means: Directly writing the output of the Attribute Sample Texture node to the position attribute or mixing colors with the Attribute Mix node with the result set to "position" has no effect. Both cases work for the rotation and scale attributes. Explicitly converting the color attribute to a vector attribute first using a Vector Math Node works as expected. [position-attribute-bug.mp4](https://archive.blender.org/developer/F9827360/position-attribute-bug.mp4) **Exact steps for others to reproduce the error** From startup file: - Add a Geometry Nodes modifier to the default cube - Add an Attribute Sample Texture node, plug it in between input and output node. Add a new Texture and set the result to "position". - The position of the vertices will be unaffected. From the .blend-file in the video: - open the file and plug in different Attribute Sample Texture nodes into the Point Distribute node. The one with the Result set to "position" will have no effect. [sample-texture-position-bug.blend](https://archive.blender.org/developer/F9827364/sample-texture-position-bug.blend)

Leon Schittek commented

2021-02-22 06:27:34 +01:00

Added subscriber: @lone_noel

Hans Goudey commented

2021-02-22 07:14:18 +01:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2021-02-22 07:14:18 +01:00

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

Hans Goudey commented

2021-02-22 07:14:18 +01:00

Thanks for the report and the clear test file. This is likely a known issue at the moment, but I think we should address it.
The difference here is that position is the only built-in attribute, so its type can not be changed.
For the others, (scale, rotation), AFAIK they are actually created with a color data type, but since there is implicit conversion back to float, you don't notice it.

I think this comes down to how we've implemented the data type conversion for writing to an attribute's values. It always uses the new type by removing the old attribute and creating a new one.
I think there are many cases where we'd want to use interpolation instead. Built-in attributes are the most obvious case of course, but there may be others.

Not sure if that makes sense, but I wanted to write it down somewhere anyway.

Thanks for the report and the clear test file. This is likely a known issue at the moment, but I think we should address it. The difference here is that `position` is the only built-in attribute, so its type can not be changed. For the others, (`scale`, `rotation`), AFAIK they are actually created with a color data type, but since there is implicit conversion back to float, you don't notice it. I think this comes down to how we've implemented the data type conversion for writing to an attribute's values. It always uses the new type by removing the old attribute and creating a new one. I think there are many cases where we'd want to use interpolation instead. Built-in attributes are the most obvious case of course, but there may be others. Not sure if that makes sense, but I wanted to write it down somewhere anyway.

Leon Schittek commented

2021-02-22 08:21:16 +01:00

I see, that's good to know. Thanks for the insight!

Charlie Jolly commented

2021-02-22 14:20:55 +01:00

Added subscriber: @CharlieJolly

Charlie Jolly commented

2021-02-22 14:20:55 +01:00

In this case, could there be an implicit conversion of rgb(-a) to position when using this node and add a node warning that there is potential data loss.

In future there could be a node to convert color4f to float3 with options on how to handle the alpha value or this could be added to any node that handles color.

In this case, could there be an implicit conversion of rgb(-a) to position when using this node and add a node warning that there is potential data loss. In future there could be a node to convert color4f to float3 with options on how to handle the alpha value or this could be added to any node that handles color.

Hans Goudey commented

2021-03-17 18:01:55 +01:00

Closed as duplicate of #86633

Hans Goudey closed this issue

2021-03-17 18:01:55 +01:00

Faster commented

2021-11-22 03:30:12 +01:00

(Migrated from localhost:3001)

Added subscriber: @Faster

Faster commented

2021-11-22 03:30:12 +01:00

(Migrated from localhost:3001)