Regression: Attribute capture yields broken results #98298

New Issue

kursad k · 2022-05-21T04:44:38+02:00

kursad k commented

2022-05-21 04:44:38 +02:00

System Information
Operating system: Win 11

Blender Version
Broken: f600a2aa6d (3.3 alpha), 1a627d528c (3.2 beta)
Worked: 3.1 release

Behavior changed in 2e70af5cd5

Short description of error

It seems like the attribute capture in 3.3. and 3.2 generates some kind of broken range, when I say broken I am comparing it to the result I get from the 3.1 release. The node setup in the blend file generates edges with tubes from a given vertex group.

Please see the images below.

Blender 3.1 release, this is the expected result and it is the result that also worked in 3.2 at some point because I originally tested this in 3.2. It only works in 3.1 now.

Blender 3.2 and 3.3 result

Exact steps for others to reproduce the error

Load the attached .blend file in 3.1

Load the attached .blend file in 3.2

Load the attached .blend file in 3.3

capture_20052022_2135_40.blend

**System Information** Operating system: Win 11 **Blender Version** Broken: f600a2aa6df1 (3.3 alpha), 1a627d528cf9 (3.2 beta) Worked: 3.1 release Behavior changed in 2e70af5cd5 **Short description of error** It seems like the attribute capture in 3.3. and 3.2 generates some kind of broken range, when I say broken I am comparing it to the result I get from the 3.1 release. The node setup in the blend file generates edges with tubes from a given vertex group. Please see the images below. Blender 3.1 release, this is the expected result and it is the result that also worked in 3.2 at some point because I originally tested this in 3.2. It only works in 3.1 now. ![image.png](https://archive.blender.org/developer/F13096000/image.png) Blender 3.2 and 3.3 result ![blender_dMMOc3Aqx4.jpg](https://archive.blender.org/developer/F13096002/blender_dMMOc3Aqx4.jpg) **Exact steps for others to reproduce the error** Load the attached .blend file in 3.1 Load the attached .blend file in 3.2 Load the attached .blend file in 3.3 [capture_20052022_2135_40.blend](https://archive.blender.org/developer/F13096005/capture_20052022_2135_40.blend)

kursad k commented

2022-05-21 04:44:38 +02:00

Added subscriber: @kursadk

Philipp Oeser commented

2022-05-21 10:58:00 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2022-05-21 10:58:00 +02:00

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

Philipp Oeser commented

2022-05-21 10:58:00 +02:00

Can confirm, will check.

Philipp Oeser commented

2022-05-23 09:47:41 +02:00

Added subscriber: @JacquesLucke

Philipp Oeser commented

2022-05-23 09:47:41 +02:00

Behavior changed in 2e70af5cd5

@JacquesLucke : this seems wrong on first sight, in the example there are zero weights that were captured as zero ints prior to 2e70af5cd5
{F13099819 size=full}

This might be intended behavior, looks like a bug to me though, can you clarify?
Will set to High prio for now since this seems like a regression, no?

Behavior changed in 2e70af5cd5 @JacquesLucke : this seems wrong on first sight, in the example there are zero weights that were captured as zero ints prior to 2e70af5cd5 {[F13099819](https://archive.blender.org/developer/F13099819/T98298.png) size=full} This might be intended behavior, looks like a bug to me though, can you clarify? Will set to High prio for now since this seems like a regression, no?

Philipp Oeser changed title from ~~Attribute capture yields broken results~~ to Regression: Attribute capture yields broken results

2022-05-23 09:48:18 +02:00

Jacques Lucke commented

2022-05-23 10:40:27 +02:00

Changed status from 'Confirmed' to: 'Archived'

Jacques Lucke closed this issue

2022-05-23 10:40:27 +02:00

Jacques Lucke commented

2022-05-23 10:40:27 +02:00

From what I can tell, the Attribute Capture node works perfectly fine here (check with the Viewer node in the spreadsheet).
The problem is that the Mesh to Curve node expects an edge selection, however you provide a point attribute. That's generally not an issue, because the node would just interpolate the point to an edge attribute, but in this specific case the interpolation does not do what you want.

In your example, every point either has value 0 or 1 after the Capture node. When that is interpolated to edges, the following is done:

Edges where both points have value 0, also get value 0.
Edges where both points have value 1, also get value 1.
Edges where one point has value 0 and the other 1, get value 1. That's because when both values are mixed, the result is 0.5, and that is rounded to 1. This is what changed in 2e70af5cd5. Previously it would always simply cut off the decimal places, which was just wrong.

So the new behavior is indeed the expected behavior, and there is no bug.

Generally, the solution for you is to be more explicit about what you want and to rely less on the automatic type/domain conversion for selections. Here are two possible solutions:

Here the attribute is interpolated to edges as a float, so that there is a 0, 0.5 or 1 value per edge. Then a Compare node can be used to just select edges with value 1.

{F13099951}

Here the points that you don't want to create curves from are deleted first.

{F13099962}

From what I can tell, the Attribute Capture node works perfectly fine here (check with the Viewer node in the spreadsheet). The problem is that the `Mesh to Curve` node expects an edge selection, however you provide a point attribute. That's generally not an issue, because the node would just interpolate the point to an edge attribute, but in this specific case the interpolation does not do what you want. In your example, every point either has value 0 or 1 after the Capture node. When that is interpolated to edges, the following is done: * Edges where both points have value 0, also get value 0. * Edges where both points have value 1, also get value 1. * Edges where one point has value 0 and the other 1, get value 1. That's because when both values are mixed, the result is 0.5, and that is rounded to 1. This is what changed in 2e70af5cd5. Previously it would always simply cut off the decimal places, which was just wrong. So the new behavior is indeed the expected behavior, and there is no bug. Generally, the solution for you is to be more explicit about what you want and to rely less on the automatic type/domain conversion for selections. Here are two possible solutions: * Here the attribute is interpolated to edges as a float, so that there is a 0, 0.5 or 1 value per edge. Then a Compare node can be used to just select edges with value 1. ``` {F13099951} ``` * Here the points that you don't want to create curves from are deleted first. ``` {F13099962}

Philipp Oeser commented

2022-05-23 10:52:57 +02:00

Thx for the explanation @JacquesLucke , indeed my findings on the capture itself were wrong (this was based on the final outcome, not on the actual values in the spreadsheet)

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

Regression: Attribute capture yields broken results #98298