Hi,

 I'm an experienced user and I've run into a weird problem. My saved camera poses do not match between Poser versions. In my case, I saved camera poses in Poser 7, which work fine in Poser 7 when loaded, but when I load the camera pose on the exact same scene in Poser 2010 it is WAY off.

 The workspace window is the same size. Everything is the same, so I've wondering what's going on? I'm a pose seller and like to add camera poses to match certain poses , so this is a big problem for me if the camera poses aren't working for some of my customers. :/

Any help would be much appreciated, thanks!

How is it possible the workspace window is the same size? In the new UI, that is not preserved.

I sized the viewspace to 600x600 in both Posers. But either way, the camera is way off. For example one is a closeup of the face in Poser 7, and in Poser 2010 it's pointed at the ground near the feet.

could you post the camera pose file ?

Sure, I've included the pose (For V4) and matching camera file. Please note the pose is erotica themed.

http://www.easy-share.com/1915316184/LionMGCameraHelp.rar

 If someone could test it in a Poser version older than Poser 7 and see if it works I'd really appreciate it.

 Also has anyone tried saving a camera pose in an older version of Poser and then using it in Poser 2010?

 Thanks!

Just had a look at your cm2 and did  a test of saving cm2 from Poser 7 and PoserPro 2010...

It is one line in every channel that's causing all this trouble...

rotateY yaw
*   {*
*   keys*
*    {*
*    k  0  -76*
*    }*
*   staticValue 323*
*   }*

As you can see, staticValue (323) is different from the k statement (0 -76).
This line gets created when saving the cm2 from Poser 7, and Poser 7 reads this line,
when loading the cm2.
PoserPro reads the k statement and ignores the staticValue.

When saving a cm2 from within PoserPro2010 no staticValue line is written to the cm2 and the cm2 loads fine in Poser 7 and Pro2010...

Usually, staticValue is identical with the second value of the k statement...
at least for pose files...

The why and how is a question for SmithMicro, or someone who knows more about Poser's inner workings than me :-)

AHA! I never thought it was Poser 7 causing the trouble.. I was fixated on fixing the problem in Poser 2010 instead of trying what you did. Woops! I even spent an hour going through the Poser 7 .cm2 with a text editor and it was driving me crazy. 

I'll just create the camera poses in Poser 2010 now. Thank you very much!!!! :)

Good sluthing msg24_7!

Quote - Good sluthing msg24_7!

Thanks...

I am still trying to figure out, why Poser7 is doing what it's doing... no luck :(

I've noticed, that Poser 7 is writing the staticValue line (with different values from the k statement) for:

• MAIN_CAMERA
• POSE_CAMERA
• RIGHT_CAMERA
• FACE_CAMERA
• LHAND_CAMERA
• RHAND_CAMERA

So, Poser does not write the staticValue to the other camera types.
Funny thing is, Poser does not write a staticValue to SIDE_CAMERA (which is the Left Cam), but to RIGHT_CAMERA... weird...

PoserPro2010 writes a staticValue to POSE, FACE, RHAND and LHAND cameras, but the value is identical to the k statement...
This makes sense, since all these cameras are connected to a figures BODY(part).

This may be related to a problem I found when using some of 3DC's stuff in Poser 6.  That's to say, the cameras don't work as intended in P6.  Now, I know 3DC's products aren't designed to work with P6 but they're just too good to pass over.  Shame about the cameras, though.

If there's a workaround I'd love to hear of it.

Quote - This may be related to a problem I found when using some of 3DC's stuff in Poser 6.  That's to say, the cameras don't work as intended in P6.  Now, I know 3DC's products aren't designed to work with P6 but they're just too good to pass over.  Shame about the cameras, though.

If there's a workaround I'd love to hear of it.

I don't have any of 3DC's stuff, so it's a little guess work... If 3DC's files are settings for MAIN_CAMERA, then you can open the cm2 with a text-editor and delete all lines beginning with staticValue.

Just save under a different name, or make a back-up of the original cm2 files!

