Geometry Nodes: writing attributes (from procedurally created geometry) to vertex groups not working #99197

New Issue

Joey D · 2022-06-27T08:45:37+02:00

Joey D commented

2022-06-27 08:45:37 +02:00

System Information
Operating system: macOS Monterey 12.4
Graphics card: RX 6800 XT

Blender Version
Broken: 3.1 & newer
Worked: 3.0.1

Short description of error

In Blender 3.0.1, it was possible to write attributes from procedurally created geometry (created by geometry nodes) to vertex groups, as long as the "Group Input" node was joined with the procedural geometry. However, no version newer than 3.0.1 seems to have this capability. From what I understand, this may have been done intentionally in anticipation of attributes replacing vertex groups entirely... but it seems odd to kill this feature before that transition is complete, so I'm reporting this as a bug.

Exact steps for others to reproduce the error

Open the attached .blend file in Blender 3.0.1:
geonodes_attrib_to_vgroup.blend
This file contains a geonodes setup where half of a procedurally generated grid is extruded using a solidify modifier. The "geonodes" object should look exactly the same as the "Expected Result" object.

Next, open the file in Blender 3.3 (or 3.1, or 3.2) and notice how the "Expected Result" object no longer matches the "geonodes" object.

**System Information** Operating system: macOS Monterey 12.4 Graphics card: RX 6800 XT **Blender Version** Broken: 3.1 & newer Worked: 3.0.1 **Short description of error** In Blender 3.0.1, it was possible to write attributes from procedurally created geometry (created by geometry nodes) to vertex groups, as long as the "Group Input" node was joined with the procedural geometry. However, no version newer than 3.0.1 seems to have this capability. From what I understand, this may have been done intentionally in anticipation of attributes replacing vertex groups entirely... but it seems odd to kill this feature before that transition is complete, so I'm reporting this as a bug. **Exact steps for others to reproduce the error** Open the attached .blend file in Blender 3.0.1: [geonodes_attrib_to_vgroup.blend](https://archive.blender.org/developer/F13232031/geonodes_attrib_to_vgroup.blend) This file contains a geonodes setup where half of a procedurally generated grid is extruded using a solidify modifier. The "geonodes" object should look exactly the same as the "Expected Result" object. Next, open the file in Blender 3.3 (or 3.1, or 3.2) and notice how the "Expected Result" object no longer matches the "geonodes" object.

👍 1 ❤️ 1

Joey D commented

2022-06-27 08:45:37 +02:00

Added subscriber: @JoeyDeutsch

blender-admin commented

2022-06-27 08:45:37 +02:00

#102516 was marked as duplicate of this issue

blender-admin commented

2022-06-27 08:45:37 +02:00

#100921 was marked as duplicate of this issue

blender-admin commented

2022-06-27 08:45:37 +02:00

#101427 was marked as duplicate of this issue

blender-admin commented

2022-06-27 08:45:37 +02:00

#100948 was marked as duplicate of this issue

blender-admin commented

2022-06-27 08:45:37 +02:00

#100908 was marked as duplicate of this issue

Iliya Katushenock commented

2022-06-27 10:38:28 +02:00

Added subscriber: @mod_moder

Iliya Katushenock commented

2022-06-27 10:38:28 +02:00

But you have a different problem. You cannot enter a field in a modifier. Use an extrude node. The idea is to work completely only in nodes

Joey D commented

2022-06-27 18:27:56 +02:00

I understand that, but I feel that it's a bit shortsighted to remove the ability to write attributes (specifically point float attributes) to vertex groups before that transition is complete. The solidify modifier was just an example I picked to easily & quickly illustrate my point - where I really miss that feature is when I want to create an entirely procedural "pinned" vertex group for a cloth simulation, for example. Sorry for the confusion haha. Take a look at this file:
geonodes_attrib_to_vgroup_cloth.blend
Open this file in 3.0.1, & click play on the timeline. You'll see that the right half of the grid is pinned appropriately. In 3.1+, the cloth simulator just makes the entire object fall, since the pinned group doesn't work anymore.

If this exact feature won't be re-implemented, do you know when the transition away from vertex groups on these modifiers will be complete? I couldn't find any sort of roadmap for that.

