I'm trying to apply instanced trees on the mesh, the UV disappears after realizing instances, i'm trying to import that applied mesh to unreal but the loss of UV after instance realization is quite frustrating, if not impossible to work with.

I wonder if this will be fixed soon.. It's a pretty big letdown for a project I'm working on which involves dynamically showing parts of a mesh (and procedurally merging verts by distance to avoid SSS seams)..

Because of this bug I ended up having to duplicate a lot of meshes :(

I don't even understand why is this a problem.
I am on the lastest 3.2 alpha so maybe there was something added that was not present before but if your goal is to export to a game engine you either want to have multiple instances of the same object wich you would make instance real or you would want everything to be joined on one mesh and you would use realize instance.
In the case of make instance real the UV are already there and in the case of realize instance you just have to go to the attributes of the object and convert them to an UVmap and it's done.

If anyone can tell me if i didn't understand the root of the problem it would be appreciated.

In T85962#1326032, @warcanin (warcanin) wrote:

I don't even understand why is this a problem.
I am on the lastest 3.2 alpha so maybe there was something added that was not present before but if your goal is to export to a game engine you either want to have multiple instances of the same object wich you would make instance real or you would want everything to be joined on one mesh and you would use realize instance.
In the case of make instance real the UV are already there and in the case of realize instance you just have to go to the attributes of the object and convert them to an UVmap and it's done.

If anyone can tell me if i didn't understand the root of the problem it would be appreciated.

The issue is that it makes it more difficult to preview your data, its a lot of button presses just to see what you are doing with the data your are manipulating

https://developer.blender.org/D14389

looks like a UV system may be in the works

In T85962#1326032, @warcanin (warcanin) wrote:

I don't even understand why is this a problem.

While the workarounds will do the job in most cases, they are still only workarounds to something which should be handled automatically in my opinion. The need of handling this manually makes the workflow sluggish and prone to errors.
A modifier which produces different results after hitting apply can be (in my opinion) considered as bug, same with loosing preview of the work by including Realize Instances - this is just not the expected behavior. You can't expect users to have idea about attributes, why their data are converted etc., they will just see their work broken without clear reason.
Also in some cases none of the mentioned workarounds help - for example if you want to use Realize Instances while working with GNodes (i.e. to improve the viewport performance when working with large amount of instances) and you need legacy data to be prevented for whatever reason (i.e. for a 3rd party addons compatibility, like custom shaders which don't support attributes).

In T85962#1326032, @warcanin (warcanin) wrote:

In the case of make instance real the UV are already there and in the case of realize instance you just have to go to the attributes of the object and convert them to an UVmap and it's done.

I remember trying to transfer/set UV maps after realizing instances and it did literally nothing. And it was on 3.2 as well.

TBH, the custom operator is a little too complicated for a dummy like me.

In T85962#1326042, @Jan Kadeřábek (jendabek) wrote:

In T85962#1326032, @warcanin (warcanin) wrote:

I don't even understand why is this a problem.

While the workarounds will do the job in most cases, they are still only workarounds to something which should be handled automatically in my opinion. The need of handling this manually makes the workflow sluggish and prone to errors.
A modifier which produces different results after hitting apply can be (in my opinion) considered as bug, same with loosing preview of the work by including Realize Instances - this is just not the expected behavior. You can't expect users to have idea about attributes, why their data are converted etc., they will just see their work broken without clear reason.
Also in some cases none of the mentioned workarounds help - for example if you want to use Realize Instances while working with GNodes (i.e. to improve the viewport performance when working with large amount of instances) and you need legacy data to be prevented for whatever reason (i.e. for a 3rd party addons compatibility, like custom shaders which don't support attributes).

I think these are totally legit concerns you mention re: 3rd party plugins, etc. From a professional game artist point of view though, UV Maps are just *SUCH* an incredibly basic, fundamental, and necessary feature; to hear any argument attempting to rationalize why they aren't included, or the feature's development can be kicked down the road, can feel pretty frustrating or dismissive. 99% of assets in gameart rely on UVs. Procedural shader effects in AAA production gameart are almost 100% secondary, and only exist to complement the work done on top of the authored texture & UV maps.

All that said, this is still a really complex, awesome piece of software, and I appreciate the work folks are putting in to develop this feature. Still really looking forward to this being realized.

In T85962#1326040, @Jacob Merrill (blueprintrandom) wrote:

https://developer.blender.org/D14389

looks like a UV system may be in the works

hype! I love it

can't wait to see a solution for this!

This is very critical imo. As a 3d artist working in games I got really excited to learn geometry nodes but quickly learned that UVS disappear after realizing instances, which completely ruins geometry nodes for use in games.

I just ran my tests again in 3.3.0 and it's definitely still not fixed. That's honestly pretty disappointing.

In T85962#1351369, @Henrique Corrêa (HeCorr) wrote:

I just ran my tests again in 3.3.0 and it's definitely still not fixed. That's honestly pretty disappointing.

Hi, look up in the title: it says Confirmed, Normal.
There are many tasks to be solved by developers and with High priority:
Open task

It also says KNOWN ISSUE, so yeah it ain't solved. A simple Join Geometry with two meshes kills the UV, or realizing scattered instances. Seems like a hard issue to fix since it have been over a year now since I first reported the Join Geometry bug. Lets hope they find a solution soon since I regularly stumble upon this :\ :)

Many people have misunderstanding of the issue status imo.

1. If you are working in Blender. This isn't an issue for most of cases, you can use "Attribute" node in shader to load UV attribute instead of "Texture Coordinate"'s UV.
2. If you are exporting your object, you have to apply the modifier and use attribute converter.

People complain that applying the modifier will lose the proceduralism. However you can always duplicate your object as a backup. If you want to edit anything, you can come back to your node tree, change parameters, apply modifier and use attribute converter again.
This method definitely seems more of a temporary workaround and have some downside, but it also solves lots of problems in the mean time.
so at least this problem isn't as unsolvable as most people think. It's not like a crash bug that you can't do anything with it.

In T85962#1352197, @Gerstmann Bradley (Bradley_G) wrote:

1. If you are working in Blender. This isn't an issue for most of cases, you can use "Attribute" node in shader to load UV attribute instead of "Texture Coordinate"'s UV.

I just tested it and it does not work. same behavior.

In T85962#1352201, @Henrique Corrêa (HeCorr) wrote:

In T85962#1352197, @Gerstmann Bradley (Bradley_G) wrote:

1. If you are working in Blender. This isn't an issue for most of cases, you can use "Attribute" node in shader to load UV attribute instead of "Texture Coordinate"'s UV.

I just tested it and it does not work. same behavior.

Make sure you are using the correct UV attribute that you can find in the face corner domain. Either "UVMap" or "uv_map".
There are tutorials on youtube/google talking about it. I can assure you this will work if you've done things correctly.

Okay, it does seem to work on a simpler scene but I'm still having difficulties getting it to work on my actual project.. but this is a big step already.

@Gerstmann Bradley (Bradley_G) thank you so much

edit: I figured it out. the imported models had "UV0" as the UV maps instead of "UVMap".

Found this issue. UVs disappear after GN. {F13115075}Blend file is attached.

Hi everyone,

I have the same kind of problem with "Realize Instances", when I want to join my instances and then "Merge by Distance" and "Subdivision Surface".

I tried the solution of adding the attribute to the material and it does not work properly. The UVs are still missing from the new object, even if some kind of display appears.
The main problem is that even if the texture appears in the right place, it is not affected correctly by the subdivision.

When the GeometryNodes modifier is applied, the UVs are lost. The only solution I have found is to resign myself to not merging or subdividing in the GeometryNodes, but to perform these operations on the object after applying the modifier.
But it's a bit frustrating because I have the impression that the result I could get dynamically is very close...

Is Blender team working on that ?

Thank you !

In T85962#1365670, @paul geraskin (mifth) wrote:

Found this issue. UVs disappear after GN. {F13115075}Blend file is attached.

After you apply Geometry nodes, an attribute called UVMap appears in (new) Attributes panel

I guess it's how it works now.

In T85962#1375353, @Jaromir (xaras0) wrote:

After you apply Geometry nodes, an attribute called UVMap appears in (new) Attributes panel
After that, you have to convert that attribute by clicking an arrow and "Convert Attribute". Then choose mode as UV Map.
After this UVMap will be created and attribute will disappear (conversion).
And UVs are back again.

I guess it's how it works now.

Thank you for your intervention.

I made these operations and I recovered my UVs, but they are still not affected by the subdivision as the "Subdivision surface" is used in the GeometryNodes.

In T85962#1326040, @Jacob Merrill (blueprintrandom) wrote:

https://developer.blender.org/D14389

looks like a UV system may be in the works

This is of course helpful, but no improvement if you have to keep the original UVs of the joined meshes.

This is still an issue preventing swaths of people adopting geometry nodes as part of really amazing setups

Would love love love to see a built-in solution in the near-term (it has been 17 months since it was initially pointed out and later confirmed as a known issue)

In T85962#1386501, @Leah (llealloo) wrote:

This is still an issue preventing swaths of people adopting geometry nodes as part of really amazing setups

Absolutely agree. This should be at the top of the pile to make it into 3.3 LTS. Lack of UV support is a big hole in the workflow.

As others have said, I really appreciate all of the development going into Geometry Nodes. Non-destructive and procedural creation has been key to my adoption of Blender as a toolset. The limitations haven't stopped me from using it on some rendered projects.

But UV maps are absolutely required for any sort of realtime engine experience. I can build some pretty helpful mesh generators in Geometry Nodes, but they're unusable in Unity/Unreal because attributes ≠ UV maps, and manual/destructive workarounds are not a viable production solution.

I'm really hoping this can be solved before 3.3? Without usable UV map data, assets created with Geometry Nodes are functionally useless outside of Blender.

Here's a bit of an update. There are a few things needed to fix this problem:

• Support generic attributes as UVs in Blender's renderers.
  • This is in progress in D15101, done for Cycles but still needs work in EEVEE. Some work it depends on is happening in D15205.
• Update everywhere in Blender to use generic 2D vectors as UV maps.
  • This is in progress in D14365. It's a massive task.
  • Luckily @Martijn Versteegh (Baardaap) has been working on this for months, and it's getting close. But it's still a big refactor and needs proper review.

Those two things fix the problem in the majority of cases (join geometry, realize instances, etc.), including for exporters, the UV editor, and rendering.
I can't say that these will land in 3.3. Probably not, at least for the second task. I'm confident they can make it in 3.4 though.

That leaves the 2D/3D vector issue, since geometry nodes cannot currently output 2D vectors.
Without some solution to that, UVs created from scratch by geometry nodes wouldn't be seen by exporters as UVs.

• Personally I would like to add 2D vector sockets to geometry nodes (T92765)
• Another option is adding some conversion in the store named attribute node like D14705.

In T85962#1387361, @Hans Goudey (HooglyBoogly) wrote:

Here's a bit of an update. There are a few things needed to fix this problem:

• Support generic attributes as UVs in Blender's renderers.
  • This is in progress in D15101, done for Cycles but still needs work in EEVEE. Some work it depends on is happening in D15205.
• Update everywhere in Blender to use generic 2D vectors as UV maps.
  • This is in progress in D14365. It's a massive task.
  • Luckily @Martijn Versteegh (Baardaap) has been working on this for months, and it's getting close. But it's still a big refactor and needs proper review.

Those two things fix the problem in the majority of cases (join geometry, realize instances, etc.), including for exporters, the UV editor, and rendering.
I can't say that these will land in 3.3. Probably not, at least for the second task. I'm confident they can make it in 3.4 though.

That leaves the 2D/3D vector issue, since geometry nodes cannot currently output 2D vectors.
Without some solution to that, UVs created from scratch by geometry nodes wouldn't be seen by exporters as UVs.

• Personally I would like to add 2D vector sockets to geometry nodes (T92765)
• Another option is adding some conversion in the store named attribute node like D14705.

thanks hans. we really appreciate all the folks putting in the time to add this functionality.