Actually even if you read the manual from start to finish, you still won't know what the purpose of Andy is. He's hardly mentioned at all.

Quote - Erm...why wouldn't you read a manual for program you don't know how to use?

???

Laurie

From start to finish? Are you kidding?

3D graphics programs are complicated; there's no getting around that. But the learning curve for Poser is unnecessarily handicapped by many usability factors that could so easily have been avoided or corrected. You shouldn't have to read the manual from start to finish to answer a question that almost everyone who starts up Poser for the first time asks, "Who's this Andy guy, and what am I supposed to do with him?"

One of the annoying features about both Poser and Daz is that they give you all this content but never tell you what the heck you're supposed to do with it.

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.

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.

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. 

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.

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.

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?

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.

Thanks, millighost. My first reaction to your post was, "That cannot possibly be right!" but apparently it is. This is from the Poser Manual:

• File Search: When an object is loaded from the Library, Poser searches for all the associated files included with that object. The File Search options allow you to configure the extent of that search. These options are:

• None..: Selecting None disables file searching; this option is useful for testing the accuracy of newly developed content.

• Shallow.: Selecting Shallow will reduce the amount of time spent searching for missing or mislabeled files, but will increase the instances of files not found.

• Deep.: This is the default File Search setting. We recommend that you select Deep file searching, as this option initiates the most extensive searches for content file components, hence increasing the likelihood that missing or mislabeled files will be found.

That doesn't really tell you much, but my tests pretty well confirm what you said, and I have to say - What a terrible, terrible idea. What were the developers thinking? Good lord, no wonder Poser is so slow. You have to wonder how many other bone-headed, inefficient, useless "features" are built into the code. Forgive me for ranting but ~!@#$%^&*()+!!!!

Even when I set "File Search" to "None" it still seems to go looking for the file outside of what is stated in the referring object.

Also, I'm not sure what you are saying with, "Most commercial objects for poser contain texture references like this.", e.g., "C:BRuntimeTexturesB.png". All the references I've seen are in the form of:

":Runtime:Textures:::"

None have the device name , e.g., "C:" appended.

 **
**

Quote - not sure why you are looking here, it is a SmithMicro product. 

Ha! Well, for one thing it's hard to keep track of who's who. From what I can tell, most of us use Poser (Smithy Micro) as our 3D tool, our base figures come from DAZ, and our content we get from Renderosity.

Still, this is the best place to ask these types of questions.

When I was first working with Poser and trying to figure out their library (dis)organization, I was struck by how many people took a vendor-centric approach to their runtimes. My feeling was that if I wanted an evening dress I would look for evening dresses regardless of the vendor. Having done this for a while I'm beginning to gravitate to the vendor-centric approach myself.

So not only will it be impossible to please everyone with a single standard, you're not even going to be able to please the same individual as their style evolves. Still, that's OK. Any standard is better than no standard.

However, one of the considerations to any proposed standard should be ease of reorganization.

Quote -

That's the most sensible suggestion I've seen in this whole thread!!! If this were Facebook I'd have clicked on the Like link!

Really?! Because that's what I've been advocating from the get go. I guess I haven't been very clear. Maybe "certification" was the wrong word; it was one I borrowed from MicroSoft.

As obm890 rightly states, the core of all of this is nothing more than a clearly defined set of standards, guidelines, conventions - whatever you want to call them.

When I was doing programming work, the better run shops all had some set of standards regarding coding, naming conventions etc. While these standards were never entirely satisfactory to everyone, everyone agreed that any standard was better than no standard at all, but that's what we have right now with Poser - no standards. To say that merchants are free to come up with their own standards is a little misleading. It would be more accurate to say that they are obligated to come up with their own standards. I suspect that most merchants would be delighted to have a set of clearly defined standards to follow.

Earlier today I was at the Dimension 3D site looking at some of the tools they have there, and I realized that almost everything we have been talking about on this thread could be automated, and in fact probably has been automated. See, e.g., the Poser File Organizer and the Runtime Repair tools. So what I'm suggesting is very simple and very easy to follow and very easy to check. The hard part will be in putting the list together.

As I said earlier, it would be nice if SM or Renderocity took the lead with this, but, really, anyone could do it. Remember - any standard is better than no standard at all. No matter what the standards are, there will be those who will object and often they will have very valid reasons for their objections. That's just the nature of the beast. Of course, users could still reorganize and rename everything to their hearts' content.