I had what I thought was a good idea. I would use a pp2 file to inject an actor named "BodyMem" into a figure. I would then use a pose file to inject linkParms statements to link the translate and rotate channels in the BODY actor to corrisponding channels in the BodyMem actor. In theory after doing this I could apply a walk cycle to the figure, then save an animated pose, and the movements of the BODY would be recorded in the BodyMem by virtue of the linkParms. I should then be able to do the process in reverse, applying the pose to the same figure and have a walking pose where the figure actually moves forwards insterad of just walking on the spot.

It half worked. The zTran and xTran of the BODY are recorded, and can be played back from a pose file. For some reason that is beyond me, it does not work for the rotations. These are not recorded in the BodyMem actor.

The translate and rotate channels where treated in exactly the same way, so I don't understyand why it is working for one type of channel but not the other. This is only happening when the rotations are applied by the Walk Designer. If I edit the rotations in by hand, they are recorded in the BodyMem actor.

If I can get this to work I think it might be quite useful to people who make animations with walk cycles, but I'm stuck. I have tried everything I can think of but nothing seems to work. So any insights or sugestions would be appreciated.

I'm using P6 under Win 2k, the test figure was Posette.

Any thoughts?

Les, this is much like Yoda saying, "I've lost my mojo, can someone help me find it?"

Dude, you are the master. I only wish I could help. When you are stumped all hope is lost (for the rest of us). But I know you are a determined man and will eventually figure this out.

Best of luck,
Jar-Jar Binks

I'm using P6 under Win 2k, the test figure was Posette.

Have you tried this on any other figures?

Quote - Have you tried this on any other figures?

I used Posette (P4 Nude Woman) because she is relatively simple and her workings and structure are well known, and she is compatible with the Walk Designer. I don't really expect this to be figure dependant, as this relates to rotate channels and I don't see there being much difference in rotate channels between figures. The internal and dial names provide the only scope for something that could be relevant here, as far as I can see. However I did do one test using Jessi, with the same results.

I just don't understand it. It works fine for the translate channels. It even works for the rotate channels if I enter the value for the BODY rotation via the dial. It also works, that is to say the values for the rotations of the BODY are copied to the corresponding channel in the BodyMem actor, when rotations are applied to the BODY via a pose file. So why, oh why, oh why, does it not work when when the walk designer applies the rotations to the BODY???

One might suspect that this is a refresh problem, and that some sort of nudge, such as moving the camera or selecting the BodyMem actor would cause the linked channels to update, but no such luck. No matter what I do the yrot dial in BodyMem remains at zero, refusing to adopt the value from the yRotate dial in the BODY that was set via the Walk Designer.

And this is the infuriatingly arcane mystery "How does the linked yrot channel in the BodyMem actor KNOW  that the value in the corresponding channel in the BODY was set via the Walk Designer, and not by some other means?". Because this seems to be the situation, I have a value of 90° on the yRotate dial in the BODY. If that value was set by turning the dial, or applying a pose, it is respected. If it was set via the Walk Designer it is not respected. But it's the same number "90°", how does the linked channel know how it was set?

What if you used a cr2 file to inj the actor?

Quote - What if you used a cr2 file to inj the actor?

In theory the results should be the same, but I'll try it.

Tried injecting from a cr2. I Have also saved a figure after injection, checked it in a text editor to make sure that everything was injected successfully, then reloading the saved figure. The only rotate channel in the BODY that is relevant to the Walk Designer is the rotateY channel. So far I have tried:

Changing the channel type in BodyMem from rotateY to targetGeom or translateZ.

changing the internal name and dial name to "yRotate" or xxx.

reversing the sense of the linkParms, to use:

    linkParms    BodyMem
             yrot
             BODY
             yrot

Instead of: linkParms BODY yrot BodyMem yrot

Using both senses of the linkParms in the same file. Adding actual geometry to the BodyMem actor.

As it's only the rotate channels that are not working as expected, and as it is only the rotateY channel that is relevant, I have stripped down my test rig to just the rotateY channel. The actor injection pp2 now looks like this:

{

version
    {
    number 3
    }

actor BodyMem
    {

    }

actor BodyMem
    {
    name    BodyMem
    on
    bend 1
    dynamicsLock        1
    hidden        0
    addToMenu    1
    castsShadow        0
    includeInDepthCue    0    
    smartparent BODY
    channels
        {
        rotateY yrot
            {
            name yrot
            initValue 0
            hidden 0
            forceLimits 0
            min -100000
            max 100000
            trackingScale 1
            keys
                {
                static  0
                k  0  0
                }
            interpStyleLocked 0
            }
        }
    endPoint 0.0 0.0 -0.01
    origin 0.0 0.0 0.0
    orientation 0 0 0
    displayOrigin        0
    displayMode USEPARENT
    customMaterial    0
    locked 0
    }
}

