Hi there,

I try to figure out if there is a way to non-uniformly scale bones. I need a
Squeeze and Stretch effect on mesh. Or ist there a better way to achive this.

any advice is appreciated,

Thanks

Use the deform capture region parameters on the bone.

Thanks Edward!!!

It works somehow….
Are there any rules or good ways to connect all those relationships together?

I used an if expression so far. But I noticed that the expression seems not to work after I reload the hip file, and needs to be reactivated manually. It all seem not to be very robost by now.

Do you have any suggestions on this?

Enclosed a hip file

There are some inefficiencies in your .hip file but the main mistake is that you're doing a ch() expression to a point() expression which uses $PT. But $PT only exists during cooking so that can't work. Given your set up, it's simple to just replace $PT with 0 to have it work consistently.

So some of the things which I think can be improved are:
- No need to use AttribPromote from Primitive to Point just to use the point() expression. Instead, just use prim() expression directly. Again use 0 because you only have a single primitive.
- Better yet, don't use SOPs to calculate the distance between two object nodes. You can directly use vlength(vtorigin(“/obj/chain_root1”, “/obj/chain_goal1”)). If you're worried about recalculating it all the time, then you can put it directly into an AttribCreate.

I've attached my modified .hip file by directly using vlength(vtorigin()).

Thanks Edward!!!

Everything works great now. The only thing I dont get is why replacing “$PR” with “0”works fine. Does the reading of one prim need no cooking although its still a sop based point() or prim() expression. Why?

It distroys my little logic construction


Cant find that in the documentation.

Thanks Edward.

$PT and $PR are called “local variables”. Local variables like $PT work in the Point SOP like this:
- The SOP cooks
- For each point, the node evaluates the parameter
- When the parameter evaluates and it sees $PT, the current point number is substituted (eg. 0, then 1, then 2, etc.)

In your case, the SOP is *not* cooking at all, the *OBJECT* is cooking. So $PT can't be evaluated.

Thanks Edward!

But one last question, why does this still work?

prim(“../out”, 3, “area”,0)
prim(“../out”, 5554561 , “area”,0)
prim(“../out”, 266, “area”,0)

It seem not to matter which primitive number is entered!

Is it just a placeholder in that case?

I think that the primitive number is silently clamped (aka limited to the number of primitives) by the prim() expression. And in this case you only have 1 primitive so the clamped result is always the same.

Thanks Edward!