If I remember right you have to send it to Daz, then save it out from there.

I just noticed the same problem, too.  Tried wiping and reinstalling Poser to no effect, the realized it only gave me problems when Adobe items were running, and traced it to Chrome.  Thanks for the tip, Ikendall, I'll check out that browser.

Quote - You can use the cpu-z program I posted a link to and find out what your memory is running at. It works for intel and amd.

I'm running a 1:1 ratio on the bus and memory.  400 on the bus and 800 on the memory. Timings are pretty loose at 5:5:5:15. I was running it at 1066 with the same timings but got intermittent crashes about once a month. Tried 5:5:5:18 and still wasnt stable.  My multiplier is set at 9. The memory is rated at 4:4:4:12 800mhz.

 My DRAM Freq is 680 MHz, with a 3:8 multi (255 MHz Frontside bus).  Timings are 7:7:7:24, but DDR3 doesn't have as good a latency as DDR2.

Quote - I'm using the p5q pro turbo motherboard and for quads it doesnt like to go over 460 on the bus.

Mine gets cranky over 260.  And yet somehow I had it running at 275 for a few weeks just fine, I just can't remember now how I did it lol.

Quote - Tomorrow I will get the q6600 up to 4ghz and tighten the timings for the memory, then run the benchmark. I've had it up to 4.1ghz but vcore was getting kindof high along with temps. I'm using the cm v6gt for cooling but it still likes to run hot

Remember the Q6600 is the older 65nm technology instead of the 45nm for newer 775 socket cpus.

For some reason I was thinking mine was 65nm too, but it's 45nm.  Maybe that's the difference.

Quote - Nice numbers and thats a good deal. I paid $100 used for my Q6600.

I'm sure that DDR3 helps a bit too. what speed is it?

I can't for the life of me remember what speed it is, 10666 or 13333.  Regardless, I have it running at 1460 MHz since I had to crank the CPU frequency up so high (locked multiplier). Since the RAM freq is lower than stock I decreased my latency timings to compensate.  I'm using the OCZ memory and it is junk, won't go over 1600 MHz for anything and I think it is not very stable.

I am VERY surprised I was able to beat your times, since we are clock-for-clock.  The Q6600 was a better CPU than mine IMO, it was the competitor to the Phenom IIs.  What do your RAM settings look like?  Even at DDR2 I would think that wouldn't make a big enough difference since the scene was small.  Also, I don't know what your bus frequencies are, but it may help to raise those, then lower your CPU multiplier to compensate if 3.6 is your upper limit. Sorry I can't better explain what I'm talking about, I don't have as much experience overclocking Intels as I do AMD.

Maybe I should bring AMD into the mix :)

Athlon II X4 630 OC'ed to 3.6 GHz

8 Gb of DDR-3

Windows 7 x64

Poser Pro 2010

Low: 51s @49c

Med: 2m17s @51c

High: 5m21s @52c

I'll admit I was apprehensive about doing this with a budget processor, but considering the CPU only cost me $95 (a year ago, at a retail store even), I think I couldn't be happier with the results.

Hmm...  good point.  After I saw that I found SVDL's script to delete unused morphs and tried it out.  Took a 110 mb pz3 down to 16 mb.  After seeing that work, I put together a pz2 file from all the V4 injection poses to inject all the morphs back in, it worked perfectly.  Now I just need to learn python so I can do all that automatically!

Thanks Markschum.  I looked at the geomstripper; I already have that functionality with D3D's poser tools program.  I couldn't find your python script, but I'm still looking.

I think I did find something to help me answer my question.  It kind of relates to the embedded geometry.  I opened a pz3 in Notepad++ and there were deltas for all the morphs.  This was even with the base V4.2.  It seems redundant to me to have those in the scene file.  It makes more sense to me to just store the morph channel setting, ie. "Shoulder Size = 1", and inject the deltas when the scene is loaded.  I guess that is where the pmd comes in, but wouldn't it make more sense to inject the deltas from the runtime instead of storing them with the scene?  I think that is where I am heading now that I have looked at it more closely.