I understand that, but I feel that it's a bit shortsighted to remove the ability to write attributes (specifically point float attributes) to vertex groups before that transition is complete. The solidify modifier was just an example I picked to easily & quickly illustrate my point - where I really miss that feature is when I want to create an entirely procedural "pinned" vertex group for a cloth simulation, for example. Sorry for the confusion haha. Take a look at this file: [geonodes_attrib_to_vgroup_cloth.blend](https://archive.blender.org/developer/F13232876/geonodes_attrib_to_vgroup_cloth.blend) Open this file in 3.0.1, & click play on the timeline. You'll see that the right half of the grid is pinned appropriately. In 3.1+, the cloth simulator just makes the entire object fall, since the pinned group doesn't work anymore. If this exact feature won't be re-implemented, do you know when the transition away from vertex groups on these modifiers will be complete? I couldn't find any sort of roadmap for that.

Hans Goudey commented

2022-06-27 18:32:17 +02:00

Added subscriber: @HooglyBoogly

Hans Goudey commented

2022-06-27 18:32:17 +02:00

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

Hans Goudey commented

2022-06-27 18:32:17 +02:00

This situation doesn't work because the join node internally just makes a new mesh, it doesn't copy the custom data format from the input meshes. And since geometry nodes doesn't create vertex groups, the result is a generic attribute.

In general, modifiers won't be updated to support attributes. Instead, nodes will be added to make the same features available inside of geometry nodes. You can track that progress here: #86839
Many nodes won't correspond exactly to modifiers though, they're often more focused, more like building blocks.

This situation doesn't work because the join node internally just makes a new mesh, it doesn't copy the custom data format from the input meshes. And since geometry nodes doesn't *create* vertex groups, the result is a generic attribute. In general, modifiers won't be updated to support attributes. Instead, nodes will be added to make the same features available inside of geometry nodes. You can track that progress here: #86839 Many nodes won't correspond exactly to modifiers though, they're often more focused, more like building blocks.

Joey D commented

2022-06-27 20:31:51 +02:00

Gotcha. Well I'm very excited for the node takeover!

Hans Goudey commented

2022-09-08 16:01:13 +02:00

Added subscribers: @austineberhart, @JacquesLucke, @SteffenD, @PratikPB2123

Hans Goudey commented

2022-09-09 17:59:53 +02:00

Added subscriber: @Carl-Olsen

Carl Olsen commented

2022-09-09 18:04:54 +02:00

I created this: https://developer.blender.org/T100948 and it was marked as a duplicate. I'm not sure it is an exact duplicate but it does seem to be related. My case only deals with vertex groups not attributes.

My case still works in 3.2.1 but not 3.3.0

I used this all the time for solidify modifiers. Hoping for a fix/workaround

I created this: https://developer.blender.org/T100948 and it was marked as a duplicate. I'm not sure it is an exact duplicate but it does seem to be related. My case only deals with vertex groups not attributes. My case still works in 3.2.1 but not 3.3.0 I used this all the time for solidify modifiers. Hoping for a fix/workaround

R. C. Randolph commented

2022-09-16 00:45:50 +02:00

Added subscriber: @rcrandolph

R. C. Randolph commented

2022-09-16 00:45:50 +02:00

Hey Carl Olsen, I agree using vertex groups with joined geo node geometry is extremely useful. The hacky, buggy, awful work around I've found is to download the source code for Blender, remove the line of code added at https://developer.blender.org/rB5d67b524412d0dab936170eef65c508930ba4c30 "BLI_freelistN(&dst_mesh->vertex_group_names)", and then build a custom version of Blender with this code change. It looks like the update was added to remove crashes when attributes and vertex groups have the same name, which is reasonable. However, the power of being able to combine geometry nodes, vertex groups, and other modifiers is so powerful that I'm willing to manually avoid double naming anything. The crash comes up when, for example, you have a vertex group and color attribute with the same name. Just make sure not to do this and it appears to work great.

Devs, is it possible to, when naming conflicts occur, just disable the join node with a warning? I noticed that there's already a warning system under color attributes when there's vertex groups and colors with the same name, "Warning: Name Collision: group_name" Maybe the join node can be automatically disabled and the same "Name Collision: group_name" warning can come up on the join node when this occurs? It's a pretty easy problem for the user to avoid once the principle is understood, and being able to use vertex groups still is huge. It allows one to use vertex groups with lattices, beveling, advanced solidify modifier options, all kinds of stuff.

I look forward to the day that geometry nodes can fully replicate the other modifiers, but until then, a work around like this would extend Blender capabilities immensely.

