Failure to preserve vertex groups through Geometry Nodes, new to 2.93 #88334

New Issue

Nathan Vasil · 2021-05-17T04:30:42+02:00

Nathan Vasil commented

2021-05-17 04:30:42 +02:00

System Information
Operating system: Windows-10-10.0.18362-SP0 64 Bits
Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.71

Blender Version
Broken: version: 2.93.0 Beta, branch: master, commit date: 2021-05-14 16:16, hash: d4a36c7ad5
Worked: version: 2.92.0, branch: master, commit date: 2021-02-24 16:25, hash: 02948a2cab

Caused by a4baedea91

Short description of error
Vertex groups (even VGs existing on both objects) are not inherited through geometry nodes

Exact steps for others to reproduce the error
Here's a 2.93 beta file:
GNVGbug.blend

It contains three cubes. All three cubes contain a vertex group named "test". On the leftmost cube, labelled "Source", the top four verts are assigned at 1.0 to this vertex group. On the middle cube, labelled "Geo Nodes", no vertices are assigned to this group.

The second cube has a pretty simple geometry nodes modifier, which replaces its geometry with the geometry from Source.

The third cube, labelled "Applied", is just a duplicate of the second cube, with the geometry nodes modifier applied, to make it easier to directly inspect what the geometry node modifier did.

Even though Geo Nodes is copying the geometry from Source, and has a VG with the same name, no verts are assigned to the test vertex group. You can see this by inspecting Applied's vertices.

Expected (and working in 2.92) is for Geo Nodes and Applied to have the same vertex group assignments as Source, at least for vertex groups that are present on both objects.

Possibly, see https://developer.blender.org/rB102eff0bd45e . Conversation on this subject in the bug tracker has been a bit confusing for me, as it's not perfectly clear to what extent VG support from geo nodes is intended vs. serendipitous; that earlier commit, and @HooglyBoogly 's reply, suggest that 2.92's level of support was probably intended.

Edit, possibly interesting: if I change the geometry replacement to a join operation instead, and assign verts in Geo Nodes to the VG, no assignment survives the geometry nodes modifier, either for application of the nodes or for a following modifier (tested a vg-limited displace.)

**System Information** Operating system: Windows-10-10.0.18362-SP0 64 Bits Graphics card: GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.71 **Blender Version** Broken: version: 2.93.0 Beta, branch: master, commit date: 2021-05-14 16:16, hash: `d4a36c7ad5` Worked: version: 2.92.0, branch: master, commit date: 2021-02-24 16:25, hash: `02948a2cab` Caused by a4baedea91 **Short description of error** Vertex groups (even VGs existing on both objects) are not inherited through geometry nodes **Exact steps for others to reproduce the error** Here's a 2.93 beta file: [GNVGbug.blend](https://archive.blender.org/developer/F10114695/GNVGbug.blend) It contains three cubes. All three cubes contain a vertex group named "test". On the leftmost cube, labelled "Source", the top four verts are assigned at 1.0 to this vertex group. On the middle cube, labelled "Geo Nodes", no vertices are assigned to this group. The second cube has a pretty simple geometry nodes modifier, which replaces its geometry with the geometry from Source. The third cube, labelled "Applied", is just a duplicate of the second cube, with the geometry nodes modifier applied, to make it easier to directly inspect what the geometry node modifier did. Even though Geo Nodes is copying the geometry from Source, and has a VG with the same name, no verts are assigned to the test vertex group. You can see this by inspecting Applied's vertices. Expected (and working in 2.92) is for Geo Nodes and Applied to have the same vertex group assignments as Source, at least for vertex groups that are present on both objects. Possibly, see https://developer.blender.org/rB102eff0bd45e . Conversation on this subject in the bug tracker has been a bit confusing for me, as it's not perfectly clear to what extent VG support from geo nodes is intended vs. serendipitous; that earlier commit, and @HooglyBoogly 's reply, suggest that 2.92's level of support was probably intended. Edit, possibly interesting: if I change the geometry replacement to a join operation instead, and assign verts in Geo Nodes to the VG, no assignment survives the geometry nodes modifier, either for application of the nodes or for a following modifier (tested a vg-limited displace.)

Nathan Vasil commented

2021-05-17 04:30:42 +02:00

Added subscribers: @HooglyBoogly, @vasiln

blender-admin commented

2021-05-17 04:30:42 +02:00

#87482 was marked as duplicate of this issue

Philipp Oeser commented

