Morphs & Genesis: On Coding Level; Workaround/Fix Found
This is not a request for help about how to create morphs, or even what avenues one may take to create them. I need help in line with the equivalent of CR2 coding, and placement of MT's within Genesis file structure itself. I guess this would be the DSON file structure.
I am well versed in the world of CR2's, and all the coding manipulation all the way through to Gen4 figures, but the new DSON/Genesis format is kicking my azz in regards to how some things work.
O.k., here goes... Ultimately I need to know exactly how does Genesis digest, and link created morph targets. I am experiencing some unwanted anomalies which may not even be that, but just illegal linkage due to my lack of understanding of Genesis' core code.
First, no, I do not need help with where in DS's file structure to place morphs, so please don't add links to amateur tutorials on how to do this. No need...
I am going to use millighost's great Genesis morphing suite for Blender as a for example.
The code structure for the created .dsf file is a little different from others (DAZ, FaceGen, etc.), but has all necessary code to create a viable morph target. As an aside; From what I see, all vertex displacement data is within the DSF file, so I can't fathom there is any "invisible" code linking to any hidden asset files anywhere. It seems the DSF morph target files are self contained.
So, the issue I am having has to do with both changing the morph target location within the DS/Genesis Parameters node tree (Universal, Head, Actor, etc.), and MT linking with Genesis failing, creating unusable null and void parameter sliders.
Millighost's .dsf exporter defaults to setting a morph target in Universal. Even if it is a compound MT based off a previously created MT which already had a dedicated parameter location. So, I edit the DSF file to relocate the MT where I want it on the node tree. This works fine, and is not the inherit issue.
O.k., here is where the issue starts, and my confusion on just how the MT's link to Genesis. Let's say I want to keep the created MT in the default "Universal" location, but I also want to add it to "Actor/Head/Universal". If I edit the code to reflect the new location, AND even give it a modified name (changed throughout the DSF file as well) it will null and void the first MT (Universal location). Even more so, if I decide I don't like the Universal location being null and void, and delete (or remove) the newly edited MT/location, this does not reinstate the first MT (Universal).
There are no longer two of the exact same MT's (with different names) stored in the DS file stucture, but it seems only the newer saved one is "live", and if I put it back into the DS file stucture it appears back in the morphs list, and works again. However, the original first morph remains dead. Now, if I re-save the original MT from Blender overwriting the first it reinstates that morph again, and null and voids the second edited one with a different name/location.
So, my underlying question is, why is this?
How is Genesis assessing, and linking to the individual morphs?
Is there some hidden data protocol that is overwritten each time you save a newer version of the same set of vertex displacement data regardless if identifiers have been changed? You can't have the exact same morph, yet named different; Head1, Head2, Head3, etc.
It's just not possible to have duplicate locations for the exact same mesh data (even with different names)? If so, why?
How exactly is Genesis linking these DSF morph files? The only difference I see in any of the DSF files I have studied (besides how an author created the structure) is in the "parent id" reference. It seems it could be either "#Genesis", or "#geometry" without any difference (they both work).
Any help from the masters would be greatly appreciated, and I'm sure this would be a good learning example for a lot of other people as well. I can't believe I am the only one who has encountered this, or is interested in knowing this for future work.
Thank you in advanced for your time, and any help you can give.
*EDIT: Testing done in DS Pro 126.96.36.199 (but I assume this relates to all DS4/Genesis versions).