Maniphest T93195

Geo Nodes: Order of Join Geometry Node seems to affect upstream index.
Closed, Archived
Actions

Assigned To
None
Authored By
Michael Hermann (245)
Nov 18 2021, 9:50 PM
Tags
  • BF Blender
Subscribers
Hans Goudey (HooglyBoogly)
Michael Hermann (245)
Philipp Oeser (lichtwerk)
Richard Antalik (ISS)

Description

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: rBf71813204c40

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

  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.blend1 MBDownload

Event Timeline

Michael Hermann (245) created this task.Nov 18 2021, 9:50 PM
Richard Antalik (ISS) added subscribers: Hans Goudey (HooglyBoogly), Richard Antalik (ISS).Nov 26 2021, 7:08 AM

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

Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Needs Information from User.Jan 31 2022, 12:35 PM
Philipp Oeser (lichtwerk) added a subscriber: Philipp Oeser (lichtwerk).

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 (245) added a comment.Feb 3 2022, 7:51 PM
In T93195#1298225, @Philipp Oeser (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.blend1 MBDownload

Philipp Oeser (lichtwerk) changed the task status from Needs Information from User to Needs Triage.Feb 3 2022, 7:55 PM
Hans Goudey (HooglyBoogly) closed this task as Archived.Feb 16 2022, 11:13 PM

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 (245) added a comment.Feb 17 2022, 10:44 AM

Thanks for taking the time!