2021-05-18 12:00:52 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2021-05-18 12:00:52 +02:00

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

Philipp Oeser commented

2021-05-18 12:00:52 +02:00

Can confirm.

Caused by a4baedea91

Also not 100% sure about intentions, but seems like an unintentional change.

Can confirm. Caused by a4baedea91 Also not 100% sure about intentions, but seems like an unintentional change.

Hans Goudey commented

2021-05-18 20:03:34 +02:00

First of all, this is a nice bug report. Thanks a lot for taking the time to write a good description of the problem.

Here's what's going on:

The object info node creates an instance as an optimization (rather than copying the cube mesh)
When you apply the modifier, the instance is realized using the same process as if you used an attribute node in the node tree.
Realizing the instance creates a generic float attribute rather than a vertex group, that's just the way geometry nodes works.
Applying the modifier replaces the object's mesh (you would think this would also remove the vertex group too, replacing it with the generic attribute!)
It does not! The list of vertex groups is stored on the object rather than the mesh! Why? I couldn't say!

So IMO this comes down to a backwards legacy implementation decision. I would like to refactor this, but it probably would be an API breaking change.

First of all, this is a nice bug report. Thanks a lot for taking the time to write a good description of the problem. Here's what's going on: 1. The object info node creates an instance as an optimization (rather than copying the cube mesh) 2. When you apply the modifier, the instance is realized using the same process as if you used an attribute node in the node tree. 3. Realizing the instance creates a generic float attribute rather than a vertex group, that's just the way geometry nodes works. 4. Applying the modifier replaces the object's mesh (you would think this would also remove the vertex group too, replacing it with the generic attribute!) 5. It does not! The list of vertex groups is stored on the object rather than the mesh! Why? I couldn't say! So IMO this comes down to a backwards legacy implementation decision. I would like to refactor this, but it probably would be an API breaking change.

Hans Goudey commented

2021-05-18 20:09:05 +02:00

As proof, try removing the vertex group on the "Applied" object and checking the values in the spreadsheet.

Nathan Vasil commented

2021-05-18 21:34:32 +02:00

Thanks for taking a look.

I want to share another file to demonstrate the edit I made to the original report, so it's more clear:

GNVGbug1.blend

In this file, we're now joining Source and GeoNodes via geometry nodes, and GeoNodes has some vertices assigned to "test", as well as a vg-limited displace so we can see whether those VGs survive. It's clear that the presence of the geometry nodes modifier is voiding the vertex group. Even though the GN nodes mesh now forms part of the output, via a join operation, that join operation seems to destroy any vertex group assignments from the original GeoNodes mesh.

Thanks for taking a look. I want to share another file to demonstrate the edit I made to the original report, so it's more clear: [GNVGbug1.blend](https://archive.blender.org/developer/F10123960/GNVGbug1.blend) In this file, we're now joining Source and GeoNodes via geometry nodes, and GeoNodes has some vertices assigned to "test", as well as a vg-limited displace so we can see whether those VGs survive. It's clear that the presence of the geometry nodes modifier is voiding the vertex group. Even though the GN nodes mesh now forms part of the output, via a join operation, that join operation seems to destroy any vertex group assignments from the original GeoNodes mesh.

Hans Goudey commented

2021-05-21 22:23:47 +02:00

Thanks for the example again. As I said above, the join node doesn't destroy vertex groups, the output is just a regular attribute rather than a vertex group. When you have a vertex group and an attribute of the same name on a mesh, the vertex group takes priority, even if it has no values.

This didn't appear in 2.92 since the object info node didn't generate instances, geometry nodes was very different back then.

I'm going to classify this as a known issue for now, since it just comes down to the fact that vertex group names are stored on the object.

Thanks for the example again. As I said above, the join node doesn't destroy vertex groups, the output is just a regular attribute rather than a vertex group. When you have a vertex group and an attribute of the same name on a mesh, the vertex group takes priority, even if it has no values. This didn't appear in 2.92 since the object info node didn't generate instances, geometry nodes was very different back then. I'm going to classify this as a known issue for now, since it just comes down to the fact that vertex group names are stored on the object.

Nathan Vasil commented

2021-05-22 06:57:09 +02:00

That's a shame :( Hopefully we can eventually get some kind of attribute->VG node in that case, or a data transfer node to reconstruct VGs (in conjunction with strange transforms and anti-transforms to copy on the basis of nearest). Again, thanks for taking a look, I appreciate all the work on GN.