Quote - It saves a lot of disk space if you use compressed files.  You can always use the python script that comes with Poser to uncompress them , or to compress the entire folder.

 

Figured that out in my scripting thread, lol.  I was so pround of myself for writing a batch file to compress them, then someone pointed out the python scripts.  Time for me to get familiar with those.

Quote - Provided that the figures and props do not contain embedded geometry, the saved PZ3 file will not contain any either. Figures tend not to contain geometry data but props frequently do, you may want to concentrate on those.

Thanks Philc.  Can I assume that morphs count as embedded geometry?  The reason I ask is because I just did a test.  I saved an empty scene except for an empty V4.2, it was 14 mb.  Then I added the morph injections which brought the scene to 104 mb.  Then I saved another one with an injected, morphed, posed, and textured V4 with some morphing tool changes, and It came to 115 mb.

I know, that's the wrong spelling of there.  It won't let me edit.

Quote - Also, Poser already comes with a script for compressing files, and it works recursively on any directory you point it to. Any particular reason why you are not using that script?

Hah! Because I had no idea it was even their.  Thanks!

A couple things to note:

   - The script will NOT harm your original pz3, it only copies it and works on the copy.

   - Because of this, it is best to have at least twice the disk space available as the room your pz3s take up. (Don't worry, it will delete the working file after every cycle of the loop so things don't get out of hand)

   - The script works fine with long filenames, but will not work with folder names that have spaces in them.    I don't know why, and eventually lost patience with trying to debug it.  Just keep that in mind, and rename folders if necessary.

   - Since the original pz3 remains, it wouldn't be a bad idea to verify the new files  before you delete the old ones.  I haven't had any problems, but just thought I should say it.

   - The compression level I used seems to be around %10 better than Poser's.  I left it at 7/10 because anything higher resulted in a substancial increase in compression time, with only a minimal decrease of file size.

Hioushi, you are %100 correct.  It gave me all kinds of fits with the long folder names and renaming files from within the FOR loop.  Time for me to learn Python.

I looked at it, and agree with you on the benefits.   I want to get to the point eventually where I can write actual programs, but for the time being I'm still just  stumbling through batch files.

So the good news, I have another one.  It copies a path (or any information entered, for that matter) to the clipboard.  This one has a setup so no need to edit the script.  Just download the file and rename .txt to .bat as before.  Run it, and it will prompt you for the info it needs, first the name you want to assign to the slot, then the path for that respective slot.   After you are finished entering the information, it will create a new batch file which will be the main program.  Run it, and select whichever slot from the menu you want to copy to the clipboard.

Example:  I make a character, and want to transfer the FBM to a clothing item.  In the setup I would enter "My Characters" as the slot name, and "C:runtimeslibrariescharactermy characters" as the path.  Then I can open Morphing Clothes, copy the path with the program, and paste the path into the location bar in MC, instead of having to browse through all the folder levels to get to what I want.

Thanks Hioshi.  It did take me a while to figure out how to use changing variables in FOR loops, I think that's what you are referring to.

I have another one on the way, just need to get it ready for deployment.  I'll have it up later on today.

Quote - Hmmm. I just read your post closer.  Now I'm confused. I thought the program automatically moved things around, but I see it actually just lists the content of a folder and it's sub folders, is that correct?  If so that could be a very valuable tool.

 

Sort of.  It copies all the target file types from the targetted folder tree to a new folder, while adding the relative file path to the file name.  I did that instead of just a file list so I can visually go through my content.  And since the filename now includes the path, once I find the thumbnail of what I am looking for I will have the path in the filename, so I know where to look in my runtime.  Or I can use that path to file the file and rearrange the runtime, but I haven't gotten that far.  Been spending all my time on the scripts, lol.