Geometry nodes material index attribute not working correctly on generated/instanced geometry #87335

New Issue

Simon Thommes · 2021-04-09T12:31:18+02:00

Simon Thommes commented

2021-04-09 12:31:18 +02:00

System Information
Operating system: Linux-5.8.0-7630-generic-x86_64-with-glibc2.32 64 Bits
Graphics card: Quadro RTX 6000/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.32.03

Blender Version
Broken: version: 2.93.0 Alpha, branch: master, commit date: 2021-04-08 17:19, hash: 1ec9ac2016
FYI, the history on this:
prior to 1a81d268a1 this was working in editmode (but not objectmode)
after 1a81d268a1 no material was shown in the viewport at all
then with 6583fb67c6 we had first material showing again, but setting index was not working in either objectmode nor editmode

Short description of error
changing the material_index attribute does not seem to have an effect on created/instanced data, even though the material index seems to change accurately in the spreadsheet and the material slots are set to Object type. What is especially strange about this is that the issue does not persist for cycles rendering.
geo-nodes_material_index_bug-2021-04-09_12.25.49.mp4
(same for geometry generated with a primitive node)

Exact steps for others to reproduce the error
Original file:
geo-nodes_material_index_viewport.blend

Updated to fields:
geo-nodes_material_index_viewport.blend

