8
$\begingroup$

This is my Geometry Node Setup. (EDIT: Here's a .blend file showing my nodes, modifier, vertex group, etc.) I create a grid, rotate it vertically, and then select out the topmost vertexes to assign to a vertex group. Geometry Node Setup, as described My vertex groups, showing Pin vgroup Geometry Node modifier, showing Pin vgroup assigned to geometry node output

I then try to use this vertex group to Pin a cloth simulation to stop it from falling. It doesn't work, it falls anyways. Cloth Physics settings, showing Pin group selected

I've used the Delete node to test and confirm the vertexes are being correctly selected by my nodes.

If this is no longer the way to set a Vertex Group output in 3.3, what is the correct way? If 3.3 no longer supports setting vgroup outputs at all, that's a breaking change considering that we're nowhere near ready to abandon vgroups...

I've searched and found other questions regarding merging vertex groups, but not straight up assigning them.

$\endgroup$
6
  • $\begingroup$ Good question I can reproduce this. In 3.1, I had to connect the original geometry to 'carry' the vertex group, and set the output to float to get it to work. But so far in 3.3 and 3.4a.. no joy. $\endgroup$
    – Robin Betts
    Sep 21, 2022 at 20:35
  • $\begingroup$ @RobinBetts Do you know if there's been a bug report related to this? I can confirm problems that feel new to 3.3 w/r/t assigning VGs. But I've made enough bug reports that they seem to be ignoring me (who knows, maybe I'm paranoid) and I don't want to invest time into investigation if it's already been reported. $\endgroup$
    – Nathan
    Sep 21, 2022 at 22:38
  • $\begingroup$ am i totally wrong, but wasn't this always the case if you build geometry in GN? you could change it if the VG and the vertices exist in "real" objects, but geometry built by GN it never worked...AFAIK...but looks like i am wrong, if Robin and Nathan think different.... $\endgroup$
    – Chris
    Sep 22, 2022 at 5:28
  • $\begingroup$ Hi @Nathan + Chris I managed to get it to work in 3.1 by passing the (single-vertex) modified object's geometry through the modifier, joining it to the generated geometry. (The vertex-group was 'extended' to include the generated vertices.) It worked only if the modified geometry was top-socket in the Join Geometry node, which is suspicious, IMO. That node shouldn't care about order. I think I agree with Chris, it was never intended to work. A good route would be to have other modifiers like Cloth accept any named attributes.. $\endgroup$
    – Robin Betts
    Sep 22, 2022 at 16:42
  • 2
    $\begingroup$ @RobinBetts I found developer.blender.org/T100908 , closed as duplicate of developer.blender.org/T99197 (even though they refer to bugs that skipped an intervening version) with the disappointing statement, "At this point this is just a known issue/limitation." That's join geometry, but it looks to me like pure GN geo is handled the same way. Unfortunately, this rules out an awful lot of things I want to do with GN. Can't get it to work with your workaround, but who knows, maybe I'll figure something out. $\endgroup$
    – Nathan
    Sep 22, 2022 at 18:11

1 Answer 1

12
+75
$\begingroup$

I figured out a workaround. It wasn't easy, because Blender 3.3 is terribly unstable and I would get various errors in the console while playing with settings - restarting Blender would fix them, but keep that in mind, as you may think some technique doesn't work, while it's the corrupted state that causes issues and requires a restart...

So here's the exact steps for everyone to easily reproduce without the need to jump through hoops:

  1. ⭾ Tab Edit default cube, X, V delete all geometry.
  2. Create a Vertex Group PIN.
  3. Add an empty
  4. Add the following stack of modifiers to the 'Cube', non-default settings in red rectangles:

  1. Add the Geometry Nodes tree of your choice to the first modifier. You need to change it by adding the contents of the blue frame to it:

It saves the calculated vertex positions and then moves vertices away from the empty so the Vertex Weight Proximity modifier can do its work.

  1. Add a new node tree to the last modifier (2nd geonodes modifier) which simply restores the saved positions:

  1. Finally, add the Cloth modifier and set the PIN group.

An additional tip: whenever you change the geometry nodes setup, you may need to fiddle with a vertex weight modifier to update the whole setup...

Another remark: you absolutely can use the default geometry, as in, you don't have to apply the step 1. in this answer. However, in such case, you have to either add "Delete Geometry" node inside your setup (so e.g. you spawn instances on original vertices, but when you apply the boolean, you don't boolean with the original cube, as you delete it before the boolean node), or just make sure the boolean doesn't screw your geometry, by e.g. offsetting before boolean and reverting the position after the boolean...

Example: changing PIN during simulation

Vertex group for pinned vertices can be changed during the cloth simulation. Unfortunately, when you change the PIN, new pinned vertices aren't pulled to their last position before being pinned - they are pulled to their original position calculated in the geonodes:

Something less erratic:

Using Pressure = 1:

$\endgroup$
3
  • 2
    $\begingroup$ Yikes. + (Heaven knows how many) for the work you've put in $\endgroup$
    – Robin Betts
    Sep 25, 2022 at 20:42
  • 1
    $\begingroup$ @RobinBetts I almost gave up, I literally wrote a comment that it seems there's no chance to make it work since even the Vertex Weight Edit doesn't work, but then I discovered error messages in console and tried again... $\endgroup$ Sep 25, 2022 at 20:51
  • $\begingroup$ @vklidu thanks for the bounty! 🤑 $\endgroup$ Oct 28, 2022 at 9:39

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .