PMD; A cautionary tale! (But positive result)
anomalaus last edited by anomalaus
Just about blew a head gasket a few moments ago!!!
With all the fully justified delight stemming from Project Evolution's release, I felt the need to push my own, previously self-imposed, boundaries and re-enable both file compression and binary morphs (PMD) in Poser.
I had several justifications for this, including discovering that my favoured text editor, BBEdit, was already seamlessly allowing me to view, compare and edit zip-compressed text files (which is what Poser's compressed format files are). PMD related inducements included the pain of trying to compare CR2 (CRZ) character files when one referenced binary morph targets (abstracted to a PMD file with UUID morph keys) and the other did not, and my confidence that, given I had been gifted with python code which could extract the contents of PMD files, they were no longer the inscrutable black box I had previously perceived them to be.
Cue the moment when I had transferred some morphs from a base figure to a piece of conforming clothing (which utilised binary morphs) and decided to save it back to the library, overwriting the same name I had originally loaded from. I did this with the unconscious confidence that the path to that position was fully recoverable, since I had taken the precaution of rummaging through an old saved scene and saving back to the props library some magnets which I had used to create morphs for the base figure, when it had occurred to me that the magnets might give a better result if applied directly to clothing with a different resolution to the base figure, than copying the morphs directly from said base figure (PE) which Poser has shown to be somewhat less than perfect at performing.
Anyway, Stumblebm Bggerlugs has forgotten to make sure the clothing figure is selected when saving to the library and realises they have just overwritten the previous version of the clothing with the base figure (apparently, PMD file and all)! Ohhhkaaayy, the scene's still open, let's just correct that by selecting the clothing figure and doing the save again...
[Cue Klaxons, Blitzkrieg lighting effects and robot voice-over: "Danger, Will Robinson!"]
Attempting to click OK just keeps reiterating the same dialog, Groundhog Day style!!! I can't even get to a point where I can save the scene...
WTFSaturday! "Pried goeth befoer..." etc.
Aha! Time machine has just completed a backup not 20 minutes ago. [Swiftly restores from backup the version of the clothing CRZ, PNG, XMP and PMD files which had been overwritten by the erroneous base figure save]... Now that PMD file which Poser is trying to write to actually matches the figure it's trying to save, the dialog goes away and the scene appears as before, allowing me to re-save the updated version of the clothing to the library. Whew!
So, what did I learn, apart from the error of my ways? Poser and PMD may now be foolproof, but they're still not idiot proof [Places Idiot 1st Class gold star under left eyelid], in the case of deliberate, but inadvertent sabotage corrupting files, and, frequent, automated backups are your friend.
In defence of PMD, I would have been (apart from the panic inducing dialog) in no different situation had I overwritten the OBJ file for the clothing figure by accident. The extra complexity of the PMD resource mechanism (one may not necessarily load all of the morphs it stores with a given CR2, so saving a figure cannot just overwrite the PMD, but must insert the UUID tagged morphs into it, so it has to be intact and match the figure you're saving) has to be treated like a database, which you don't necessarily want to just completely overwrite.
nagra_00_ last edited by
Good luck with PMD !
In the past i run several times into the dialog above, although without the reiterating.
fbs7 last edited by
I know this is a scary tale with happy ending, but I've been too many times on the unhappy ending of it... that's why I always tell myself: PMD's are evil, PMD's are scary, no use PMD, go away PMD, shoo-shoo PMD, and keep checking every couple of weeks to see if Poser re-enabled PMD behind my back.
But now that you brought this frightening PMD tale (even if it had a happy ending) I'm sure I'm going to have some nightmare with PMD, like it's eating my house or something.
anomalaus last edited by anomalaus
@fbs7 in hindsight, the only unexpected occurrence here, is the Groundhog Day inescapable (without operating system intervention external to Poser) loop. My suggestion to SMS would be that any error message which includes the the words "There may be" is utterly unacceptable. Is there actually insufficient memory or isn't there? Work it out, Guys! Don't offer guesses to the user.
If it's not a memory problem, as this demonstrably was not, determine that the PMD file you're trying to update is completely unrelated to the figure you're saving (you have a complete list of UUID's after all) and don't bother to try and update it, just overwrite it completely, thereby avoiding a data inconsistency which Poser's logic cannot escape, and mirroring the situation which occurs in a non-binary-morph situation where a character saved to the library completely overwrites any files of the same name which already exists, eliminating complications.
I am using PMD (external binaries) all the time now since P10.
In the P9/P10 beta time frame there were a lot of bugs fixed with regards to PMD corruption.
There are still some things to be aware of. All filenames in Poser have to be unique - regardless of filename. This means it will reuse the same file if it encounters it again (regardless whether it is the same file or not). When you save a scene with external binaries, it will create a PMD with the same name as the scene. If you have named the scene the same as a figure you have loaded (with an attached PMD file), Poser will now prevent you from saving the figure or scene with that same name to avoid a naming conflict (scene PMD and figure PMD having the same name) and it throws up a warning message. Solution is to save the scene of figure with a different name.
Things can get more complicated when you overwrite a figure in the library. The figure may have been used in another scene and that scene may have had a reference to the figure PMD. If you use the same figure it will be fine, but if there is a change in the loaded morphs, there might be an PMD corruption message if you load that old scene.
If you load old (pre P10) scenes you may run into PMD corruption messages caused by pre-P10 bugs which have crept into that scene. One of them was when you used the cloth room. If you had a saved sim and you have done multiple sequential save afterwards (usually 5 or more Save As with a new filename of the same scene), it was possible that a PMD got corrupted because of rounding errors in the simulation. Once it gets over a certain threshold, the scene could get corrupted. This bug (and others) were fixed in P9 and the P10 beta builds. But the corruption message may creep up when you load older scenes which were already infected with the bug.
Last year I spend several months to load all my old scenes (several thousands) to find out what they contained and make renders of it and found 2 occurrences of the old bug. Both were created in P8/P9. In both cases i could save those without binaries and re-inject the morphs of the corrupted PMD and recover my scenes.
I am using external binaries all the time for the past 5 years and have not had a problem since.
There are 2 reasons why I use them. Most important one is that a Save is a LOT faster as without PMD (save of a very large scene is a few seconds instead of minutes) and the scene filesize is a lot smaller as well.
If you don't feel comfortable with external binaries, turn it off. It will not prevent the loading of figures or scenes with their attached PMD files. Those are not changed and do not get corrupted.
I feel completely comfortable with external binaries,. so I have the option on to benefit from the load and save performance benefits