Geo Nodes: Order of Join Geometry Node seems to affect upstream index. #93195

New Issue

Michael Hermann · 2021-11-18T21:50:16+01:00

Michael Hermann commented

2021-11-18 21:50:16 +01:00

System Information
Operating system: Linux-5.14.16-arch1-1-x86_64-with-glibc2.33 64 Bits
Graphics card: NVIDIA GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 495.44

Blender Version
Broken: version: 3.0.0 Beta, branch: master, commit date: 2021-11-18 13:27, hash: f71813204c

Short description of error
The order in which Geometry is plugged into the Join Geometry Node seems to have an effect on the upstream index. - The result of an upstream Transfer Attribute changes depending on the order. I think it becomes clear when looking at the attached .blend file. (Description is in the Node Tree)
I don't know if this is a bug or not, but to me at least, it is unexpected behavior.

Here is an image of the expected output:

However, when the Geo for the cubes is in the lower position the result is this:

Exact steps for others to reproduce the error

Open Attached blend file
Switch to Rendered View
Switch the order of the inputs of the Join Geometry node in the red frame.

GN_joinGeo_issue.blend

**System Information** Operating system: Linux-5.14.16-arch1-1-x86_64-with-glibc2.33 64 Bits Graphics card: NVIDIA GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 495.44 **Blender Version** Broken: version: 3.0.0 Beta, branch: master, commit date: 2021-11-18 13:27, hash: `f71813204c` **Short description of error** The order in which Geometry is plugged into the Join Geometry Node seems to have an effect on the upstream index. - The result of an upstream Transfer Attribute changes depending on the order. I think it becomes clear when looking at the attached .blend file. (Description is in the Node Tree) I don't know if this is a bug or not, but to me at least, it is unexpected behavior. Here is an image of the expected output: ![Correct.png](https://archive.blender.org/developer/F11826273/Correct.png) However, when the Geo for the cubes is in the lower position the result is this: ![Incorrect.png](https://archive.blender.org/developer/F11826276/Incorrect.png) **Exact steps for others to reproduce the error** 1. Open Attached blend file 2. Switch to Rendered View 3. Switch the order of the inputs of the Join Geometry node in the red frame. [GN_joinGeo_issue.blend](https://archive.blender.org/developer/F11826278/GN_joinGeo_issue.blend)

Michael Hermann commented

2021-11-18 21:50:16 +01:00

Added subscriber: @MichaelHermann

Richard Antalik commented

2021-11-26 07:08:05 +01:00

Added subscribers: @HooglyBoogly, @iss

Richard Antalik commented

2021-11-26 07:08:05 +01:00

This is bit too complex for me to immediately see what happens here. @HooglyBoogly Can you check this report?

Philipp Oeser commented

2022-01-31 12:35:03 +01:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2022-01-31 12:35:03 +01:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Philipp Oeser commented

2022-01-31 12:35:03 +01:00

Can confirm the behavior.

Could this however be demonstrated in a simpler file please?
e.g., does this only happen with multiple Transfer Attributes? Does it only happen with realized instances?

It is always desirable to have the minimal example case for reproduction.

Thx, will set to "Needs Information from User" until this can be simplified further.

Can confirm the behavior. Could this however be demonstrated in a simpler file please? e.g., does this only happen with multiple Transfer Attributes? Does it only happen with realized instances? It is always desirable to have the minimal example case for reproduction. Thx, will set to "Needs Information from User" until this can be simplified further.

Michael Hermann commented

2022-02-03 19:51:58 +01:00

In #93195#1298225, @lichtwerk wrote:
Could this however be demonstrated in a simpler file please?
[...]
It is always desirable to have the minimal example case for reproduction.

Hi! Yes, I am totally aware and try to do this where possible. I think, when reporting this bug, I had spent quite some time simplifying and cleaning the file as much as possible, but couldn't remove anything else and still clearly see the problem.

