0
$\begingroup$

I made a geometry node to make skin of characters shrink whenever a tight clothing/accesoires is worn. Like this image down here. enter image description here

How it works:

Arm Object: For this to work, I gave the Arm object a geometry node modifier that moves in normal position based on the 'Band'objects proximity.

Band object: The Band Objects is connected by using a Surface Deform modifier binded to the Arm object. So when the Arm objects shrinks, the band shrinks with it.

By looking at the screenshot, you can see that this seems to work. But the problem is, that it does not render as in the screenshot. Instead, it shrinks the entire object as if ignoring the Band object. If I delete the Surface deform modifier, it works fine, but then the band object does not deform anymore.

My question is: Why does this seem to work in the viewport, but not when rendering?

My guess is that this has something to do with how blender calculates the objects in a particular order. Since both objects influence and depend on each other, I guess that is the problem?

I know how to find a way to work around: By creating shapekeys! Yes, I am aware of that. I made this node to make a quick and easy way for multiple characters and clothing sets. If there are other suggestions other than shapekeys, then please let me know.

Thanks a lot

I can provide Blend file if needed

$\endgroup$
2
  • $\begingroup$ I imagine you checked in the console that you have indeed "Dependency cycle detected" error messages ? If not, may I suggest to look here: Dependency Cycles In Blender - How To Find And Fix them $\endgroup$ Dec 3, 2023 at 14:48
  • $\begingroup$ Thank you for the link. Yes, it does give a dependency error! Nathan gave an answer in how to avoid that. Thanks! $\endgroup$
    – DarkSoul
    Dec 3, 2023 at 20:10

1 Answer 1

4
$\begingroup$

Usually, what you need to do to make what seems to be a circular dependency work, is to reconceptualize exactly what you want so that you can build it without any circular dependencies.

You have a band, surface deformed by a mesh, and that mesh is measuring its proximity to the band. But most likely, you want the proximity to the band from before it gets surface deformed, not after. You offer:

If I delete the Surface deform modifier, it works fine, but then the band object does not deform anymore.

So it's clear that what you want is not really a circular dependency, not conceptually. You want the proximity to the object from before it gets surface deformed, and then you want to surface deform it.

You can do this by creating a third, non-rendering object. Duplicate the band to band.001; disable rendering on band.001 and delete the surface deform modifier on it. The arm gets proximity from band.001, while the original band, the rendering band, gets surface deformed from the arm. (In many cases, you would then parent band to band.001, but not where you're surface deforming, which shouldn't be accompanied by transforms-- but, surface deform may not be what you want to be using.) You now have a clear, linear hierarchy: band.001->arm->band.

Why does this seem to work in the viewport, but not when rendering?

In Blender, objects get updated in a number of circumstances; every time they get updated, all of their modifiers are recalculated. When there's a circular dependency, it's pretty much a crapshoot as to which object is evaluated by Blender first, like on a frame change or a file load, but if you do something that updates the first object, like tab into and out of edit mode, then that object will get re-evaluated, which will allow it to read from an object that is dependent upon it-- but, only once, not in an unending loop of recalculation.

But the instant you render, these objects are, yet again, recalculated from scratch. The circular dependency makes it so that you might see one thing or the other in the viewport, depending on what actions you've taken that update objects. But, when you have a circular dependency, what you see in the viewport is not necessarily what you'll get when you render (which is a very bad thing, and a reason to never have any circular dependencies even if they seem okay. You don't want to spend a day rendering just to discover that it doesn't look like your preview.)

Here, it sounds like you're not after a true circular dependency-- that the addition of an extra object can turn it into a healthy hierarchy. Every once in a while, someone is looking for a truly interdependent system. Physics is an example. In cases like this, GN can be useful. You calculate all operations before implementing any of them; you likely repeat this a number of times. However, here, it doesn't sound like you're looking for this.

$\endgroup$
2
  • $\begingroup$ Nathan, thanks for your detailed answer. I am wondering: does Blender have an future that allows you to choose what order to 'calculate'? I think a feature like that would be awesome. I marked your your response as correct, because it works nicely. A smart solution! But in my case, not what I was looking for. For me, I would have to make the band.001 object connect to a rig. THe problem with this, is that when the Arm objects has shapekeys, I would have to copy ALL the shapekeys to the band.001 object, which is time consuming for multiple sets. That's why surface deform modifier is perfect. $\endgroup$
    – DarkSoul
    Dec 3, 2023 at 20:16
  • $\begingroup$ @DarkSoul "I am wondering: does Blender have an future that allows you to choose what order to 'calculate'?" I would be surprised if Blender ever implemented something like that. $\endgroup$
    – Nathan
    Dec 3, 2023 at 22:07

You must log in to answer this question.

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