odf opened this issue on Aug 20, 2009 · 49 posts
LaurieA posted Tue, 25 August 2009 at 8:12 PM
Quote -
Quote - lesbentley: I didn't know about "linkParms". Pretty cool stuff! I think for things like cat-eyes or pupil dilation it's perfect.
Now I wonder if it's possible to rig the eyes so that moving the left eye would also move the right eye and vice versa, but one could still achieve a cross-eyes look via a separate dial.
(above quote is from another thread) It should be possible, but I'm not sure I would not recommend it, as I think it makes things unnecessarily messy and complex, when the current system of control dials in the head works well. Personally I might have gone for ERC and control dials in the head for Dilate and CatEye, except there is no way I can inject a new valueParm channel from a pz2. I can't even inject a delta-less targetGeom, as Poser only saves targetGeom to a PMD when they have deltas in them. So 'linkParms' was more of a workaround here than anything else.
Problems with linkParms are that once channels are linked there is no way (that I know of) to unlink them, short of editing the cr2. Also it's a strictly one-to-one link, once a channel is linked it can't be linked to a second channel, and there is no control ratio.
If you did want to do it I think this should work. Link two channels, say yrot in each eye, then create a new hidden rotateY channel named "yrot2" in each eye. Then slave the "yrot2" channels to a valueParm (or targetGeom) in the head named "Cross-Eyes".
Whilst we are on the subject of the eyes. Some morphs will move the eye sockets. In a case like that translating the eye to fit the socket via a pose or its dial, is not good, because the fist time you apply a stock pose, it will reset the translations back to zero. So IMO the translate channels in the eyes should be slaved to valuParm (not targetGeom) channels in the head, in much the same way you have done for eye rotations. People who make morphs that move the sockets can then inject slaving code into the CTRL channels in the head, to translate the eyes when the morph is applied. The CTRL channels need to be built into the cr2 because of the difficulties associated with injecting new CTRL channels from a pz2. The CTRL channels for translation should be valueParm, precisly because their values will not be saved to a pose file. You don't want a pose saved for the purpose of turning the head, to translate the eyes.
For rotating both eyes you have used targetGeom channels. This means that if a pose saved with "Include morph channels in pose set" it will include those rotations set via the CTRL channels, but a pose saved without that option will not. Unlike eye translation it is probably a good idea to save eye rotations to a pose file, but the inconsistency here may confuse some users. I think this inconsistency can be resolved my creating a ghost actor as a child of BODY (named, say "actor CTRL:1"). The ghost actor would then contain translateY channels like this:
actor CTRL:1 { name CTRL off bend 1 dynamicsLock 1 hidden 0 addToMenu 1 includeInDepthCue 0 parent BODY:1 channels { translateY CTRLEyesLeftRight { name EyesLeftRight initValue 0 hidden 0 forceLimits 0 trackingScale 0.04 keys { static 0 k 0 0 } interpStyleLocked 0 } translateY CTRLEyesUpDown { name EyesUpDown initValue 0 hidden 0 forceLimits 0 trackingScale 0.04 keys { static 0 k 0 0 } interpStyleLocked 0 } } }
And in the 'figure' section, after the 'defaultPick' line you would place this code: linkParms head:1 CTRLEyesLeftRight CTRL:1 CTRLEyesLeftRight linkParms CTRL:1 CTRLEyesLeftRight head:1 CTRLEyesLeftRight
linkParms head:1 CTRLEyesUpDown CTRL:1 CTRLEyesUpDown linkParms CTRL:1 CTRLEyesUpDown head:1 CTRLEyesUpDown
Because a pose file will always record a translation channel in the CTRL:1 (unless "Select Subset" is used to exclude that actor) the value of the CTRL channels will always be recorded and applied by a pz2 file. This stuff about a CTRL:1 actor is a bit experimental, but I did do a quick test, and it seems to work well. If you would like to see a cr2 rigged as above, I could email you one.
So, lets say for the sake of argument (and because I've actually created them...lol). I have morphs that make the eyes move apart/closer and up/down and in/out. I can bring the eyeballs with them??? As it stands now tho, I can only move the eyeballs with a morph target which distorts them sometimes if I don't make the falloff big enough. If I could actually move the eyeballs and not distort them that'd be perfect.
Laurie