**System Information** Operating system: Linux-5.8.0-7630-generic-x86_64-with-glibc2.32 64 Bits Graphics card: Quadro RTX 6000/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 460.32.03 **Blender Version** Broken: version: 2.93.0 Alpha, branch: master, commit date: 2021-04-08 17:19, hash: `1ec9ac2016` FYI, the history on this: prior to 1a81d268a1 this was working in editmode (but not objectmode) after 1a81d268a1 no material was shown in the viewport at all then with 6583fb67c6 we had first material showing again, but setting index was not working in either objectmode nor editmode **Short description of error** changing the material_index attribute does not seem to have an effect on created/instanced data, even though the material index seems to change accurately in the spreadsheet and the material slots are set to `Object` type. What is especially strange about this is that the issue does not persist for cycles rendering. [geo-nodes_material_index_bug-2021-04-09_12.25.49.mp4](https://archive.blender.org/developer/F9926700/geo-nodes_material_index_bug-2021-04-09_12.25.49.mp4) (same for geometry generated with a primitive node) **Exact steps for others to reproduce the error** Original file: [geo-nodes_material_index_viewport.blend](https://archive.blender.org/developer/F9926701/geo-nodes_material_index_viewport.blend) Updated to fields: [geo-nodes_material_index_viewport.blend](https://archive.blender.org/developer/F11777686/geo-nodes_material_index_viewport.blend)

Simon Thommes commented

2021-04-09 12:31:18 +02:00

Added subscriber: @SimonThommes

blender-admin commented

2021-04-09 12:31:18 +02:00

#95417 was marked as duplicate of this issue

blender-admin commented

2021-04-09 12:31:18 +02:00

#87786 was marked as duplicate of this issue

Simon Thommes commented

2021-04-09 12:32:01 +02:00

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

Jacques Lucke commented

2021-04-09 12:51:09 +02:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2021-04-09 12:51:09 +02:00

Looks like the issue is that the material slots on the mesh and the object are not in sync. The number of material slots on the other object and on the grid mesh is zero. Eevee seems to check the number of materials, while cycles probably handles it differently. Since the number of materials on the mesh is zero, eevee does not look for materials on the object.
A workaround in your demo file is to add some material slots to the icosphere.

This commit fixes a related issue: 3de5fbba3a
Also related: #86737.

Looks like the issue is that the material slots on the mesh and the object are not in sync. The number of material slots on the other object and on the grid mesh is zero. Eevee seems to check the number of materials, while cycles probably handles it differently. Since the number of materials on the mesh is zero, eevee does not look for materials on the object. A workaround in your demo file is to add some material slots to the icosphere. This commit fixes a related issue: 3de5fbba3a Also related: #86737.

Zijun Zhou commented

2021-04-09 17:26:52 +02:00

Added subscriber: @Eary

Zijun Zhou commented

2021-04-09 17:26:52 +02:00

I encountered this problem a few weeks ago, and after discussion with my friends, we came to the conclusion that all we needed to do for solving the problem is this:

So basically the icosphere needs to have the same amount of slots (even empty slots count) as the geometry node object

EDIT: Ops, I didn't see Jacques' reply, I guess I am just repeating what he said, lol

I encountered this problem a few weeks ago, and after discussion with my friends, we came to the conclusion that all we needed to do for solving the problem is this: ![image.png](https://archive.blender.org/developer/F9926904/image.png) So basically the icosphere needs to have the same amount of slots (even empty slots count) as the geometry node object EDIT: Ops, I didn't see Jacques' reply, I guess I am just repeating what he said, lol

Nathan Vasil commented

2021-08-18 19:39:31 +02:00

Added subscriber: @vasiln

Nathan Vasil commented

2021-08-18 19:39:31 +02:00

Note that this can also interact with instancing a collection. In this case, the workaround doesn't help (in 2.93.3 release.) It appears that the entire collection gets a set of materials that depends on the order that objects were created, or the order of input noodles in any join geometry nodes, or something else:

Here, it's getting the material of the first created object in the collection, rather than the materials of any other objects. Changing the material index assignment does nothing. I've renamed the first created object to "z" to see if it's alphabetic, but no, it appears to be creation order.

Change the noodles around and you get:

Now we're getting the material of the referenced object. Again, changing the material index assignment doesn't change anything.

It would be nice if instanced geometry inherited all materials of all instanced objects, as space permitted, so that we could do material assignments, but if that's not possible, choosing materials on the basis of noodle order or creation order is probably not a good way to do it. Creation order is especially poor, since there's no apparent way to change it without starting over from scratch.

Note that the material assignments aren't necessarily getting updated with changes to the geometry nodes, which can confuse some troubleshooting. Sometimes you need to drag some objects around to force recalculation of nodes. It also happens that the geometry nodes show different materials when the node object is in edit vs object mode.

Note that this can also interact with instancing a collection. In this case, the workaround doesn't help (in 2.93.3 release.) It appears that the entire collection gets a set of materials that depends on the order that objects were created, or the order of input noodles in any join geometry nodes, or something else: ![image.png](https://archive.blender.org/developer/F10288001/image.png) Here, it's getting the material of the first created object in the collection, rather than the materials of any other objects. Changing the material index assignment does nothing. I've renamed the first created object to "z" to see if it's alphabetic, but no, it appears to be creation order. Change the noodles around and you get: ![image.png](https://archive.blender.org/developer/F10288003/image.png) Now we're getting the material of the referenced object. Again, changing the material index assignment doesn't change anything. It would be nice if instanced geometry inherited all materials of all instanced objects, as space permitted, so that we could do material assignments, but if that's not possible, choosing materials on the basis of noodle order or creation order is probably not a good way to do it. Creation order is especially poor, since there's no apparent way to change it without starting over from scratch. Note that the material assignments aren't necessarily getting updated with changes to the geometry nodes, which can confuse some troubleshooting. Sometimes you need to drag some objects around to force recalculation of nodes. It also happens that the geometry nodes show different materials when the node object is in edit vs object mode.

Philipp Oeser commented

2021-08-20 09:43:42 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2021-08-20 09:43:42 +02:00

Note that this works in editmode afaics.

Philipp Oeser changed title from ~~Geometry nodes material index attribute not working correctly on generated/instanced geometry~~ to Geometry nodes material index attribute not working correctly on generated/instanced geometry (in objectmode, editmode is fine)

2021-08-20 09:44:02 +02:00

Philipp Oeser commented

2021-08-20 09:45:48 +02:00

Added subscriber: @NahuelBelich

Philipp Oeser commented

2021-08-20 09:52:04 +02:00

In #87335#1208813, @lichtwerk wrote:
Note that this works in editmode afaics.

Correction: this is only true for 2.93 LTS, in 3.0, this does not work in either object or editmode

> In #87335#1208813, @lichtwerk wrote: > Note that this works in editmode afaics. Correction: this is only true for 2.93 LTS, in 3.0, this does not work in either object or editmode

Philipp Oeser commented

2021-08-20 11:17:19 +02:00

FYI, the history on this:
prior to 1a81d268a1 this was working in editmode (but not objectmode)
after 1a81d268a1 no material was shown in the viewport at all
then with 6583fb67c6 we had first material showing again, but setting index was not working in either objectmode nor editmode

FYI, the history on this: prior to 1a81d268a1 this was working in editmode (but not objectmode) after 1a81d268a1 no material was shown in the viewport at all then with 6583fb67c6 we had first material showing again, but setting index was not working in either objectmode nor editmode

Philipp Oeser changed title from ~~Geometry nodes material index attribute not working correctly on generated/instanced geometry (in objectmode, editmode is fine)~~ to Geometry nodes material index attribute not working correctly on generated/instanced geometry

2021-08-20 11:17:45 +02:00

Hans Goudey was assigned by Jacques Lucke

2021-11-22 16:47:09 +01:00

Philipp Oeser commented

2021-12-20 11:33:48 +01:00

@HooglyBoogly : are we still keeping reports for the "legacy" nodes?

Crowe commented

2022-05-08 17:12:59 +02:00

Added subscriber: @crowe

Crowe commented

2022-05-08 17:12:59 +02:00

I'd just like to let you know this bug still happens with the new nodes. Set Material Index doesn't affect generated or instanced geometry, nor does the new Named Attribute node from the builds with "material_index" as the attribute—this one will crash Blender.

My guess is that generated/instanced geometry has a separate list of materials which is out of sync with the object's material slots. It's logic is wild and with more materials it can be hard to keep track of.

Examples:

2 material slots (idx 0-1). Initially the problematic geometry will be only able to be index 0.

Add a Set Material node before the Set Material Index. Set the material to any material not used in this object. Now Set Material Index works correctly for indexes 0 and 1, ignoring what's in Set Material to adhere to the object's material slot list.

4 material slots (idx 0-3)

Set Material to the last material slot.
Repeat with the second last.
Now do like in the other example, setting it to a material not in this object.

As long you don't repeat materials, it works. You can use only materials not in the object, only materials in the object but out of other, or mix them.

Without using Set Material Index to pick the material, you always get the highest index the geometry tree allows. Whether the material it'll be drawn from the object data or the geometry node depends on the number of slots created by geo nodes.

Results...
a) 2 slots x tree with 2 materials not in obj = slot 2 mat
b) 2 slots x 1 material not in obj = slot 1 mat
c) 2 slots x 3 materials not in obj = overwritten by Set Material's mat (idx higher than original slots)