Hey Carl Olsen, I agree using vertex groups with joined geo node geometry is extremely useful. The hacky, buggy, awful work around I've found is to download the source code for Blender, remove the line of code added at https://developer.blender.org/rB5d67b524412d0dab936170eef65c508930ba4c30 "BLI_freelistN(&dst_mesh->vertex_group_names)", and then build a custom version of Blender with this code change. It looks like the update was added to remove crashes when attributes and vertex groups have the same name, which is reasonable. However, the power of being able to combine geometry nodes, vertex groups, and other modifiers is so powerful that I'm willing to manually avoid double naming anything. The crash comes up when, for example, you have a vertex group and color attribute with the same name. Just make sure not to do this and it appears to work great. Devs, is it possible to, when naming conflicts occur, just disable the join node with a warning? I noticed that there's already a warning system under color attributes when there's vertex groups and colors with the same name, "Warning: Name Collision: group_name" Maybe the join node can be automatically disabled and the same "Name Collision: group_name" warning can come up on the join node when this occurs? It's a pretty easy problem for the user to avoid once the principle is understood, and being able to use vertex groups still is huge. It allows one to use vertex groups with lattices, beveling, advanced solidify modifier options, all kinds of stuff. I look forward to the day that geometry nodes can fully replicate the other modifiers, but until then, a work around like this would extend Blender capabilities immensely.

Hans Goudey commented

2022-09-18 04:24:14 +02:00

I'm actually surprised that change makes it work at all for you. The join geometry node and realize instances node don't create vertex group data at all, so it's not just about name collisions. The issue is that the vertex group storage system just doesn't work at all with the way attributes or geometry nodes are designed.

R. C. Randolph commented

2022-09-19 17:51:50 +02:00

I mean, I'm surprised too. I don't really understand the complexities deep in the code, but my thought process was basically this:

Geometry Nodes + Vertex Groups worked in Blender 3.2
Geometry Nodes + Vertex Groups still works in Blender 3.3+, except when a Join Geometry node is used
The new Join Geometry node behavior is consistent with vertex groups being removed after the Join Geometry node
Pratik Borhade did a regression analysis at #100908 that indicated the new Join Geometry node behavior started at the branch 5d67b52441
5d67b52441 adds two lines of code, one of which appears to remove vertex groups
5d67b52441 was made as a fix for #100562, which discovered that the Join Geometry node would cause a crash if a vertex group and color attribute had the same name
Removing the line of code that appears to delete vertex groups from Blender 3.3+ restores the old behavior, including the name collision crash
Removing this line of code, while hacky, appears to be a work around allowing Join Geometry and Vertex Groups to be used on the same object

