This object (see illustration) is made of two actor chains:
  - the grey blocks (g1, g2, g3, tip) are the FK chain. Those are to be used for posing via FK.
  - the rings (p1, p2, p3, ptip, target) are an IK chain, so that the ring around block g1 is named p1, etc., with ptip being the IK target. Only the IK target (red ring ptip) is meant to be posed for IK. In a "real" figure, the blue things would not have any geometry. They are just used to illustrate.
  - IK in the "Figure->Use Inverse Kinematics" menu is to stay enabled.

These two chains are linked via PointAt in such a way that g1 points at p2, g2, points at p3, ..., and tip points at target. So with the PointAt active, the blocks will have exactly the same direction as the rings. When the PointAt is not active (you can tamper with the influence of the PointAt with a dial),, the blocks can be manipulated freely with FK. Effectively this means that with the PointAt influences at 1 the blocks are controlled by IK, with the influence at 0 the blocks are controlled by FK, giving a kind of FK/IK switch that even can be animated.

• Start with the first IK frame (11). Dial the PointAts to 1, and by manipulating the IK target (red ring), put the chain into place. Disable the PointAts and fiddle with the FK controls (xyz rotations) until the blocks have the same positions as with PointAt turned on.
• Do the same for the first FK frame after the IK frames (21)
  (- in the remaining frames 1-10 and 21-30 you can do with the FK whatever you want, in the frames 11-20 you can do with the IK whatever you want).
• make sure that in the frames 11-20 the PointAts stay enabled, either by setting keys, or by using a constant in the animation palette.

There are some very nasty limitations, however:

  - There is no easy way to capture the angle of the actors with the PointAt, so when switching off the IK in mid animation, the FK angles have to be made to match the IK position manually.
  - For the same reason, with PointAt active, you cannot have dependent parameters for the blocks. In particular, you cannot use JCMs so this method is practically not usable for bending figures, only for discrete parts (like robots). Just like it would be with IK alone.
  - In theory it could be used to seamlessly blend between IK and FK by using a PointAt influence somewhere between 0 and 1, but because PointAt is based on position and not on angle, the interpolation normally does not look good.
  - I tried to make a master dial on the BODY to drive all the blocks' PointAt influences with one dial, but for some reasons it does not work when saving and loading the object again, but it could be my mistake.
  - Apparently the PointAt influences cannot be saved in a pose file; they are just left out. I am not sure if this is Poser's fault or the library manager's (i used Dimension3d's XL). But saving as a scene (pz3) seems to work.

I feel realy dumb asking this question - All together now "the only dumb question is the one you don't..." - but what is "FK"? It's not a term I have heard before.

Quote - I tried to make a master dial on the BODY to drive all the blocks' PointAt influences with one dial, but for some reasons it does not work when saving and loading the object again, but it could be my mistake.

Your slaving code appears to use the wrong syntax, it reads: valueOpDeltaAdd BODY:3 fk_ik PointAt deltaAddDelta 1.00000 Try this instead: valueOpDeltaAdd Figure 3 BODY:3 fk_ik deltaAddDelta 1.000000 Of course the number "3" needs to match the figure number in the rest of the cr2. This should solve the ERC problem, but there may be other problems with maintaining Point At through a save and reload. I vaguely remember haveing problems myself, but it was some years ago, and I forget the details.

point at is very handy for things like hydraulic cylinders.

Quote - I feel realy dumb asking this question - All together now "the only dumb question is the one you don't..." - but what is "FK"? It's not a term I have heard before.

It stands for "Forward Kinematics". In a sense it is the opposite of IK (Inverse Kinematics). The "normal" way to pose a figure is to use FK, i.e. you modify the angle with a value dial and the computer calculates the position (of the children actors) from it; with IK the computer calculates the angle after you set the position for the IK target.

Quote - Your slaving code appears to use the wrong syntax, it reads: valueOpDeltaAdd BODY:3

fk_ik PointAt

deltaAddDelta 1.00000

Try this instead:

valueOpDeltaAdd

Figure 3

BODY:3

fk_ik

deltaAddDelta 1.000000

Of course the number "3" needs to match the figure number in the rest of the cr2. This should solve the ERC problem, but there may be other problems with maintaining Point At through a save and reload. I vaguely remember haveing problems myself, but it was some years ago, and I forget the details.

Aha, thanks for pointing that out. I will try that.

Quote - Apparently the PointAt influences cannot be saved in a pose file; they are just left out. I am not sure if this is Poser's fault or the library manager's (i used Dimension3d's XL). But saving as a scene (pz3) seems to work.

When you use 'Point At' on an actor, Poser add a channel to the actor named "pointAtParm Point At", and that all the difference you will see in a saved cr2 or pz3. The only really significant parts of the channel are its name, its 'keys' value, and the last line in the channel which specifies what to point at. The rest of the stuff in the channel is just standard stuff that you will find in any channel. As this pointAtParm channel is the only thing that Poser adds to the figure, a bit of guess work suggests it works like this. Poser looks to see if the actor has a pointAtParm channel, and if it does, what it should point at. All the rest is done internally by Poser, calculating how to do the pointing on the fly, and with nothing saved back to the figure. The only things specific to pointing at, that you can put in a pose file, are the 'keys' value and the name of the 'pointAtTarget'. PointAt influences themselves (rotation values) can't be saved to a pose because they are calculated on the fly, being only stored in volatile memory, and not written into any saved file.

FK will work fine in Poser if you add bones that point in the right direction, and add an FK object to it as well. Similar to helper bones in various WM characters. This will also get around the save problem because the FK object data will get saved in the pose and with the character as well. You can use point at or constraints, or a combination of both.

Constraints seem to be the better way to go.

As for the saving of point at influences in a pose - nope, it doesn't save. It has to be saved in the CR2 in Poser or the DUF / DSA in DAZ Studio.

Point at will not save, but constraints do.