As it happens, the settings use a Dolly camera accessed by a "create new camera" option which ain't present in P6.

Quote - As it happens, the settings use a Dolly camera accessed by a "create new camera" option which ain't present in P6.

You may get them to work in Poser 6 by doing some editing of the cm2 files.

At the beginning of the file change number X to *number 6 (*this is not fundamental, but keeps Poser from showing the version number error)

Change the line *camera Dolly Camera *to camera STD_CAMERA

At the end of the cm2 file you have a line "userCreated 1" (or userCreated 0). Delete that line.

Finally change the last line to read ***useCamera STD_CAMERA

***These changes should make the user created dolly cams usable in Poser 6 and/or 5.

Nice discovery. I rarely use preset camera's so who knows when I would have run up against this.

Thanks for the tip.  Like Steve, I don't generally use preset cams but with some of the sets I have it's a pain in the nether regions to move the cameras around.

I did a few tests in P6. In P6, with regard to the Main or Aux camera (and probably the others), if you save a cm2 with camera Animating turned off, P6 does not write 'staticValue' lines for of the channels. If you save it with Animating turned on, it does write those lines. Also, whilst Animating is turned on, moving the camera will alter the staticValue, but not the k value. This explains how the static staticValue can be different from the k value. Whilst Animating is on, it is also the staticValue that will be displayed on the dials. If you move the camera whilst Animating is on, then turn it off, the camera will revert to k value position, its position at the time Animating was turned on.

Now how about applying cm2 poses? If the pose was saved whilst Animating was turned on, it works differently depending on whether Animating is turned on or off at the time the pose is applied. In P6, if you apply a cm2 whilst Animating is turned on, the camera will be set to the staticValues in the cm2 file, if it is applied whilst Animating is turned off, the camera will be set to the k values.

I'm wondering if P7, works the same. Perhaps the staticValue lines are a function of whether Animating was on or off at the time the file was saved, and not a function of the Poser version after all? Just a thought. I don't have P7 to check this.

If that is the case, the solution is probably to make sure Animating is turned off before you save any cm2 pose. A pose saved with Animating off, will unconditionally set the camera to the k values, irrespective of the state of the Animating switch.

For poses already saved whilst Animating was turned on, apart from making sure animating is turned on before you apply the pose, you may have no better option than to edit the cm2 files in a cr2 editor, transferring the staticValue to the k value line. There is a certain amount of supposition here, I could be wrong, P7 or later may work differently, but my hunch is that they do not, and that what you are getting is a result of the poses being saved whilst Animating is turned on, but applied whilst it is turned off.

Just did a short test in Poser 7.

-Delete preferredState.pz3 (basically back to factory default)
-Start Poser 7 - all cams are set to animating, except for Pose, Face, LHand and RHand cams
-Select MainCamera and change all tran and rot values
-save MainCamera to library
NO staticValue lines !!

Now, I repeated the above steps, but deactivated "Animating" prior to changing the values
Poser 7 writes staticValue lines!

For the final test, I created a new scene, left all cams at their default settings and saved to library without selecting a subset.
So, this file contains all cams, showing staticValue for Pose, Face and R/LHand cams.

So it looks like Poser 7 does not behave like Poser 6. More like the opposite!

PoserPro 2010 behaves like Poser 7...

staticValue lines written, when Animating is turned OFF for the respective camera.

Quote - So it looks like Poser 7 does not behave like Poser 6. More like the opposite!

That's interesting, surprising, and probably bad!

So the cm2 files for P7 always save the staticValue. What about applying the poses? Say you rotate the camera 90 degrees right with the Animating switch off, then turn Animating on, rotate 90 degrees left, then save a pose. Does it make any difference if the Animating is turned on or off when you apply the pose? And if it makes no difference, is it the k value or the staticValue that is being applied?

Quote - So the cm2 files for P7 always save the staticValue.

If animating for the camera is set to OFF, but it is ON by default for all cams
(except the figure related like pose, face and hand cams). I did the test suggested...

