modifying vellum constraints over time

[freejonah]

I'm building a relatively complex Vellum DOP setup using multiple objects with different constraint arrangements. The issue I'm having is my usual Achilles heel with this sort of thing: modifying attributes and values mid-sim.

My specific issue is that I have a Vellum cloth object that is using the Pin to Target constraint option to follow some geometry I'm animating in SOPs. I created a point attribute for the target weights and that's working fine. My problem is that around halfway through the sim I want to animate down the target influence for this specific pin constraint.

I have partially solved the problem using the Vellum Constraint Property DOP and animating the "Remove" value from 0 to 1 at the frame I want the pins to disengage. This works nicely as long as you're careful to select the specific constraint geo in the Group field of that DOP it will work. It's working so I'm going to get through this project using this method, but I'm having a really hard time figuring out how to modify my existing per-point constraint values using these fields.

My questions:

There are a bunch of specific vellum constraint attributes represented like Stiffness, Damping Ratio, etc. in the Vellum Constraint Property DOP that I can play with over time. Are these scalars that multiply by the point attributes I already have? Or are they values that will override the ones I've already set?

Assuming they are overrides, is this why the VEXpression toggle and field is there? If I do something like "stiffness=stiffness*(fit($FF,50,100,0,1)" will this remember the original value of stiffness or is that being reset each frame?

There is also the SOP solver methodology where I can modify the definition of the Constraint Geo over time. I can always fall back on that but it's also kind of tricky to setup. Hoping for something simple and effective that can just be wired into my DOP network.

I really rely on the Sidefx example files to guide me through a lot of these setups, but I find that these kinds of constraint modification setups are in short supply. Would love to know how everyone handles this sort of thing.

If anyone has guidance on this sort of thing, let's discuss. Thanks community.

[anim]

11 minutes ago, freejonah said:

There are a bunch of specific vellum constraint attributes represented like Stiffness, Damping Ratio, etc. in the Vellum Constraint Property DOP that I can play with over time. Are these scalars that multiply by the point attributes I already have? Or are they values that will override the ones I've already set?

they are overrides, apart from Rest Length Scale which is multiplier of f@restlengthorig attribute which has stashed original restlength 

so in the same way you can store original stiffness (without exponent) as an attribute like f@stiffnessorig and then in VEXpression do

stiffness=f@stiffnessorig*(fit($FF,50,100,0,1);

be really careful about the values as since stiffness was split into base and exponent, the stiffness parameter is only the base part and stiffnessexp is the exponential part, so make sure your f@stiffnessorig has just base part

or you can alternatively have f@stiffnesexporig and do 

stiffnessexp=f@stiffnessexporig*(fit($FF,50,100,0,10);

etc...

[freejonah]

Thanks Tomas. This is great information. I kind of feel like an example file in the Vellum Constrain Property section of the Houdini help would be really helpful. I have been digging for a while and I've never found anything in the documentation about using "orig" suffix on standard constraint attributes. Also this separate base and exponent component phenom is a bit of a black box as well. Would you happen to have a lead on documentation about this sort of thing?

[anim]

10 minutes ago, freejonah said:

I've never found anything in the documentation about using "orig" suffix on standard constraint attributes

this is not anything standardized, this is how f@restlengthorig is named, so I just shown how you can extend it to others

just to not be confused there is no such thing as f@stiffnessorig, f@stiffnessexporig, ..., the fact I used f@stiffnessorig, etc... as an example name is just an example of how you can call it (call it f@foo if you want), it's up to you to store the value before sim , so that you can use it in the sim since the actual f@stiffness will be changing

Edited May 13, 2020 by anim

[anim]

11 minutes ago, freejonah said:

Also this separate base and exponent component phenom is a bit of a black box as well

it is and isn't, vellum is highly based around HDAs and VEX so you can easily see inside what things do if you are in doubt about certain things like whether stiffness variable in VEXpression contains full stiffness or just the base value from the parameter, etc... obviously noone expect you to understand everything that's going on under the hood, but a simple peek inside can clarify a lot of stuff

[freejonah]

1 hour ago, anim said:

it is and isn't, vellum is highly based around HDAs and VEX so you can easily see inside what things do if you are in doubt about certain things like whether stiffness variable in VEXpression contains full stiffness or just the base value from the parameter, etc... obviously noone expect you to understand everything that's going on under the hood, but a simple peek inside can clarify a lot of stuff

I get it. You're saying that I should generate a bunch of my own attributes that won't be modified during the sim as persistent containers. Name them whatever I like so I have access to them in the Vex expression area. That makes great sense. I get it's time to put my wet suit on and dive into that HDA and see what's going on in there

Thanks for taking the time to help me out. I appreciate it.