And the pose file to inject the linkParms looks like this: {

version
    {
    number 3
    }

actor BODY
    {

    }

actor BodyMem
    {

    }

figure
    {
    linkParms    BODY
             yrot
             BodyMem
             yrot
    }
}

Quote - Hey Les,  do you think it would work on my figures?  The hip group is independent of the main mesh.

It should work for you to the same extent that it works for me. Any way, you have nothing to loose by trying. The files you need are attached to the second and third posts in this thread. The only requirements are that your figure has an actor named BODY, and that it uses standard internal names for the rotate and translate channels in the BODY.

The injection itself is working fine, this has been verified beyond any reasonable doubt.

Again I would stress that the problem seems to be getting the linked rotateY channel in the BodyMem actor to recognize that the value in the rotateY channel of the BODY has changed, when, and only when, this change was implemented through the Walk Designer.

Consequently I assume that a solution consists of finding some way to "tell" the linked rotateY channel in the BodyMem actor that it needs to update to the new value in the BODY. Either that, or to remove any obstruction that may exist to such an update.

This is the same technique as implemented in V4 by standard, if I remember right. There all the linkparms are defined in both senses. I'm unsure if this is neccessary cause in books I have read that the linkparm is connecting both channel directly vice versa. Other than ERC what is direction significant. So normally one linkparm definition should be enough, but how knows.

In V4 this is used to have the body movements saveable into pz2 files. So normally also saving rotations should work.

Ok, dumb question, but are you sure that the walk designer is using the usual way to input new values via the dial and not have found some way to set the value directly without using the dial.
You know what I mean, a morph value for example coming from Boady to a single actor via ERC is also not shown in the dial. So may be something out of this mysteriums ...

Oh, just had a look into V4 and have to revert the above. V4 is only using linkparmed morph channels and not the trans or rot channels.
But this additional actor, in V4 BodyMorphs, is also connected with addChild to the hip. Did you do this also ?

@ JoEtzold,

Quote - Ok, dumb question, but are you sure that the walk designer is using the usual way to input new values via the dial...

Not a dumb question at all. The values input by the Walk Designer do appear on the dial of the rotateY channel in the BODY, but it seems that there is something about the way that the values are input that is stopping them being registered by the linked channel, because any other way of inputting them does register.

Quote - But this additional actor, in V4 BodyMorphs, is also connected with addChild to the hip. Did you do this also ?

In my case the additional actor "BodyMem" is a child of the BODY. That seemed like the best place for it as it is in direct proximity to the actor that it needs to link to. When injecting an actor, I use a 'smartparent' line to set the parent. Poser automatically takes care of the 'addChild' stuff according to the actor specified in the 'smartparent' line. Perhaps it is worth trying it as a child of the hip. The only other thing I can think to do is to sacrifice a chicken at full moon, and sprinkle the blood over my PC.

Quote - In V4 this is used to have the body movements saveable into pz2 files. So normally also saving rotations should work.

I have heard that P7 allows saving of the BODY data to a pose file, are you using P7? As I am still using P6, that option is not open to me.

Quote - I have heard that P7 allows saving of the BODY data to a pose file, are you using P7?

Yes and Yes. 
In P7 you can select Body in the subset selection as such and also there is a additional question if you will include Body morphs and/or transformations into the pz2 file.

So I have tested this with V4 in following manner:

1. As described V4 has a empty actor (named but with out geometry in first section of cr2) bodymorphs. All FBM's etc. but not transformations are linkparmed twice between Body and all single actor to bodymorphs on one hand and also reverse between bodymorphs to body and all single actors.

2. So I have done equal with the yrot as linkparm from body to bodymorphs and from bodymorphs to body.

3. Have created a walkpath for V4

4. Started walkdesigner and have loaded V4 ... and was astonished that I worked. In older versions figures outside of the EF or SM hemisphere was problematic, or not ?
   Anyway I got a walkcycle for V4 ... not brilliant but ok.

5. Applied it to the scene and V4 is walking.

So every time If I'm looking into yrot in Body or Bodymorphs they have same values in their dials.
This is the same with hand inputed as with the values from walkdesigner given to the animation window. I had a look to the graphical chart of both yrot's and they are identical.

Included is a pz2 (zipped) only from the first frame. But as V4 was standing normally with yrot=0, she was turned by walkdesigner in the first frame to round 26 as startposition on the path.
And as you see the yrot values in body:2 as in bodymorphs:2 are the same.

So I think this is as you expected but didn't get with Posy in P6, am I right.

