# Geometry nodes instance grid, with material parameters for specific instances

I'm trying to create a grid of objects, where a parameter for their material depends on their location (for example, increase emission strength of objects along the rim of the grid)

What is the best approach to achieve this? I could not find a way to propagate a property from geo nodes to materials, and also did not find a way to easily select specific instances in the grid...

Any help on how to achieve this will be greatly appreciated!

## Blender 3.0

Using the Scale-to-zero trick by Robin Betts:

Like in Chris'es answer, you need to name the output somehow:

Then use the Attribute node, Fac output:

Keep in mind the attribute is clamped to [0;1] range, hence the Fraction node used. Passing Index and calculating the hue inside the shader wouldn't work in Blender 3.0.

## Explanation

• Amazingly, the setup works even without applying the rerouting marked red on the first screenshot. This is because vertices of the Mesh Line go vertically up, and the offset doesn't touch Z, so the spawning vertex is the closest to to all vertices of the instance (as long as you don't increase the instance size).
• Similarly, the setup works even if you mute the Scale Instances node (as long as you don't increase the instance size).
• For the setup to work in more elaborate cases, you need to reroute the connection as corrected on the first screenshot, otherwise look what happens if you e.g. offset them on Z axis as well:

• To see why Scaling to 0 is important, increase the Scale in Instance on Points to 1.1, and mute the Scale Instances node, then you will see that some vertices produce wrong colors because they are no longer matched to the vertex that spawned the instance - they are so far from the spawn point, that they are now in the "enemy" territory:

As for the need for two Transfer Attribute nodes... You need to read geometry nodes from the right:

• You have the Group Output, receiving some geometry, and an attribute. So it evaluates the geometry, and then the attribute. To evaluate the hue output, it goes left, to the RTA (Right Texture Attribute) node.
• Now RTA's 2nd setting tells it to look for a vertex with the same index as the vertex currently evaluated by the Output node. So it evaluates the geometry passed to it, finds the vertex, and then evaluates the attribute, and so the processing goes left again, to the LTA...
• ...(Left Texture Attribute) node. Again, it evaluates the geometry passed to it, but since it has a different setting, it now doesn't look for a vertex with the same index (which would "work" only for first 42 vertices of the first icosphere, and first 38 vertices for the second icosphere, the 39th vertex would have an index 80, while the Mesh line produced only 80 vertices, indexed 0..79 - of course matching this way wouldn't make sense, you want to match each vertex of an icosphere to a vertex that spawned that icosphere), but instead it looks for the closest vertex. This is why scaling-to-zero works, because it puts all vertices of an instance at the exact same spot as the vertex that spawned that instance, forcing the match.
• This actually worked for me! Can you explain why the second attribute transfer node is needed? I understand everything up to that point Jan 19 at 16:07
• @AlbertPerkins see edit. Jan 19 at 18:35
• Thanks for the detailed clarification! I think I get it now! Jan 19 at 20:17

## Blender 3.1

First, you need to convert your instances into real geometry, because you cannot store different data into the same object data (Instances share the same object data). It is not efficient in calculating and memory, so do it only if you need.

To convert data, you have to use Realize Instances node. It can transfer data from instance to realized geometry only in 3.1 (remove old one and add new one in 3.1 this is why). So you have to get this build at https://builder.blender.org

Here is the simple set up:

You can note that I use Capture Attribute with "Instance" setting to pass a value from instance to realized geometry. In my case it's just random color, you may build your own node setup.

When you send the data to output, you need to store it somewhere. In my case, I use vertex color to save the data. This is the output section of geometry nodes modifier is used for:

Then finally you can use this data in shader using the Attribute node:

If you find that UVMap is broken, use also Attribute node to get the UV, this is a known issue.

• 3.1 crashes when I try to add geometry nodes to a simple plane, so that's not going to cut it for me... Is there a more-stable-ish build that is known to work? I tried the one from yesterday... Jan 19 at 14:24
• I use one from 4 Jan. But yes, builds may be broken, try today's one Jan 19 at 14:36
• Today's build crashes on startup, without a chance to even do something :-( Jan 19 at 15:54
• I managed to get it working on Jan 5th. I ended up accepting the second answer because it actually solved the problem I had at hand, although your answer will definitely age better, given the workaround will no longer be needed in the future... Thanks a lot for your explanation! Jan 19 at 16:18

you can use e.g. this simple node setup:

• I could not reproduce this setup in blender 3.0. Are you using a different build here? Jan 19 at 14:25
• since you didn't tell that your are using 3.0 until now...i couldn't know. I am using 3.1 alpha Jan 19 at 14:31
• what node r u missing? so i can tell you which you could use on 3.0 Jan 19 at 14:32
• All nodes in the photo exist, but the data does not transfer to the end result (I read the above answer by Markus which kind of explains why). Jan 19 at 15:55
• In any case I can't find a working build of 3.1, which probably means what I'm trying to do is currently impossible to achieve with available Blender versions Jan 19 at 15:56