I'm posting in this thread as the ones that seemed more related to the problem I'm having got closed and merged into this one, but they might be separate issues. I'm not trying to create Vertex Groups inside geometry nodes, I'm just wanting to be able to use existing Vertex Groups after using a Join Geometry node. #100908 has a .blend file that demonstrates the issue, but I'll include another one to make it more clear.
join_geometry_version_bug.blend
In the included file, the Vertex Groups are empty by default, and I am editing their weights after a Join Geometry node using the Data Transfer modifier. In 3.2 this works great, and even allows me to add Vertex Group data to a cube generated with the add cube node (listed as a viable work around at #92948.) In Blender 3.3+ this type of functionality is no longer possible. The Data Transfer modifier no longer can edit Vertex Group weights, and it and subsequent modifiers behave as though the Vertex Groups are deleted entirely after a Join Geometry node. I'd much rather use Geometry Nodes for everything than use Vertex Groups and subsequent modifiers, but my current project requires lattices and I fear lattices are not a high priority for Geometry Node integration. Love the work you're all doing, just trying to use it all as soon as possible.

I mean, I'm surprised too. I don't really understand the complexities deep in the code, but my thought process was basically this: - Geometry Nodes + Vertex Groups worked in Blender 3.2 - Geometry Nodes + Vertex Groups still works in Blender 3.3+, except when a Join Geometry node is used - The new Join Geometry node behavior is consistent with vertex groups being removed after the Join Geometry node - Pratik Borhade did a regression analysis at #100908 that indicated the new Join Geometry node behavior started at the branch 5d67b524412d - 5d67b524412d adds two lines of code, one of which appears to remove vertex groups - 5d67b524412d was made as a fix for #100562, which discovered that the Join Geometry node would cause a crash if a vertex group and color attribute had the same name - Removing the line of code that appears to delete vertex groups from Blender 3.3+ restores the old behavior, including the name collision crash - Removing this line of code, while hacky, appears to be a work around allowing Join Geometry and Vertex Groups to be used on the same object I'm posting in this thread as the ones that seemed more related to the problem I'm having got closed and merged into this one, but they might be separate issues. I'm not trying to create Vertex Groups inside geometry nodes, I'm just wanting to be able to use existing Vertex Groups after using a Join Geometry node. #100908 has a .blend file that demonstrates the issue, but I'll include another one to make it more clear. [join_geometry_version_bug.blend](https://archive.blender.org/developer/F13516399/join_geometry_version_bug.blend) In the included file, the Vertex Groups are empty by default, and I am editing their weights after a Join Geometry node using the Data Transfer modifier. In 3.2 this works great, and even allows me to add Vertex Group data to a cube generated with the add cube node (listed as a viable work around at #92948.) In Blender 3.3+ this type of functionality is no longer possible. The Data Transfer modifier no longer can edit Vertex Group weights, and it and subsequent modifiers behave as though the Vertex Groups are deleted entirely after a Join Geometry node. I'd much rather use Geometry Nodes for everything than use Vertex Groups and subsequent modifiers, but my current project requires lattices and I fear lattices are not a high priority for Geometry Node integration. Love the work you're all doing, just trying to use it all as soon as possible.

Carl Olsen commented

2022-09-22 17:18:40 +02:00

If you do a boolean operation on a mesh vertex group data is kept intact. It would make sense for join geometry to do the same I think. There must be a better way to handle attribute name collisions than this.

Hans Goudey commented

2022-09-28 16:36:28 +02:00

Added subscribers: @nacioss, @persun, @OmarEmaraDev

Germano Cavalcante commented

2022-09-29 19:51:45 +02:00

Added subscribers: @BlenderAmateur, @mano-wii

Gary Ritchie commented

2022-09-30 16:46:21 +02:00

Added subscriber: @GaryRitchie

Serge Lyatin commented

2022-10-03 22:26:59 +02:00

Added subscriber: @SergeL

Iliya Katushenock commented

2022-11-15 08:26:33 +01:00

Added subscriber: @shadow_creeper

Mike commented

2022-12-26 19:25:32 +01:00

Added subscriber: @MMMM

Mike commented

2022-12-26 19:25:32 +01:00

In #99197#1417901, @rcrandolph wrote:
Hey Carl Olsen, I agree using vertex groups with joined geo node geometry is extremely useful. The hacky, buggy, awful work around I've found is to download the source code for Blender, remove the line of code added at https://developer.blender.org/rB5d67b524412d0dab936170eef65c508930ba4c30 "BLI_freelistN(&dst_mesh->vertex_group_names)", and then build a custom version of Blender with this code change. It looks like the update was added to remove crashes when attributes and vertex groups have the same name, which is reasonable. However, the power of being able to combine geometry nodes, vertex groups, and other modifiers is so powerful that I'm willing to manually avoid double naming anything. The crash comes up when, for example, you have a vertex group and color attribute with the same name. Just make sure not to do this and it appears to work great.

Devs, is it possible to, when naming conflicts occur, just disable the join node with a warning? I noticed that there's already a warning system under color attributes when there's vertex groups and colors with the same name, "Warning: Name Collision: group_name" Maybe the join node can be automatically disabled and the same "Name Collision: group_name" warning can come up on the join node when this occurs? It's a pretty easy problem for the user to avoid once the principle is understood, and being able to use vertex groups still is huge. It allows one to use vertex groups with lattices, beveling, advanced solidify modifier options, all kinds of stuff.

I look forward to the day that geometry nodes can fully replicate the other modifiers, but until then, a work around like this would extend Blender capabilities immensely.

Thanks. I need vertex weights, for my procedurally generated model, to apply an armature. It's a shame they broke it and seem unwilling to fix it with such a simple fix. :(
I have a really nice model rigged in 3.2 that outright breaks in 3.4, as all the vertex groups have no values any more. :(

> In #99197#1417901, @rcrandolph wrote: > Hey Carl Olsen, I agree using vertex groups with joined geo node geometry is extremely useful. The hacky, buggy, awful work around I've found is to download the source code for Blender, remove the line of code added at https://developer.blender.org/rB5d67b524412d0dab936170eef65c508930ba4c30 "BLI_freelistN(&dst_mesh->vertex_group_names)", and then build a custom version of Blender with this code change. It looks like the update was added to remove crashes when attributes and vertex groups have the same name, which is reasonable. However, the power of being able to combine geometry nodes, vertex groups, and other modifiers is so powerful that I'm willing to manually avoid double naming anything. The crash comes up when, for example, you have a vertex group and color attribute with the same name. Just make sure not to do this and it appears to work great. > > Devs, is it possible to, when naming conflicts occur, just disable the join node with a warning? I noticed that there's already a warning system under color attributes when there's vertex groups and colors with the same name, "Warning: Name Collision: group_name" Maybe the join node can be automatically disabled and the same "Name Collision: group_name" warning can come up on the join node when this occurs? It's a pretty easy problem for the user to avoid once the principle is understood, and being able to use vertex groups still is huge. It allows one to use vertex groups with lattices, beveling, advanced solidify modifier options, all kinds of stuff. > > I look forward to the day that geometry nodes can fully replicate the other modifiers, but until then, a work around like this would extend Blender capabilities immensely. Thanks. I need vertex weights, for my procedurally generated model, to apply an armature. It's a shame they broke it and seem unwilling to fix it with such a simple fix. :( I have a really nice model rigged in 3.2 that outright breaks in 3.4, as all the vertex groups have no values any more. :(

Jacob Merrill commented

2022-12-27 01:50:54 +01:00

Added subscriber: @JacobMerrill-1

Jacob Merrill commented

2022-12-27 01:50:54 +01:00

A temp workaround would be to copy the data from the evaluated mesh, and then write it to a copy of the mesh without geometry nodes using python.
(if you need this for a production etc)

import bpy
context= bpy.context

depsgraph = context.evaluated_depsgraph_get()
ob = bpy.data.objects
new = ob.copy()

eval_ob =  ob.evaluated_get(depsgraph)

from here we can access the attribute and write to a vertex group
let me know if you need more

if you need it to update each frame consider a modal operator*

A temp workaround would be to copy the data from the evaluated mesh, and then write it to a copy of the mesh without geometry nodes using python. (if you need this for a production etc) ```Py import bpy context= bpy.context depsgraph = context.evaluated_depsgraph_get() ob = bpy.data.objects new = ob.copy() eval_ob = ob.evaluated_get(depsgraph) ``` - from here we can access the attribute and write to a vertex group - let me know if you need more if you need it to update each frame consider a modal operator*

Mike commented

2022-12-27 14:40:56 +01:00

In #99197#1465946, @JacobMerrill-1 wrote:
A temp workaround would be to copy the data from the evaluated mesh, and then write it to a copy of the mesh without geometry nodes using python.
(if you need this for a production etc)
    import bpy
    context= bpy.context

    depsgraph = context.evaluated_depsgraph_get()
    ob = bpy.data.objects
    new = ob.copy()
    
   eval_ob =  ob.evaluated_get(depsgraph)

   #from here we can access the attribute and write to a vertex group
   #let me know if you need more 
if you need it to update each frame consider a modal operator*

Great minds think alike! I tried making a script to edit the vertex groups from the attributes, but found out the Geo-nodes models are completely detached from vertex groups.
I didn't think about making a copy.
Instead of making an entirely new object in python, I'd like to using an existing object and copy the evaluated data to the base mesh of the new existing model. Is there a simple command to do this? Like have two objects selected, the first being the geo-nodes object, the 2nd being a blank (or default cube) and copy evaluated data from 1st to base mesh of 2nd?
You mentioned modal operator for frames. This would be great for polymorphing during animations. I know a tiny amount about Blender's python, but not enough get this done in a reasonable amount of time.

Again, I can't thank you enough. I've been working on this project for 6 months, 10+ hours every day, when 3.0 came out. Any and all help to push forward is greatly appreciated.

> In #99197#1465946, @JacobMerrill-1 wrote: > A temp workaround would be to copy the data from the evaluated mesh, and then write it to a copy of the mesh without geometry nodes using python. > (if you need this for a production etc) > ``` > import bpy > context= bpy.context > > depsgraph = context.evaluated_depsgraph_get() > ob = bpy.data.objects > new = ob.copy() > > eval_ob = ob.evaluated_get(depsgraph) > > #from here we can access the attribute and write to a vertex group > #let me know if you need more > ``` > > if you need it to update each frame consider a modal operator* Great minds think alike! I tried making a script to edit the vertex groups from the attributes, but found out the Geo-nodes models are completely detached from vertex groups. I didn't think about making a copy. Instead of making an entirely new object in python, I'd like to using an existing object and copy the evaluated data to the base mesh of the new existing model. Is there a simple command to do this? Like have two objects selected, the first being the geo-nodes object, the 2nd being a blank (or default cube) and copy evaluated data from 1st to base mesh of 2nd? You mentioned modal operator for frames. This would be great for polymorphing during animations. I know a tiny amount about Blender's python, but not enough get this done in a reasonable amount of time. Again, I can't thank you enough. I've been working on this project for 6 months, 10+ hours every day, when 3.0 came out. Any and all help to push forward is greatly appreciated.

Lai Yu-Hsuan commented

2023-02-06 21:09:33 +01:00

Added subscriber: @raincole

Lai Yu-Hsuan commented

2023-02-06 21:09:33 +01:00

That's... quite bad. It rules out the most usage of geometry nodes, at least for me.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Geometry Nodes: writing attributes (from procedurally created geometry) to vertex groups not working #99197