e.g., does this only happen with multiple Transfer Attributes? Does it only happen with realized instances?

I've taken another look now and checked your questions.

Disable one Transfer Attribute: Problem still there.
Disable the Realize Instances: No way to tell, because everything disappears
Disable both, TA and RI: Problem is gone. (i.e. switching the inputs to the Join Geo doesn't change the result) - However, then the whole setup is broken and I can't visually tell if it's doing the right thing. (Which might not be relevant.)

So, the last point might actually be a clue.

I've added a green frame around the two nodes I'm talking about and added the file here.
GN_joinGeo_issue_220203.blend

> In #93195#1298225, @lichtwerk wrote: > Could this however be demonstrated in a simpler file please? > [...] > It is always desirable to have the minimal example case for reproduction. Hi! Yes, I am totally aware and try to do this where possible. I think, when reporting this bug, I had spent quite some time simplifying and cleaning the file as much as possible, but couldn't remove anything else and still clearly see the problem. > e.g., does this only happen with multiple Transfer Attributes? Does it only happen with realized instances? I've taken another look now and checked your questions. - Disable one Transfer Attribute: Problem still there. - Disable the Realize Instances: No way to tell, because everything disappears - Disable both, TA and RI: Problem is gone. (i.e. switching the inputs to the Join Geo doesn't change the result) - However, then the whole setup is broken and I can't visually tell if it's doing the right thing. (Which might not be relevant.) So, the last point might actually be a clue. I've added a green frame around the two nodes I'm talking about and added the file here. [GN_joinGeo_issue_220203.blend](https://archive.blender.org/developer/F12844262/GN_joinGeo_issue_220203.blend)

Philipp Oeser commented

2022-02-03 19:55:29 +01:00

Changed status from 'Needs User Info' to: 'Needs Triage'

Hans Goudey commented

2022-02-16 23:13:14 +01:00

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

Hans Goudey closed this issue

2022-02-16 23:13:14 +01:00

Hans Goudey commented

2022-02-16 23:13:14 +01:00

Sorry for the delayed response. I messed around with this file for a while. I didn't see any indication that there's a bug here.

This setup might be more complicated than is obvious because there are multiple layers of transfer nodes in index mode. Remember that these nodes don't output arrays of values, they output fields that are then evaluated at the final geometry.
With that in mind, it makes perfect sense that changing the order of the inputs to the join node changes the result, since the indices in the final geometry are different.

As for the changing "Sphere Age" values on frame 72 for the "outer" sphere, I didn't see any indication of a bug there easily. I think it's more likely that there's a non-intuitive dependence between the values and indices of the geometry you created with the node setup.

With all that in mind, and because the second part sort of comes down to "the animation looks different on a specific frame", I think I'll close this report.
If you end up at a point where there's more clarity, i.e. "This node is meant to do ..., but it's doing something else", then please don't hesitate to open another report.

Sorry for the delayed response. I messed around with this file for a while. I didn't see any indication that there's a bug here. This setup might be more complicated than is obvious because there are multiple layers of transfer nodes in index mode. Remember that these nodes don't output arrays of values, they output fields that are then evaluated at the final geometry. With that in mind, it makes perfect sense that changing the order of the inputs to the join node changes the result, since the indices in the final geometry are different. As for the changing "Sphere Age" values on frame 72 for the "outer" sphere, I didn't see any indication of a bug there easily. I think it's more likely that there's a non-intuitive dependence between the values and indices of the geometry you created with the node setup. With all that in mind, and because the second part sort of comes down to "the animation looks different on a specific frame", I think I'll close this report. If you end up at a point where there's more clarity, i.e. "This node is meant to do ..., but it's doing something else", then please don't hesitate to open another report.

Michael Hermann commented

2022-02-17 10:44:06 +01:00

Thanks for taking the time!

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

Geo Nodes: Order of Join Geometry Node seems to affect upstream index. #93195