Main_Cam set to animating off, set yrot to -90, turn animating on, set yrot to 90, save cam (while animating is still set to on!)
No staticValue line and k value is at 90 (last value entered)

Now I turn off animating and save again.
A staticValue line is written with value 90, identical to k value.

If I turn animating off, set to -90, turn animating on, set to 90, turn animating off and save, I get staticValue 90, k value -90

Quote - Main_Cam set to animating off, set yrot to -90, turn animating on, set yrot to 90, save cam (while animating is still set to on!)
No staticValue line and k value is at 90 (last value entered)

Thanks msg24_7. So in P7, if you don't want to record the staticValue, you turn Animating on. Where as in P6 it is the other way round. Strange, I haven't quite got my head around which way is best, I suppose they must have had a reason for changing it, but it certainly is inconvenient to have to have a pose that works differently in different versions. And there is still the question of what exactly is Poser 2010 doing differently from P7 when it applies a cm2? My assumptions have not been working well lately, but I assume that if you save a pose from P7 whilst Animating is turned "On", thus only saving the k values, then 2010 has no choice but to apply that one set of values.

I am still trying to figure out, what the staticValue line is for...
It really doesn't make any sense to me.
I position my camera and want to save for later use to my cam library.
I want Poser to apply the settings used when adding the cm2 to the library.
Poser does that, but only when the camera is set to animating.
If animating is off, Poser writes a staticValue (with values prior to my changes)
and applies those.

When saving a cm2 for more than one frame, Poser writes k values and spline indicators and no staticValues as long as animating is on when saving.
If you turn animating off prior to saving the cm2, Poser 7 writes staticValue, using the last k line's value.

When applying the 30 frame preset to a cam that's set to animting, everything is fine.
If you apply the same cm2 to a cam that is not set to animating, Poser reads the staticValue (which is the cam position from your last frame).
The moment you change this camera to animating, Poser changes to the values from the first k line and plays your original animation.
Still, this doesn't help to understand why one would need staticValue...

To sum it up, in order to avoid any staticValue statements in your cm2, make sure your camera is set to animating when adding the cm2 to the library.
Even if it is not an animated camera.

Oh... and all my tests were done with no figure present!
Who knows, what might happen with a figure in the scene.

Quote - I am still trying to figure out, what the staticValue line is for...

I think I can answer that one. It just means that the camera (or what ever it is) will not change when you run the animation. Say you have a 30 frame animation and want the camera to stay still throughout the whole animation, you set Animating off for the camera. Now say you are at frame 7, and you decide that you want to tweak the camera position a bit. With Animating turned off, the  position you set in frame 7 will now be the position of the camera in all frames of the animation. That position (and focal length, and whatever) will be used throuout the whole animation, and it will be stored as the staticValue in each channel.

Any Poser channel can be set as static by the application of a pose file (static 1), xRot in the left collar, what ever, but only lights and cameras have a way to turn it on or off via controls in the interface.

In P6 I normally have all my cameras set to 'static 1' (Animating off), and only use 'static 0' (Animating on) if I am doing an animation where the camera needs to pan as part of the animation. In P7 it sounds like it may be a better idea to have Animating on by default. In P6 you can edit a cm2 file to include the static statemnts ('static 0' or 'static 1') in each channel, so that applying the pose also sets the Animating status of the camera, this probably also works in later versions. Setting 'static 0' in the cm2 is, at least in P6, a way to force Poser to use the k value.

Sorry, I did not explain that very well. I said "It just means that the camera (or what ever it is) will not change when you run the animation.". That statement is wrong. staticValue is just a stored value, it does not in and of itself make the camera static or animated. It is the state of 'static' switch ('static 0' or 'static 1') that determins wether the staticValue is used.

{
#Animating on
version
    {
    number 4.01
    }

clearFigureKeys 1

camera MAIN_CAMERA
    {
    channels
        {
        rotateY yaw
            {
            keys
                {
                static  0
                k  0  45
                sl  1
                spl
                sm
                }
            staticValue 90
            }
        }
    cameraModel poser
    }

doc
    {
    useCamera MAIN_CAMERA
    }
}

