Poser 7 introduced something new, called dependent parameters.  They're a lot like ERC only more powerfull.  Has anybody tried using them?

I ask because I want to include dependent parameter slave-master relationships in the upcoming version of EasyPose Underground and it would be really useful to see some practical examples of things people have done with them.

O.o

I didn't even know about them. Is there any of the included content that uses them? Like the "move several bodyparts at once" dials on Sydney perhaps?

I'd like to know more about these as well - as I'll probably be hearing about them at some point. :)

They're explained in the appendix of the manual. If you have seen Maya's driven keys, this is pretty much the same idea. Where the other ERC functions give you a simple linear relation between two parms ('as parm A increases, increase parm B too'), the new valueOpKey allows you to establish more complex relationships based on key positions ('as A goes from 0 to 4, set B to 90 to -3; as A goes from 4 to 10, set B to -3 to 40').

Thanks, stewer.  Haven't even had time to play P7 let alone look over the manual. :)

Ajax, can you provide any practical examples of this feature ?

Attached Link: http://ockhamsbungalow.com/DreamVillage/1950Phono.zip

The tone-arm action works like a charm.  I also used the Key on the OpenLid control, 
to give it a good workout ... and also because the key list is easier to calculate
than the old deltaAddDelta.  It's a great addition to Poser!

On the OpenLid, there seems to be an 'interval error'  in the workings of the
valueOpKey.  The code is shown here, and looks OK to my eyes. But as
you increase the main control, the lid opens properly until you hit 1.0.  At
that point it snaps shut again.  At .999 it's still open, which is why I suspect
either an [interval) problem or some kind of zero-based versus 1-based 
confusion in the coding.

This code seems to work perfectly.

Hmm...  Now I'm confused.  The manual says that the ValueKeys are deltas, 
not actual key values.   But if that's the case, the tone-arm action shouldn't work.

The first -12 would raise it; the next -12 would raise it again but hit the limit, so
it would accidentally look the same as a non-delta entry of -12.  But the 0 on the 
last key should leave the arm up if the values were deltas.  

(It would have to be +12 to lower the arm if we were doing deltas.)

In fact the arm does return down to 0, as you'd expect from a non-delta entry.  

So which is it?  Deltas or plain values?

BM

BM II ;)

After more fiddling, I think the 'snap-back' on the OpenLid was just
the usual ERC weirdness ... sometimes the action is delayed and
sometimes it isn't.

But I'm still convinced that the manual is wrong when it talks
about deltas. 

Nevertheless, assuming plain instantaneous keypoints, the feature 
works beautifully.  

In other words, the 'valueKey' entries are identical to 
the 'k lines' in a PZ2 or PZ3.

Edit for precision:

In other words, the 'valueKey' entries are sort of like the 'k lines' in
a PZ2, except that the left numbers here are locations along the
control range, while the left numbers in the PZ2 are locations along
the time range.

What's the interpolation look like? ;)

Yes, I agree.  This looks hauntingly like the k lines for animation.  But obviously, they are setting a mapped range between values rather than a mathematical (procedural) relationship like other valueOp commands.

The interpolation is definitely spline when I watch the figure itself.  
When I remove the upper limit, the tone-arm goes through the
typical spliny overshoot.

Can't show you a graph, though, because the slave movements don't 
make any marks on the keygraph.  Only the valueparm change shows.

Those strange afterimage lines don't mean the phono is playing
"Lucy in the Sky with Diamonds" .... they're just artifacts of the PSP
Gif-maker's highest file compression.  They turn out to be useful
here, though.

And I thought it was the LSD. ;)

So they do look very promising.  Instead of having a linear relationship (Add, Minus, Divide, Multiply, blah, blah), you can create more complex non-linear relationships - slide A->B and get a complex set of motions on the slave - without the complex VK-type setup (as I call it).  As you show, a set of linear values (0,0.3,0.6,1.0) can affect the slave using variable values (0,-12,-12,0) and thus impart a more interesting relationship when the slave's motion isn't just linear.  You could do linear->sin (sine waves), linear->exponential, linear->pseudo-random (very pseudo as the periodicity would be short unless you can specify a large range of valueKeys).

Now all you need to do is graph plotting to make whatever relationship and give enough points for constraints.  As you note, the interpolation appears to be spline-based.  Wonder if there will be a set of 'lin/con/spl' type interpolation specifiers to vary this?

Thanks for the rigorous work thus far!

Robert

Don't forget that one parm can have multiple targets. For example, you can make an elbow bend control a series of biceps morphs or change the zone and strength of a magnet as it bends. Or you could have a "smile" dial that gives you a smirk from 0 to 0.5, an open smile from 0.5 to 1 and a grin from 1 to 1.5. The intention was definitely to give content creators the ability to create more sophisticated rigs and a tool to deal with those extreme bends. You can now have extra morphs and magnets that only kick in when the knee bend is > 110 degrees. (Actually, you could have done all that and more since ProPack through Python callbacks.) The thing about deltas - they are deltas as in that the values you specify are being added to the target parm's value. The keys themselves are not relative to each other.

The spline interpolation is great for some things but I'm really wishing there were an option for linear interpolation as well.  I'm going to try experimenting with extra key values either side of the main key values to as a way to flatten the curve between the main keys.

stewer, so does this mean that you set several slaves to a master dial and partition their response according to the master dial setting (as you say, 0-0.5 for one, 0.5-1 for another, etc)?  You can have a grimace to 'perhaps' (can't think of a good word for that look) to smile all controlled by a single dial where the progression goes through the different e-motions.  Neato. :)

Sounds very interesting for JCM type stuff where you want more complex musculature changes due to different body part bends as well as other scenarios.

Multiple targets: The tone-arm does in fact illustrate two non-linear motions,
though only the lifting is obvious. The lift goes up then down,
and the Y-rot goes faster in the first part of the move and slower in the
second part, as you'd do in the real world when putting a needle on 
a record.  

Next I'm going to make a complete changing action, including the 
drop of a smart-propped record....

This not only eliminates the 'VK code', it saves a lot of Python-coding!  

THIS IS FUN!  All this action from one dial!

======================================

Incidentally, the Make Movie function doesn't Make Movie when
set to use the P4 renderer.  It just Makes Pure Black.   I don't know if 
this has been noted yet in the P7 bug list..........

re: the Make Movie function, I've just made two that worked fine using the Cinepak codec by Radius and the P4 renderer.

Do these dependent parameters only work in a python script? I know in Maya there is a dialog box that lets you connect your set-driven keys.

 
<?))###><<  
 

The MakeMovie problem is with separate images.  I never use any of the codecs.

Just verified it again: pure black in P4 renderer, OK in Firefly.

And the new form of ERC certainly doesn't need Python.  In fact it
will replace the need for many Python scripts, because you can
now include complete animations in the CR2, ready to run in full or
in part, at any speed!   Any standard action the character or machine is
going to perform, can be moved by one dial.  

Attached Link: http://ockhamsbungalow.com/PPP/KeyframeERC.zip

You set up the animation sequence in Poser,
this script writes the code into a CR2 for you.

Couldn't resist, eh? ;)

I've downloaded it.  Sounds a much saner method to create the dependent parameters than editing the Poser file.

Thanks!

NOW i gotta get p7, this is gonna be really really important. 

@elenorcoli:  Yes indeed, important.  The biggest improvement
in any edition of Poser.

Think especially of a single-dial walk cycle......