It may be that poser people fixed a bug in this with version 7 cause building in the possibility to save also body values.
So sometimes things get better as sometimes becoming worse like in example with the symmetry functions. There P7 is taking also morph values into acount, may be to mirror asymmetrical morphings. Good idea but bad done. They read the morph values from the internal actor values not taking into acount that they are given by ERC from Body. And than they reproduce them on the opposite actor via dial input ... and the ERC is adding too.
So if you have a FBM set to 0.3 for example and make one symmetry you end with 0.6 in the single actor, 0.3 set normally via FBM ERC and 0.3 via symmetry added. Second symmetry try gives you 0.9 and so on.
Use some more FBM's tah one will mess up your figure with one mirroring completely.

This behavior was the point cause I asked if there would be a mismatch between dialed desktop value and the internal unseen but read out to file value.

Though ... it's interesting while writing I have tried the same procedure as above described in Poser 6.
And it's the same as your experience ... hand dialed values are exixting and written to pz2 while values given from walkdesigner are missing in yrot.
With look to the pz2 there are differences. In the P7 version (included) you will see TWO k-lines with k 0 0 in first line and k 0 xxx as third line and these both are the same in body as in bodymorphs. But in the P6 file I hvae looked in there is only ONE k-line given for the channel and this is k 0 0 while with walkdesigner only but k 0 xxx if dialed by hand.
So this is strongly looking like a bug in Poser below version 7.

How about a test in creating a valueparm ytest in body and bodymorphs (or like you named it). Then linking both ytest via linkparm and ERC slave ytest in body to yrot in body 1:1.
So the idea is that yrot is giving it's value via ERC to ytest that should reproduce exactly in bodymorphs. Only as idea ...

@ JoEtzold,

First of all I would like to thank you for taking an interest in this, and for your clear and very detailed response.

Quote - 4. Started walkdesigner and have loaded V4 ... and was astonished that I worked. In older versions figures outside of the EF or SM hemisphere was problematic, or not ?
Anyway I got a walkcycle for V4 ... not brilliant but ok.

Yes, previous DAZ figures did not work well in the walk designer. V4 is not perfect, but a lot better than V3.

Quote - Included is a pz2 (zipped) only from the first frame. But as V4 was standing normally with yrot=0, she was turned by walkdesigner in the first frame to round 26 as startposition on the path.
And as you see the yrot values in body:2 as in bodymorphs:2 are the same.

So I think this is as you expected but didn't get with Posy in P6, am I right.

Yes, this was as expected, and hoped for. Your words here gave me a brief moment of hope, until I read further into your post.

Quote - ... it's interesting while writing I have tried the same procedure as above described in Poser 6.
And it's the same as your experience ... hand dialed values are exixting and written to pz2 while values given from walkdesigner are missing in yrot.

In one way it is good to have confirmation that this does not work in P6, and was not just a silly mistake in my syntax. In another way it is very bad news, because a silly mistake by me could be rectified.

Quote - With look to the pz2 there are differences. In the P7 version (included) you will see TWO k-lines with k 0 0 in first line and k 0 xxx as third line and these both are the same in body as in bodymorphs. But in the P6 file I hvae looked in there is only ONE k-line given for the channel and this is k 0 0 while with walkdesigner only but k 0 xxx if dialed by hand.
So this is strongly looking like a bug in Poser below version 7.

I don't have P7, but suspect that the second k-lines may be something to do with animation layers. I don't think P6 supports animation layers, and this may account for the difference.

Quote - How about a test in creating a valueparm ytest in body and bodymorphs (or like you named it). Then linking both ytest via linkparm and ERC slave ytest in body to yrot in body 1:1.
So the idea is that yrot is giving it's value via ERC to ytest that should reproduce exactly in bodymorphs. Only as idea ...

This idea also occurred to me, but then I decided that it would not work. The whole idea of using linkParms for this sort of stuff, rather than ERC, is that channels linked with linkParms will register a dial/k-line value in the channel, and this value is recordable in a pose file. The moment we introduce ERC into the chain you loose the k-line value in the slaved channel, and there is no way to restore it at some further point in the chain, so we have lost the ability to record the values in a pose file. Which was the whole point of the procedure in the first place. At least this is the way it seems to me, though I would be happy to be proved wrong here. Perhaps I will do the test you suggest, just to make sure my logic is not faulty here.

Thanks again for your interest, and for the valuable info you have passed on.

Cheers,
Les.

Les, what I didn't check in that context is if the behavior in the k-line is the same for a frame unequal 0. So for k 1 ... or such. I came across this cause I found sometimes that even in animation sceen frame 0 is acting different to the others. May be a programmer was not sure if starting with 0 or 1 in the program loops.

But otherwise it's somewhat funny that this flaw is existing with yrot and not with the translation channels. That's very strange.

Will not check this at the moment cause the walk designer in P6 is soooo slow. While waiting for it the whole testing is done in P7. P7 is really lot's quicker than P6.

Cheers,
Jo