Has anyone seen or developed a script that will: 1) identify all the files (and paths) associated with a pz3 (i.e., texture, geometry, etc.) AND 2) copy them all to a clean runtime (using a project's name for example) AND 3) rewrite the pz3 using the new project's path? Since I try to keep my harddrive relatively clean, I load and unload what I need. This utility would make it possible for me to quickly recover a project and all it's associated files if I ever want/need to rework it at a later time. Paul

Interesting idea. I've been using the same form of organization manually, because I keep my serious work by PZ3s. I'll see if the "extractor" script can be extended to do this. It would help you and me both! Would you want all the files in the same folder with the PZ3, or do you want a hierarchy like this...... XYZFolder --XYZ.PZ3 --XYZReflections ----[reflection maps] --XYZTextures ----[texture maps] --XYZBumps ----[bumpmaps] --XYZObjects ----[obj files]

Thanks ockham! Good question. Either way would work as long as the rewritten pz3 points to the correct path. For simplicity, all files in the same folder would work but in the back of my mind I keep wondering if something that replicates the runtime scheme would be useful ... but can't for the life of me think when I might need that.

I'd rather have all files in one folder, too. So that's how I'll build it.

That will rock!

oh! I was wondering about this a little while ago since I use Poser for exporting figures to trueSpace I need a similar function, so I can put the exported OBJ with textures used in one folder. could this be combined into the script as well? Kai

Do you mean just the OBJ itself plus all textures it uses? Do you need this to be pulled out of a CR2 or PZ3, or just start with the name of the OBJ?

Starting to think about this. It will be simpler if the source PZ3's are required to be somewhere inside the Runtime of the presently active Poser. Is that a reasonable restriction, or does it need to be looser?

I could live with that.

for me, having all the textures with the OBJ would be ideal.. or even just being able to place all the textures in 1 folder then I just save the OBJ there would work lol the TSX (Luuv) relies on having the textures in the folder with the OBJ to seamlessly import the figure.. else it's the old hunt and repaint.. and the way that textures are listed / named / placed with poser.. it's a nightmare at times.

Kai, Just wondering since I haven't used trueSpace. Are you exporting/importing a single obj from a pz3 or the entire contents of a scene? ockham, Will you be able to do this with P5's linked runtimes? I'm thinking that may have been part of the reason for your previous question. Paul

On the runtimes: After a bit of testing, I take back that restriction. I was thinking about portability and absolute filenames, but that's not a problem for PZ3. (I think it is a problem with texture references in CR2 and PP2, which is what was confusing me.) In a PZ3, texture files that reside in the same directory with the PZ3 can just be written as plain filenames, no folder or path needed. So a project folder that contains all necessary parts will be completely portable.

Pablos, it can be both depending on the project...

How's it coming along ockham? Just thought I'd poke my head in here so you wouldn't think I didn't care any more. :-)

Don't worry; I want this one as well, so I'll definitely get it done! But it does help to know that you're still thinking about it.

Thanks ockham! Having not done programming in a l-o-n-g while (visions of punch cards ... FORTRAN!) and haven't really studied Python, I don't have a good handle on just how difficult this might be ... but I can be patient.

Yes, I remember Fortran too! Handing in a batch of cards, waiting 3 days to find out that it doesn't work, debugging, waiting another 3 days, hoping my account will be able to pay for the CPU time.... That was no fun, and I gave up on programming until the PC came along. Lord, how things have changed. I'm in the middle of working on this, and bumped into a decision point related to OBJ files. An OBJ that was contained in the original prop or figure will be incorporated inline in the PZ3, so it will get carried over just by copying the PZ3. But with standard props and figures (Posette, Vicky, Mike) the OBJs are simply listed as external references. When the PZ3 is copied into its own folder, should it also make a copy of these monster files, or should we assume that the location written in the PZ3 is a reliable standard location? The former would guarantee that everything, standard or otherwise, will be found by the PZ3. The latter would save disk space. It would seem that there is a middle option, copying only non-standard OBJ files and assuming the standard ones can be found in their proper place. But that's not practical because there's no mechanical way to distinguish between the names of standard and custom files. DAZ and CL do use certain patterns in their names, but a custom OBJ could just as easily begin with "P4" or "blMil".

ockham, I see your point. I originally envisioned copying all external reference objs to the "project" folder. In that way, I would never have to worry about it (and they compress well anyway). However, other users might not want to do that. How hard would it be to query the user as to whether they wanted to copy external objs (standard and/or non-standard) or leave 'em where they are?

Good idea. I'll make that a choice. For my own purposes I like everything neatly bundled up, same as your preference.

"...I like everything neatly bundled up, same as your preference." Maybe it's an Oklahoma thing. :-)

Hey ockham. How's this thing going? Was wondering if the query option gave this thing any trouble.