Constraint group broken

[breadbox]

I've been messing around with constraints lately and I stumbled on an example where a glue constraint primitive would break, then unbreak, and break again. That is to say the impact value on a given frame was above the strength of the bond and so it added itself as "1" to the @group_broken then on subsequent frames it un broke giving the @group_broken a value of "0".

Am I crazy or is that expected behavior?  I thought once a glue constraint was broken it was forever broken?  

[StepbyStepVFX]

Maybe you need to add a sop solver on the constraint network node, and inside, add a delete node setup on "broken" group. This will avoid the problem mentionned above :-)

Edited April 28, 2018 by StepbyStepVFX

[breadbox]

yes its not a problem per say, I'm just curious about the expected behavior.  I always thought once broken a constraint was broke it was always broke... so this would fundamentally change how I need to think about how the solver behaves. 

[StepbyStepVFX]

7 hours ago, breadbox said:

yes its not a problem per say, I'm just curious about the expected behavior.  I always thought once broken a constraint was broke it was always broke... so this would fundamentally change how I need to think about how the solver behaves. 

Indeed, Glue seems to work without the delete node inside a proper SOP solver, probably as a fallback solution, because people may forget to delete the "boken" primitives of the constraint network (I guess SideFx have seen that and implemented a proper test to check if primitives of the constraint network are broken or not ?)

I don't use that much the shelf tools when it comes to RBD (because I like to understand and control what happens), but I have rermarked that when you use the Glue button, it creates a constraint network from your fractured objects and set all the attributes, but it also create a constraint network node, a glue constraint node AND a sop solver with a delete node inside, which you may forget to do if you don't use the shelf tool :-)

So it seems that having a sop solver + a delete node setup on broken, inside the sop sover, is the "standard way to go" :-)

Edited April 29, 2018 by StepbyStepVFX

[breadbox]

Well well well would you look at that, the shelf tool does indeed create a delete node in a sop solver to remove constraint prims.

I myself don't use the shelf tools and I would have to say about 99.9% of the tutorials about glue constraints also omit this sop solver step which removes the prim. It does seem that sideFX has enabled the breaking constraint without it, which makes me wonder if sop solver to force remove prims is now redundant? 

 

So I tried to add the delete prim into the sop solver network to make this particular example of constraints more stable and still getting blinking constraints on and off and on again. can't really explain it. maybe its somehow caught between a pre and a post solve state? 

 

Dop_glue_v01.hipnc

[StepbyStepVFX]

2 hours ago, breadbox said:

Well well well would you look at that, the shelf tool does indeed create a delete node in a sop solver to remove constraint prims.

I myself don't use the shelf tools and I would have to say about 99.9% of the tutorials about glue constraints also omit this sop solver step which removes the prim. It does seem that sideFX has enabled the breaking constraint without it, which makes me wonder if sop solver to force remove prims is now redundant? 

 

So I tried to add the delete prim into the sop solver network to make this particular example of constraints more stable and still getting blinking constraints on and off and on again. can't really explain it. maybe its somehow caught between a pre and a post solve state? 

 

Dop_glue_v01.hipnc

In the file you shared you have animated the network at SOP level, not in DOP. Therefore, it has automatically set your constraintnetwork1 "Overwrite with SOP" to 1, which means that you can delete some constraints in DOP, but next time step, it takes the whole network again (which is still intact in SOP, with modified strength values in your case), which makes some previsously deleted prim to appear again at the end when conditions are met. If you want to allow your constraint to break, while keeping the animated strength values, you should animate them in DOP, within the SOP solver, before the Delete node.

By the way, I see in your comments "@strength can be set on the properties sop inside the dopnet. doing both up here in sops lets you do keyframed effects more easily" : but be careful, if I my memory don't confuse me, those values are multiplied (when you put an attribute in sop, it multiply this value with the one in the tab of the Glue Constraint node in DOP).

Edited April 29, 2018 by StepbyStepVFX

[breadbox]

Ahhhhhh ok great.  makes a little more sense.  This was an example network I was examining, not one of my own design.  I'm using it for learning purposes  

Typically I would build it a little different instead of animating the @strength value in SOP land, I would put in a static attribute such as break frame where the constraint could be set in conditional statement in a sop solver within the DOP network to break at a predefined time.  That might lead to more consistent/stable solving of results per frame.  

Now it makes sense why the constraints were re-making themselves because they were being brought in fresh every frame with the overwrite with SOP!  this is great to know, thanks for the help.