As this pose only affects one channel it could leave rotateY in a diffrent state to the other channels in the main Camera. So you may need to start a new scene after using it to be sure your camera is returned to its normal state.

{
#Animating off
version
    {
    number 4.01
    }

clearFigureKeys 1

camera MAIN_CAMERA
    {
    channels
        {
        rotateY yaw
            {
            keys
                {
                static  1
                k  0  -45
                sl  1
                spl
                sm
                }
            staticValue -90
            }
        }
    cameraModel poser
    }

doc
    {
    useCamera MAIN_CAMERA
    }
}

As this pose only affects one channel it could leave rotateY in a different state to the other channels in the main Camera. So you may need to to start a new scene after using it to be sure your camera is returned to its normal state.

Thanky for those examples... I am going to try to get my head around it...

But first I have another question...
What is the clearFigureKeys 1 line doing?
I have noticed this in other cm2 files, but never in any I saved from Poser 7 or PP2010.

To late to edit my previous post...

Just realised, that it refers to the number of frames when saving animated cams/poses.

I did apply your camera presets in PP2010.
Both do, what they are supposed to do.

In combination with static 1 or static 0 everything makes much more sense.
Contrary to a cm2 written by Poser you can force animating to be on or off,
and the camera behaves as intended. No matter the users settings (animating on/off).

That's good to know!

Quote - What is the clearFigureKeys 1 line doing?

To late to edit my previous post... Just realised, that it refers to the number of frames when saving animated cams/poses.

That's right. More specifically, it will add the number of frames required by the pose to the animation if they do not already exist. Say you have a 20 frame animation and a pose file with "clearFigureKeys 20", if you apply that pose in frame 10 of the animation, the animation will expand to 29 frames to accommodate all the frames in the pose. Poser will prompt you for confirmation before adding the frames.

Re adding the 'static' switch to cm2 files. If you have a text editor that can 'Search & Replace' multiple lines at once (I use EditPad Lite), you can use this trick to process all the channels in a file, or even multiple files, at one time.

Set the search string to:

            keys
                {

Then set the replace string to:

            keys
                {
                static  0

You need to copy the search string directly from a Poser file, to make sure the indenting is correct, Rosity will have changed the formatting in the above examples. Doing the above will add the static switch to all channels in the file. Of course you can also use 'static  1' in the replace string.

One word of caution. Some people (especially animators) might not appreciate a cm2 changing the static switch on the camera, as this is not normally to be expected. Any files for distribution should clearly state in the readme that the file does this.

Quote -
That's right. More specifically, it will add the number of frames required by the pose to the animation if they do not already exist. Say you have a 20 frame animation and a pose file with "clearFigureKeys 20", if you apply that pose in frame 10 of the animation, the animation will expand to 29 frames to accommodate all the frames in the pose. Poser will prompt you for confirmation before adding the frames.

I think the "clear" got me confused... sounds more like removing than adding.

Quote - Re adding the 'static' switch to cm2 files. If you have a text editor that can 'Search & Replace' multiple lines at once (I use EditPad Lite), you can use this trick to process all the channels in a file, or even multiple files, at one time.

Set the search string to:

            keys
                {

Then set the replace string to:

            keys
                {
                static  0

You need to copy the search string directly from a Poser file, to make sure the indenting is correct, Rosity will have changed the formatting in the above examples. Doing the above will add the static switch to all channels in the file. Of course you can also use 'static  1' in the replace string.

One word of caution. Some people (especially animators) might not appreciate a cm2 changing the static switch on the camera, as this is not normally to be expected. Any files for distribution should clearly state in the readme that the file does this.

I use TextPad for most edditing, but may retire it in favor of PhilC's PoserFileEditor soon.

I think you are right about distributing files including the static switch.
Those files should be saved according to Poser's default, which is animating on for most cams.
One may include the static switch when using user created cameras in Poser 7 and up.