After helping someone, I was just playing around with Geometry Nodes in 3.0, and was trying to set each instanced mesh to it’s own material using the “set material index” node. But it doesn’t seem to work or maybe it’s just not intuitive to me. Even without using the index input and just adjusting the numerical value, it doesn’t do anything, even though I have 4 materials and 4 material slots. I would expect each of the icospheres to be a different color based on material 0, 1, 2, and 3. Is this possible? What am I missing?
I don’t think this is the proper way to do it, but it appears to work. Maybe someone with more knowledge will show how to do it with primitives.
Ah I see thanks. But then a different material is applied to each face of an instance, not to the whole instance itself. Is there a way to change it so that setting the material affects the whole instance?
If you look at the file, you should see that the object that is instantiated is the one with the multiple material slots.
Yes I get that, but if you look at the screenshot below, if I try to set the material using the index input and modulo, it doesn’t change every other instance, it changes every other face.
If you are only using one mesh type for your instances (i.e. they all have the same number of faces), you can use the approach here to get a different, single, material per instance:
I was just struggling with this and didn’t find any good answer on the web. I think I figured out one/the “correct” way to do it. (Tested on 3.1 but should work on 3.0).
The issue is that “geometry” after instancing has been done is indeed a set of faces. It doesn’t seem possible to assign materials directly to whole instances at that point.
The solution seemed to be to split the instances into groups by ID. (Example is two groups selected at random.) Each instance geometry group can have a separate material assigned.
Example node tree is:
A few comments on my own reply. I’m pretty sure of the below, but haven’t tested exhaustively.
- Basically, the “Set Material [Index]” nodes always operate on each FACE in the input Geometry. So if they take values from Index/ID, they get the set of FACE indexes/IDs. The Index/ID “inputs” are overloaded.
- I think it would be more correct, and safer, in my example to use Index rather than ID to separate the odds/evens. Index is guaranteed to be 0…N. You can’t necessarily count on the values of ID (could all be even, although they aren’t). If the actual values are used in computations, you would surely need Index.
I’m still pretty new at Geometry Nodes. But as a retired programmer, I think I’m beginning to understand how they work.
I had the same problem, and with the help of the genius mind of Bradley Animations (check out his YouTube vids) I managed to fumble my way to a solution. I’ll paste it here so other people might find it useful.
I’ve been researching about this for a couple days now and always end up at this same example you posted, but what if you still want to benefit of the instances in terms of memory? If you realize instances at the end you end up again with a bunch of unnecessary polys when, for example, in my case, I just wanted to see a bunch of different colorways. I’m trying to figure out if geometry nodes is a good solution for experimenting with different CMFs in product design and still don’t see a clear answer to this.