I'd just like to let you know this bug still happens with the new nodes. **Set Material Index** doesn't affect generated or instanced geometry, nor does the new **Named Attribute** node from the builds with "material_index" as the attribute—this one will crash Blender. My guess is that generated/instanced geometry has a separate list of materials which is out of sync with the object's material slots. It's logic is wild and with more materials it can be hard to keep track of. Examples: - > 2 material slots (idx 0-1). Initially the problematic geometry will be only able to be index 0. 1. Add a **Set Material** node before the **Set Material Index**. Set the material to *any* material not used in this object. ***Now Set Material Index works correctly for indexes 0 and 1***, ignoring what's in **Set Material** to adhere to the object's material slot list. ![geonodes_mindex-tree_01.jpg](https://archive.blender.org/developer/F13058577/geonodes_mindex-tree_01.jpg) ![geonodes_mindex_01.jpg](https://archive.blender.org/developer/F13058569/geonodes_mindex_01.jpg) - > 4 material slots (idx 0-3) 1. **Set Material** to the last material slot. 2. Repeat with the second last. 3. Now do like in the other example, setting it to a material not in this object. ![geonodes_mindex-tree_03.jpg](https://archive.blender.org/developer/F13058579/geonodes_mindex-tree_03.jpg) ![geonodes_mindex_03.jpg](https://archive.blender.org/developer/F13058573/geonodes_mindex_03.jpg) As long you don't repeat materials, it works. You can use only materials not in the object, only materials in the object but out of other, or mix them. Without using **Set Material Index** to pick the material, you always get the highest index the geometry tree allows. Whether the material it'll be drawn from the object data or the geometry node depends on the number of slots created by geo nodes. ![geonodes_mindex-tree_02.jpg](https://archive.blender.org/developer/F13058587/geonodes_mindex-tree_02.jpg) Results... a) 2 slots x tree with 2 materials not in obj = slot 2 mat b) 2 slots x 1 material not in obj = slot 1 mat c) 2 slots x 3 materials not in obj = overwritten by Set Material's mat (idx higher than original slots) ![geonodes_mindex_02.jpg](https://archive.blender.org/developer/F13058588/geonodes_mindex_02.jpg)

Dalai Felinto commented

2022-05-09 11:32:26 +02:00

Added subscribers: @Erindale, @PratikPB2123