"Realize Instances" node removes part of the image texture

I’m using Blender 3.0 and I’m trying to understand geometry nodes. That’s why I followed a few tutorials from the internet.
Now I stumbled upon a strange behavior. It looks like a program error to me, but I’m not sure. Maybe you can tell me, if it’s an error in the program or if I did something wrong, and when I did, how I can fix this “error”.

I have an object, in the shader editor I put an image texture on the object. The image is just a red square with the text “Test” written on it. The object is metallic and reflective that’s why it’s looking kind of smudged.

In the geometry nodes editor I “Distribute Points on Faces” and after that I “Instance on Points” and I use a simple UV sphere as instance. This works and it’s looking like this:

So far so good. Now I’d like to distort each separate UV sphere, that’s why I use the “Realize Instances” node. But as soon as I plug in this node, the text of my image texture disappears, but the back color survives.

Why does only the text of my image texture disappear? And where does it go? How can I get it back?

Thank you.

Pictures are great,

but even better would be yr node setup, might help?

Shader Editor:

Geometry Nodes Editor:

Image Texture:
Image Texture

No luck here with UV, but generated or object work, also you may want to select tube for mapping type in image material node.

Im using B 3.2

So, is it a bug, that it’s not working with UV? If the object isn’t a simple cylinder than switching to generated or object coordinates might not work?

Somethings up, I got it to work like this though, you have to put the geonode on a plane (just as a container) Then use object info and bring in the cylinder.

Good job I dont sleep much hey?

The realize instances node does tend to obliterate the UV maps, a way to get around this is to use an input attribute node with the UVMap as the attribute in the shader editor, like this:

It is strange that you can not use the texture coordinate nodes UV output or a UVMap input node for this (neither will work). It seems that GN nodes need you to specify the UVMap as an attribute in the shader editor.
Note I did not do anything in the GN node setup, the only change is the attribute node in the shader editor.

Edit: This also works for UVMapped instances.

Ah, thanks for the clarification, I hadnt thought of that method at all.

I wonder if that will change or, thats just the way it is?

I have no idea but I suspect that things will get more integrated, I think I read somewhere that they were working on this.
For the moment the “attribute node” is like a wormhole between GNnode setups and shader setups


While it’s not ideal that realizing the instances is affecting the UV of the base object, your process is flawed.
Instead of creating the instances in a node tree on the can, create a new object for the geometry nodes tree and reference the can object as an input. It keeps objects separate in the scene hierarchy and you can reuse the condensation generator wherever you want.

Exactly what I showed in post 3.

No. I see no node tree inputs in any of what you’ve posted.

Im sure this is what yr talking about, Just because I havent wired it into a group input doesnt mean its invalid.

If not, why not post yr solution??

You’re sure that’s what I’m talking about despite me saying it’s not? You seem be taking offense at my suggestion that there’s a more robust solution than what you’ve posted.
The limitation with what you’ve posted is that the geometry reference is internal, not a tree input, so anytime you reuse the node setup you have to create a full copy of it and then open it up to change the source. Also there’s no reason to fully merge the can, just use the tree to create the condensation and keep the original can object for rendering.

No, no offense, Ive shown 3 solutions to Op’s question.

And I understand what you are saying, but I wasnt bearing reuse in mind, I was assuming the user was going to build whatever around this, a re usable group or not.

So, for clarity for @Nostromo , @init_pixel is suggesting this setup.

Yes, exactly that. I wouldn’t realize the instances but to each their own.
Even outside of reuse I think it’s important to demonstrate and follow good practices of exposing important parameters. Particularly so given how new geometry nodes, and the fields changes, are.

Sorry, it’s seems a trend that people get very defensive at even the slightest of disagreement or question :slight_smile:

1 Like

Thank you all for your answers and suggestions. Without knowing your suggestions I doubled the base object and put the geo nodes on this copied object. It’s probably not pretty but it did the job.
I’ll have a look into your suggestions though and try to use them in my scenario.

Although @init_pixel initially came up with what I’m going to flag as solution, I couldn’t understand what he suggested with words. So I flag @AlphaChannel’s message with the picture of what @init_pixel suggested as solution.