As you may know, I am a moderator over at Renderosity. I had a question yesterday that is more technical than my skill level. So ... I bring it here for the true Gurus of Poser: "Can anyone give any details about Morph ID and UUID? What are they? Should I edit them, or leave them as they are? If I should edit them, what goes? What are the best practices?" ~ TMDesign in the Poser Forum at Renderosity.
anomalaus last edited by
@Boni UUID (Universally Unique IDentifier) is used when PMD binary morphs are enabled, and are allocated when a morph is either initially created with PMD enabled, or when a figure/prop is initially saved to the library with PMD enabled. If PMD is disabled and the figure is resaved, the allocated UUID will remain, but the PMD component (morph target deltas) will be re-incorporated into the cr2 file.
If you have a file with UUID AND deltas, then the UUIDs are redundant, but will be re-used (rather than reallocated) if you ever re-enable PMD binary morphs.
If you were to edit the UUID definition of a morphTarget channel within an actor, you could either run into the problem of rendering the UUID string invalid (not adhering to the rules of UUID specification), or inadvertently choose one that had already been used (not unique). If, on the other hand, you were trying to re-link a CR2 file with a previously saved PMD repository, and knew the exact UUID of the morph you were trying to connect to, that would probably work. In general, though, leave them alone.
There are python scripts around which can parse PMD files and list the contents. I'll see if I can find a reference.
I'm not familiar with the term "Morph ID", unless it's another term for UUID, or the channel's internal name.
@anomalaus Thank you! that was a great answer. I will relay it.
rokketman last edited by
Wow. I understood about one line of that. I really need to start digging into the nuts and bolts of a figure and learn more...
anomalaus last edited by
@rokketman having been hand editing Poser files since version 4 (though using Poser since v1), there are still many things I have yet to come to grips with. Every release seems to bring new, undocumented items of syntax to Poser scenes, character and pose files (SMS really needs to take ownership of producing and maintaining interface and file level documentation, rather than just what hackers and tinkerers have gleaned through experimentation). I'm forever updating my Editor's extensible language syntax spec for Poser, so that keywords get highlighted in a different colour.
When they were released, I could never afford (or initially trust) the third-party Poser file editors, and their initial iterations were invariably PC-only, having tkInter GUI elements, which have long been incompatible with the Mac platform (where Poser ironically originated). The trust issue has long been ongoing, since Poser still consistently re-orders hidden joint parameters between one save and the next, making comparisons between library files tedious and painful (why would you reverse the order? Hmmm? What illogic or brain fart inspired that piece of code?)