I've been trying to figure out what's going on inside certain Poser files, in particular .pz2 files, and in even more particular the .pz2 files that inject body morphs into V4. The first thing I noticed is that different vendors take vastly different approaches to creating their characters. That's one question, but I'll get to it later. First I want to look at the injection pose file for FRAD's Jessie called !!!Jessie INJ.pz2, and its sister !!!Jessie REM.pz2.

It starts off with 33 readScript commands like this:

    readScript ":Runtime:libraries:!DAZ:Victoria 4:Deltas:Morphs++:InjDeltas.FBMBodyBuilder.pz2"
    readScript ":Runtime:libraries:!DAZ:Victoria 4:Deltas:Morphs++:InjDeltas.FBMDefinition.pz2"
    readScript ":Runtime:libraries:!DAZ:Victoria 4:Deltas:Morphs++:InjDeltas.FBMFitness.pz2"
    ...

These call DAZ scripts that are just other .pz2 files, and these scripts load the morph targets that Jessie will be using. (I think I'm using the terminology right.)

The next thing are 33 valueParms for the BODY actor which correspond exactly to the 33 readScript lines. These basically turn the dials to the settings that make Jessie look like Jessie. Like this:

actor BODY { channels {
    valueParm FBMBodyBuilder            { keys { k 0 0.1 } }
    valueParm FBMDefinition             { keys { k 0 0.3 } }
    valueParm FBMFitness                { keys { k 0 0.5 } }
    ...

(I've taken some liberties with the formatting to get things on one line.)

So far, so good. Next comes "dial turning" for specific body parts like hip, abdomen, rCollar, rHand, etc. Here is the one for hip:

actor hip { channels {
    targetGeom PBMHipsCrest            { keys { k 0 -0.3 } }
    targetGeom PBMHipsSize             { keys { k 0 0.3 } }
    targetGeom PBMGenitalCrease        { keys { k 0 0.8 } }
    targetGeom PBMGluteCreaseR         { keys { k 0 0.1 } }
    targetGeom PBMGluteCreaseL         { keys { k 0 0.1 } }
    targetGeom PBMGlutesDimpleDepth    { keys { k 0 0.2 } }
    targetGeom PBMCC_50                { keys { k 0 0,  k 0 1,  k 0 1 } } } }

Notice that now you are setting targetGeoms instead of valueParms, and notice that the last one is PBMCC_50 and that the key settings are not like the rest. PBMCC_50 is always the last one for each of the specific body part actors except for three - the neck which is PBMCC_70 and rHand and lHand which don't have a PBMCC_ target.

Finally there are 13 settings for the actor bodyMorphs:

actor bodyMorphs { channels {
    targetGeom FBMBodyBuilder          { keys { k 0 0.1 } }
    targetGeom FBMDefinition           { keys { k 0 0.5 } }
    targetGeom FBMFitness              { keys { k 0 0.5 } }
    targetGeom FBMYoung                { keys { k 0 0.2 } }
    targetGeom FBMVoluptuous           { keys { k 0 0.1 } }
    targetGeom PBMArmSize              { keys { k 0 0.2 } }
    targetGeom PBMBicepsFlex           { keys { k 0 0.3 } }
    targetGeom PBMForearmsThickness    { keys { k 0 0.1 } }
    targetGeom PBMTorsoThickness       { keys { k 0 -0.3 } }
    targetGeom PBMThighsTone           { keys { k 0 0.2 } }
    targetGeom PBMShinsThickness       { keys { k 0 0.2 } }
    targetGeom PBMFeetArch             { keys { k 0 0.5 } }
    targetGeom PBMFeetForShoe          { keys { k 0 0.8 } } } } }

Each of these targetGeoms corresponds to one of the 33 readScripts and valueParms for the BODY actor, but that leaves 20 that aren't covered. Furthermore most of the 13 key settings match up with their corresponding BODY settings, but not always. E.g., for FBMDefinition the bodyMorph key is set to {k 0 0.5} while for BODY the key is set to {Key 0 0.3}. 

OK, now for the questions.

1. What's the difference between valueParm and targetGeom?

2. What's up with the PBMCC_50 stuff?

3. What's up with the bodyMorphs actor? Why are some of the targets for the BODY actor left out? Why do some of the keys not match up?

Well, that's enough for now. I'll save the other questions for another thread.

Q: 1. What's the difference between valueParm and targetGeom?

A: A valueParm (FBM) channel is a control channel, its only function is to output a value that can be read as input by other channels, is not a morph in the usual since as it does not contain any deltas. The targetGeom channels are morph channels the do (usually) contain deltas, the deltas are the actual morph. A targetGeom channel can be slaved to a valueParm with slaving code so that the channel gets an input from another channel, this is known as ERC. A number of targetGeom channels in different actors may all be slaved to one valueParm channel in the BODY actor. Collectively that is known as an FBM (Full Body Morph). So valueParm are control channels, and targetGeom are morph channels.

Q: 2. What's up with the PBMCC_50 stuff?

A: I'm not sure exactly what you want to know about it. The PBMCC channels are blank (no deltas) channels that third party morphs can be injected into. PBMCC stands for Partial Body Morph Community Channel.

I'll have to think for a few minutes about how I might be able to answer your third question.

Les beat me !

The Body actor has no geometry of its own , its simply a set of controls for other body parts.

Every body part has 50 PBMCC and 50 PBMDC channels. The DC is for DAZ to use and CC are community for other developers or you to use.  PBMCC_70 makes no sense , there should be only 50 channels.

The bodymorphs are setting Full body morphs. Thats sort of a control dial within BODY actor that sets morphs on each body part that combined make a full body morph. (not quite sure on that one)

 The k line is keyframes so k 0 0.5 says set this parameter to 0.5 at frame 0 , and I think its relative to the scene current frame.  If the pose was animated you would get multiple k lines, one for each keyframe.

When a channel is not in use , its dial is hidden and it will show numdeltas 0 and have no name (or rather a _ where the morph name will be )

Inj poses use an existing channel , they do not create them.

Q: 3. What's up with the bodyMorphs actor? Why are some of the targets for the BODY actor left out? Why do some of the keys not match up?

A: Back in the days of P6 and before, a pose saved from the Poser interface could not record any data for the BODY actor. As valueParm (FBM) channels live in the BODY, this meant FBM settings did not get recorded in pose files. The bodyMorphs actor was the way DAZ worked round this problem. The valueParm channels in the BODY are linked to targetGeom channels in the bodyMorphs actor via 'linkParms' statements in the 'figure' section of the cr2.

'linkParms' is a way of making a linkage between two channels. In theory, if you change the value of one of the linked channels, the other linked channel adopts the exact same value. That's what should happen in theory, the real world is not always so neat.

So the bodyMorphs actor works like this (in theory). You turn the dial of a valueParm channel in the BODY actor, a target geom channel in the bodyMorphs actor mirrors that value. When you save a pose, no data is saved for the BODY, but the mirrored data in the bodyMorphs actor is saved. When you apply the pose, the targetGeom in the bodyMorphs actor receives the value, and that value is mirrored in the valueParm channel in the BODY (via a 'linkParms' statement in the 'figure' section).

I'm not sure I have explained this in a way that is easy to understand. Perhaps someone else can explain it in better words.

I did not fully answer you question about the bodyMorphs actor. Truth is I don't know the answer to the rest of the question.

Why are some of the targets for the BODY actor left out? Why do some of the keys not match up?

Hey, Les, do you mind if I add those to the Wiki?  :)  GREAT and in-depth answers :)  (I'll totally give you full credit!)

Thanks so much for reading through all that and trying to help me understand, but I'm afraid I've still got some work to do. Is this stuff documented anywhere? Are the contents of these .pz2 files determined by DAZ, Poser or both?

I suspect some of the anomalies that I've pointed out are simply oversights or mistakes by the vendor. I'm surprised that Jessie works at all. She reminds me of some women I've known in real life - gorgeous on the outside, but on the inside she's just a mess.

Quote - Hey, Les, do you mind if I add those to the Wiki?  :)  GREAT and in-depth answers :)  (I'll totally give you full credit!)

Wiki? What Wiki?

Attached Link: http://www.renderosity.com/mod/rrwiki/index.php/Main_Page

Quote - Is this stuff documented anywhere?

The only comprehensive documentation of Poser library files that I was aware of was the "Unofficial CR2 File Specification" at "www.kuroyumes-developmentzone.com", unfortunately that resource no longer seems to exist on the site.

Quote - Are the contents of these .pz2 files determined by DAZ, Poser or both?

The language of 'Poser Script' used in Poser library files is determined by who ever owns Poser this week. The actual contents of any specific pose file are determined by the application that wrote the pose file.

Quote - I suspect some of the anomalies that I've pointed out are simply oversights or mistakes by the vendor.

I share your suspicion.

Quote - Hey, Les, do you mind if I add those to the Wiki?  :)  GREAT and in-depth answers :)  (I'll totally give you full credit!)

Please feel free to do that. In fact anyone is welcome to use anything I post in the forums, anywhere they like.

Well, I edited !!!Jessie INJ.pz2 and took out everything but the 33 readScript commands and their corresponding 33 valueParms for the BODY actor, and everything works fine. At least everything works exactly the way it did before. 

The more I look inside these Poser files, the more I realize that a lot of the peculiar behavior that I assumed was part of Poser is actually due to errors in the vendors' code files.

I know I've said it before, but I'll say it again - SM, Renderosity or somebody needs to come up with a set of standards and some kind of certification for these products.

the readscript is just a way of including the other file without actually copying it. Some files read by readscript actually have a few readscripts of their own.  Tracing Daz morph injects can be very tedious.

Each store does testing. That testing should find major faults. If it does not then customers need to complain , and get some butt kicking done on bad products.

Right. A readScript is essentially a function call in programming, and a function can call other functions, etc. It's a much, MUCH better way of coding than duplicating code in each file.You're right about another thing, too, tracing these calls is quite tedious.

Apparently Poser, much like HTML, is very forgiving of errors in its code (the contents of .pz2, cr2, etc files.) You can make all sorts of mistakes with HTML and CSS - typos in the tag names, meaningless attributes, etc. - and the browser will still display something. If you try to tweak it without going directly to the code, you can often get your page to look the way you want it, but with every tweak, the actual code gets messier and messier.

Whatever testing that was done on FRAD's Jessie, it apparently wasn't enough. Besides the inefficiencies, there were some obvious mistakes that should have been caught. In particular, there  wasn't one-to-one correspondence between the morphs in the INJ file and the REM file.

I don't mean to beat up on FRAD; they make gorgeous stuff, but I suspect they're not programmers. As a programmer myself, I'm sure if I tried to create a character, the code would be immaculate but the final output amateurish.

By the way, I've even spotted errors in the DAZ base product, Victoria 4. If you go to :Runtime:libraries:Character:! Vickie:Morph Injections:Morphs++ and load Young.pz2 you end up loading InjDeltas.PHMHeadYoung.pz2 instead of InjDeltas.FBMYoung.pz2. 

Hmmm... It looks like I may just be talking to myself at this point. That's OK. I'm used to it.

Anyway. So now I'm looking at the INJ and REM code for Rebel Mommy's Sash character: "!! RM SashB-INJ.PZ2" and "!! RM SashB-REM.PZ2". These files were created by 3D Universe Injection Magic as were FRAD's (I think), so they are similar in approach.

The RM code is much cleaner with a one-to-one correspondence between each morph that is injected and each one removed. Also all the key settings are consistent, e.g., when PBMWaistWidth is set to -0.1720000 in the BODY actor, it is also set to -0.1720000 in the abdomen actor. But even so that brings up the question again of why it is set in two places anyway.

I tested two approaches to removing the duplication. In one file I took out all the settings for the BODY actor while leaving the settings for the hip, abdomen, chest and bodyMorphs actors. In the other I only used the setting for the BODY actor and deleted all the rest.

I then loaded three Vickies and applied one of the three injection files to each one. The results were that each Vickie looked and behaved exactly like the others. So whatever reason there may be for the duplicate settings, it apparently has nothing to do with the results.

The abdomen's WaistWidth is linkParmed to the BODY WaistWidth, so they should be the same always. But the WaistWidth does not only alter the abdomen, but e.g. the hip, too. So one method to get the WaistWidth into the hip, is to put a child morph for the WaistWidth in the hip, this is what they did (abdomen linked to BODY, and hip child of BODY). They could have made the hip a child of the abdomen (for this morph), but if they would do something like this for every morph, nobody would understand the interdependence of the various morphs anymore. An alternative would be to only make a full body morph for the waist width (in the BODY), and make the abdomen's morph a child of it, but then you wouldnt find the WaistWidth within the abdomen (this is where everybody would expect it to be anyway). So the general strategy seems to be: Put the main dial into the body part where it you would look for it, copy the value up into the BODY, and then let other children depend on the this. Perhaps not the best way to do it, but at least not too complicated.

While all that makes sense, it doesn't seem to be influenced by the either of the three approachs I've taken to add Sash's morphs to Vickie. I can set the value in one place only or I can duplicate the settings. Either way the WaistWidth dial appears in the BODY actor like this:

    Morphs|Shapes --> Morphs++ --> Lower Torso--> WaistWidth = 1.00

and in the Abdomen actor like this:

    Morphs|Shapes --> Morphs++ --> WaistWidth = 1.00

which is what I would expect.