Added a "Scale Compensation" plug to both twistSpline & riderConstraint nodes.

[mdilena]

Checklist

• I have read the CONTRIBUTING.md document
• I have added documentation regarding my changes where necessary

Types of Changes

• Bugfix (change that fixes an issue)
• New Feature (change that adds functionality)
• Documentation Update (if none of the other choices apply)

Proposed Changes

Here I am just making sure the rig is scalable by providing a couple of extra "Scale Compensation" attributes to the twistSpline and riderConstraint nodes. I figured I could give it a try by replicating what I'm currently doing in the rigging tools at work to get the rig to scale correctly, which are compensating the spline parameters and the rider constraint globalSpread and normalizedValue. I haven't found any other way to make it work, so if there's any please let me know!
But if not, I think this could cut down quite a few unnecessary nodes in a rig, as each spline param would otherwise need a separate multiply node for the param to scale up correctly.

I also took the chance to update the attribute templates with the new attribute, along with including the previously missing twistTangent template and the outliner's icon assignment. I hope you don't mind me locking some output parameters on the twistTangent, just as a visual distinction from the input ones; if you prefer to have them editable all the time I can roll back that change!

Cheers!

EDIT: for the riderConstraint, this will work for both normalized and param-based modes!

[tbttfox]

Thanks again for the PR!
I won't be able to look at this for a couple days, but the idea sounds good at first blush.

Also. I just asked around, and the way we handle this is we just parent all the rider nodes under the spline.
Of course, that may not work for what you're doing.

[tbttfox]

I took a quick look this morning. I built a spline using twistSplineBuilder.py and I just multiplied the inputs of the .globalOffset and .globalSpread parameters of the rider constraint by the scale value coming in from the *Global_Part object, and with that change everything I do seems to scale correctly.

Could you send me a file/script/something so I can see your issues better?

[mdilena]

Basically, all works fine like you said when you're in normalized mode and you only compensate for spread and normValue, but the moment you turn that off and use param mode and you start pinning, the parameter values need to be compensated too. If you don't compensate for global spread and you pin everything it looks alright when scaled, but when unpinned they shrink, while if you compensate for global spread they shoot in hyperspace 🙂

I will try and upload a file later!

[mdilena]

twist_spline_scaling_debug.zip

There you go, hopefully I haven't forgotten anything in there. This shows what happens in various conditions:

• Scales up in normalize mode
• Parameters get pinned on every control
• Mode is swapped to parametrized by turning normalize off
• Pins on all controls, except from first one, are turned off
• Scaled back down

I've put a bunch of attributes on the global control in order to easily swap modes on the rider constraint. I tried reloading the same file with the changes in this PR, and there's a case I don't seem to have caught (normalized + pinned), but most of it seems to work by just connecting the scale compensation and removing the extra multiply node I added for the global attributes.

[mdilena]

One small correction: the frames between 60 and 80, I actually don't expect that to work as it's just the blending between the two distribution modes, so I don't think it'll ever be necessary (they do stretch at normal scale too during the blend).

[mdilena]

I figured that, if we decide at some point to go on with this, the version should probably be bumped to 1.2.0 due to the functionality change, although one could always ignore the new plugs and keep on going with the old way of compensating without issues.

I also updated the python script so when built it connects the two new attributes automatically!

[tbttfox]

OK, I see what you're getting at. My quick testing definitely didn't cover that case. Thanks for finding that!

I've got some changes I'm working on as well (a new single tangent node rather than the multi-node setup per tangent).
So I'm going to rebase my stuff on yours and test. If it all works out, I'll go ahead and merge both, and up the release tag.

[mdilena]

Sounds great! Good timing as I'm also refactoring the tentacle component at work 😁