Morphs from G3 to G8

1414244464771

Comments

  • HaruchaiHaruchai Posts: 1,879

    Since the Prototype.dse was used and not PrototypeVerbose.dse, there's not a lot in the log file. That said, I don't think it would make much difference because the script completed successfully. So that tells me the files were created.

    Further, the log shows that Studio is reading the created files, however the error is "Cannot find parent." This tells me that parent data line for the modifiers is not as Studio expects.

    My first recommendation is to make sure you have all of the most current files. First install the package in my signature, then replace the Prototype.dse script with the scripts found here.

    Beyond that, I wonder if perhaps you've modified your Genesis 8 Female, which might also cause this issue. In all of my tests, only Genesis 3 Female is picky about exactly what the parent data line says, however you are clearly having parent mismatch. Since it seems to be just you, this is the first thing that comes to mind.

    Baring in mind, I could completely wrong since this is inferred from the logs (and again, while the Verbose script might help, I know what it prints, and it's likely it wouldn't add much to this case as the script appears to have done what it should do). Perhaps someone else could attampt to move Arabella 7 to Genesis 8, and report if the have similar issues. I'd not expect it, but it could happen.

     

    Thanks for the response.

    I can confirm that I am using the files you have suggested. I installed the files from the ones in your signature and replaced the two Prototype files with the latest ones, 10th February, as per your link above. I will reinstall Genesis 8 Female and see if that cures the parenting problem whilst we see if anyone else has my issue.

  • jardinejardine Posts: 1,190

    hi, singular...

    so here's an anomaly i ran into last night.  i've reproduced the error twice today to verify (or try to verify) that it wasn't due to a mistake on my end.

    i encountered it transferring some of 3anson's Creative MR morphs from g3f to g8f.  this log file covers the transfer of two sets (product subsets, really) of breast morphs. 

    for some reason, the first set transfer logged yielded g8 morphs that have switched from an original parameter range of 0.00 - 100.00, limits on, to a range of -100.00 to 100.00, with limits off.  they don't seem to affect the figure at all within values up to 1000 or so.  (last night i entered something insane in the value field and finally did get some effect that looked like g8's chest had sprouted a dog's head on a tiny neck.  but i didn't try that today.)

    the second set transferred produced g8 morphs that reproduced the g3 shapes quite nicely, maintaining the original parameter range of 0.00 - 100.00 and keeping limits on. 

    hope this is useful...let me know if i can provide any additonal info, or run something again for you.  i will try to keep an eye on the thread today, but i'm DM'ing you my email if you'd like to contact me more directly.

    j

     

     

    zip
    zip
    3anson-exp-log.zip
    87K
  • FenixPhoenixFenixPhoenix Posts: 3,001
    edited February 2018

    Since the Prototype.dse was used and not PrototypeVerbose.dse, there's not a lot in the log file. That said, I don't think it would make much difference because the script completed successfully. So that tells me the files were created.

    Further, the log shows that Studio is reading the created files, however the error is "Cannot find parent." This tells me that parent data line for the modifiers is not as Studio expects.

    My first recommendation is to make sure you have all of the most current files. First install the package in my signature, then replace the Prototype.dse script with the scripts found here.

    Beyond that, I wonder if perhaps you've modified your Genesis 8 Female, which might also cause this issue. In all of my tests, only Genesis 3 Female is picky about exactly what the parent data line says, however you are clearly having parent mismatch. Since it seems to be just you, this is the first thing that comes to mind.

    Baring in mind, I could completely wrong since this is inferred from the logs (and again, while the Verbose script might help, I know what it prints, and it's likely it wouldn't add much to this case as the script appears to have done what it should do). Perhaps someone else could attampt to move Arabella 7 to Genesis 8, and report if the have similar issues. I'd not expect it, but it could happen.

    I can confirm I was able to successfully transfer Arabella7 to Genesis 8. Here's a quick render:

    Arabella7-Gen8.jpg
    1267 x 1683 - 715K
    Post edited by FenixPhoenix on
  • Singular BluesSingular Blues Posts: 737
    edited February 2018

    Jardine,
    By the log, I see you ran the script several times on the same morph packages. I can't see why you did that. (EDIT: Not that you arent supposed to. The script shouldn't care. I just can't see anything in the log to explain it.) All of the times you ran it, the script logged success, except one case you ran it without the correct number of nodes selected.

    There's only two ways that comes to mind to see a morph file added with limits off. A) you played with the dials without reloading the figure. In my experience, Studio caches morph data but not ERC data, so even if things were buggy, reloading should have set the value limits. B) the final morph adjustment step did not occur. However, in that case, the base morph would be correct. The only way to get the result you describe out of the script is for the transfer not have happened at all. in which case the script would atempt to perform the morph adjustment step, find no data, and write the source figure vertex order. However, in that instance, the resultant morphs would have the same limits as the original, because the script does not rewrite any of that data. It copies it directly from the source.

    Based on your log, if you restart studio and just load genesis 8, the problem morphs will load correctly. However, nothing in your log indicates they should have transfered incorrectly. 

    There is a possibility C in which you somehow loaded a malformed version of the morph, and dialed it, then attempted to run a transfer. I've seen this, but that was a case of morph transfered from a morph that had been transfered by my old scripts, and the original morph was malformed (I kept telling people it wasn't ready to sell and it was because of things like that). It worked on the first figure, but there were places where there were too many tabs, and that seemed to throw Studio for a loop. However, that issue was a problem only because, after discovering that problem with source, I also dicovered that the actual morph transfer was erroring out. Thus wrong vertex order, a problem that persisted over 4 new scenes despite what turned out to have been a successful transfer. It was only after resarting studio that the morph dialed in correctly. However again, with each new scene, the limits were on.

    Post edited by Singular Blues on
  • HaruchaiHaruchai Posts: 1,879
    edited February 2018

    I can confirm I was able to successfully transfer Arabella7 to Genesis 8. Here's a quick render:

     

    Thanks giselle3000. So that confirms it is definitely something going on with my copy of Studio.

    I have reinstalled Genesis 8 Female with no further progress. I have also tried with a pristine copy of Genesis 8 Male. I tried transferring Gianni 7, with the verbose script, and attach the log in case this can shed some light on what may be stopping the morphs showing.

    Other than that I guess I'm at the stage of 'it's something wrong with my how my copy is setup'.

     

    Thanks for all the help and suggestions.

    txt
    txt
    log.txt
    175K
    Post edited by Haruchai on
  • jardinejardine Posts: 1,190

    hi, singular...

    i'll give it another go-round in a bit, and i'll delete and reinstall the morphs i'm trying to transfer before i do that. 

  • barbultbarbult Posts: 23,049
    jardine said:

    hi, singular...

    i'll give it another go-round in a bit, and i'll delete and reinstall the morphs i'm trying to transfer before i do that. 

    Be sure they're installed with DIM, not Daz Connect.

  • barbult said:
    jardine said:

    hi, singular...

    i'll give it another go-round in a bit, and i'll delete and reinstall the morphs i'm trying to transfer before i do that. 

    Be sure they're installed with DIM, not Daz Connect.

    It shouldn't matter. I installed them with Daz Connect and it works for me with the latest fix of the script.

  • barbultbarbult Posts: 23,049
    barbult said:
    jardine said:

    hi, singular...

    i'll give it another go-round in a bit, and i'll delete and reinstall the morphs i'm trying to transfer before i do that. 

    Be sure they're installed with DIM, not Daz Connect.

    It shouldn't matter. I installed them with Daz Connect and it works for me with the latest fix of the script.

     

    barbult said:
    jardine said:

    hi, singular...

    i'll give it another go-round in a bit, and i'll delete and reinstall the morphs i'm trying to transfer before i do that. 

    Be sure they're installed with DIM, not Daz Connect.

    It shouldn't matter. I installed them with Daz Connect and it works for me with the latest fix of the script.

    Really! I'll have to give that a try then. It never worked before. That would be a big improvement.

  • barbultbarbult Posts: 23,049

    Yes! It does work with characters installed with Daz Connect now!!!!!

  • Singular BluesSingular Blues Posts: 737
    edited February 2018

    The first thing stands out to me is this: 
     

    2018-02-12 01:25:31.588 WARNING: fileinput\dzassetdaz.cpp(4908): Could not find parent for modifier: S1M_PowerfulAthleticTorso.
    2018-02-12 01:25:31.590 WARNING: fileinput\dzassetdaz.cpp(1427): Failed to prepare modifier: S1M_PowerfulAthleticTorso!
    2018-02-12 01:25:31.590 WARNING: fileinput\dzassetdaz.cpp(4908): Could not find parent for modifier: S1M_PowerfulAthleticThighs.
    2018-02-12 01:25:31.590 WARNING: fileinput\dzassetdaz.cpp(1427): Failed to prepare modifier: S1M_PowerfulAthleticThighs!
    2018-02-12 01:25:31.590 WARNING: fileinput\dzassetdaz.cpp(4908): Could not find parent for modifier: S1M_PowerfulAthleticShins.
    2018-02-12 01:25:31.590 WARNING: fileinput\dzassetdaz.cpp(1427): Failed to prepare modifier: S1M_PowerfulAthleticShins!
    2018-02-12 01:25:31.591 WARNING: fileinput\dzassetdaz.cpp(4908): Could not find parent for modifier: S1M_PowerfulAthleticArms.
    2018-02-12 01:25:31.591 WARNING: fileinput\dzassetdaz.cpp(1427): Failed to prepare modifier: S1M_PowerfulAthleticArms!
    2018-02-12 01:25:31.592 WARNING: fileinput\dzassetdaz.cpp(4908): Could not find parent for modifier: S1M_PowerfulAtheticism.
    2018-02-12 01:25:31.592 WARNING: fileinput\dzassetdaz.cpp(1427): Failed to prepare modifier: S1M_PowerfulAtheticism!
    2018-02-12 01:25:31.596 WARNING: fileinput\dzassetdaz.cpp(1438): Failed to create modifier: S1M_PowerfulAthleticTorso!
    2018-02-12 01:25:31.598 WARNING: fileinput\dzassetdaz.cpp(1438): Failed to create modifier: S1M_PowerfulAthleticThighs!
    2018-02-12 01:25:31.598 WARNING: fileinput\dzassetdaz.cpp(1438): Failed to create modifier: S1M_PowerfulAthleticShins!
    2018-02-12 01:25:31.598 WARNING: fileinput\dzassetdaz.cpp(1438): Failed to create modifier: S1M_PowerfulAthleticArms!
    2018-02-12 01:25:31.598 WARNING: fileinput\dzassetdaz.cpp(1438): Failed to create modifier: S1M_PowerfulAtheticism!

    This appears to be a Genesis 8 Male product from renderosity, and it is failing to load under the same circumstances.

    This appears in your log alone on G8M load. Then the script is run. Then the next time G8M is loaded, the same errors occur on the script targets. But this appears every time.

    As a rule, figures don't seem to over much care whether the modifer parent is the figure or the figure geometry. Structurally, Studio seems to expect morphs to be children of geometry, but Genesis 3 female tends to be weird, with a lot cannot find parent when the parent is geometry. It's not been my experience that this is an issue with G8M. As a guess, for some reason your system is picky, judging by the fact that it's not only transfers by the prototype causing this issue. It would be most helpful to nail down the exact cause, but unfortunately, I'd need to be able read the files on your hard drive, since (as the refrain goes) I can't replicate the issue.

    I know tech people can come across as blamey and stuff, so understand, I do want to solve this because if it is broken for you that could be 100s of unhappy customers. But part of that is ironing out why it is broken for you but no one else has reported the issue. This means important details like where are these figures installed? Are they in different libraries, connect libraries, etc? The real issue here is, there's no way I can possibly think of all the questions I'd need to ask.

    Off the top of my head I can't imagine why this would be any issue for any figure other than G3F. If there really is an issue with way the parenting is written by the script and what works, then I'd like to fix it. And that starts, unfortunately, with you figuring out what this Sixus1 rendo product (Simply Human: Natural Male For G3M and G8M) has in common with the transfered morphs.

    Post edited by Singular Blues on
  • barbult said:

    Yes! It does work with characters installed with Daz Connect now!!!!!

    Yes! I've yet to run into a problem transferring something since the fix! I even managed to transfer Sakura8 over to G8M (though the character below does have other characters dialed in; I'm still using Sakura dialed to 100; both body and head)!

  • barbult said:

    Yes! It does work with characters installed with Daz Connect now!!!!!

    Yes! I've yet to run into a problem transferring something since the fix! I even managed to transfer Sakura8 over to G8M (though the character below does have other characters dialed in; I'm still using Sakura dialed to 100; both body and head)!

    That worked better than I expected for S8.

    Which is something I should note. I think I have about the best solution I can get for transfer breast morphs cross gender, but to get that, nipple accuracy is off. This is another low priority issue. I think it can be impproved, but the bottom line is that male and female nipples are not aligned, so those details will not transfer accurately.

    As a further pontification on the Sixus1 morphs, I suspect that perhaps the common thread is that Sixus used a similar method to create the G* version of the for G3 and G8 product. But you'd have to ask Sixus1 about that.

  • marth_emarth_e Posts: 171

    Just tested the last version of the script and the image cards seems to being working now.

  • HaruchaiHaruchai Posts: 1,879

    I know tech people can come across as blamey and stuff, so understand, I do want to solve this because if it is broken for you that could be 100s of unhappy customers. But part of that is ironing out why it is broken for you but no one else has reported the issue. This means important details like where are these figures installed? Are they in different libraries, connect libraries, etc? The real issue here is, there's no way I can possibly think of all the questions I'd need to ask.

    Ok, let's see if we can start to narrow this down then if you're game.

    All my content from DAZ is installed via DIM. All content is on an external drive, everything is on the same drive. DIM installs directly to the My Library on the external drive. The My library on the C drive in Documents is completely empty.

    My DAZ Connect Libary is also set up to install to this drive but has only been used a couple of time, mainly scenes picking up old Poser content it can't find.

    The only other data is in my C:-Users-Public-Documents-My DAZ 3D Library. There is a data folder there where your script is copying the morphs that are attempting to be transferred. (I tried moving these files onto the external drive data folder in case it was an issue of having 2 data folders but that didn't appear to solve it). The folder on C: is mapped as a content directory in the Directory Manager (see attached Content jpg).

    With regards to the Sixus morphs SOME of them are showing just not all. I have attached a comparison of the G8M and G3M version loads. Any investigation of the sixus dsf files I can do if that will help in any way.

    I have again uninstalled and reinstalled Genesis 8 Male via DIM and tried the process again with no success. Log file gives the same parenting error.

    Not sure if any of this is relevant/useful so let me know what else to check that you might be able to think of.

    Content.jpg
    459 x 456 - 38K
    SixusG8M.jpg
    760 x 856 - 140K
    SixusG3M.jpg
    761 x 704 - 148K
  • FenixPhoenixFenixPhoenix Posts: 3,001
    edited February 2018
    Haruchai said:

    I know tech people can come across as blamey and stuff, so understand, I do want to solve this because if it is broken for you that could be 100s of unhappy customers. But part of that is ironing out why it is broken for you but no one else has reported the issue. This means important details like where are these figures installed? Are they in different libraries, connect libraries, etc? The real issue here is, there's no way I can possibly think of all the questions I'd need to ask.

    Ok, let's see if we can start to narrow this down then if you're game.

    All my content from DAZ is installed via DIM. All content is on an external drive, everything is on the same drive. DIM installs directly to the My Library on the external drive. The My library on the C drive in Documents is completely empty.

    My DAZ Connect Libary is also set up to install to this drive but has only been used a couple of time, mainly scenes picking up old Poser content it can't find.

    The only other data is in my C:-Users-Public-Documents-My DAZ 3D Library. There is a data folder there where your script is copying the morphs that are attempting to be transferred. (I tried moving these files onto the external drive data folder in case it was an issue of having 2 data folders but that didn't appear to solve it). The folder on C: is mapped as a content directory in the Directory Manager (see attached Content jpg).

    With regards to the Sixus morphs SOME of them are showing just not all. I have attached a comparison of the G8M and G3M version loads. Any investigation of the sixus dsf files I can do if that will help in any way.

    I have again uninstalled and reinstalled Genesis 8 Male via DIM and tried the process again with no success. Log file gives the same parenting error.

    Not sure if any of this is relevant/useful so let me know what else to check that you might be able to think of.

    So if your content is in your external drive (G), then move that up inside the content directory manager. You want that to be the first path on the list within Daz Studio Formats. Since, Rez did mentioned it way back (page 40 of this thread):

    Redz said:

    Hi Singular Blues. First trials with the new prototype script. 

    First attempts, I received an error. Went back and read your instructions, and discovered that my ‘main DAZ3D Library’ (where I installed the script and data folders) was not the one that is listed first in my Content Library - Daz Studio Formats. Once I set ‘My Daz 3D Library’ as the first folder in the list, the script works exactly as described. 

    So is the script looking for the first listed Library destination, rather than the main one, where the base figures are installed? For most people they will be the same, but I customize the content folders a lot for content creation.

    Don't know if it'll fix the issue, but you can always give it a shot :)

    Post edited by FenixPhoenix on
  • HaruchaiHaruchai Posts: 1,879
    Haruchai said:

     

    Don't know if it'll fix the issue, but you can always give it a shot :)

     

    And it was as simple as that it seems. Apologies for missing that particular bit of information.

    Thank you so much for pointing that out, it has in fact solved the issue.

    Again apologies for not reading the thread carefully enough.

  • FenixPhoenixFenixPhoenix Posts: 3,001
    edited February 2018
    Haruchai said:
    Haruchai said:

     

    Don't know if it'll fix the issue, but you can always give it a shot :)

     

    And it was as simple as that it seems. Apologies for missing that particular bit of information.

    Thank you so much for pointing that out, it has in fact solved the issue.

    Again apologies for not reading the thread carefully enough.

    Not a problem! And man, had been thinking of advicing that since yesterday, but I thought... nah, can't be that. Next time, I'm just gonna say it as I think it hahaha. Glad it's working for you now!

    Post edited by FenixPhoenix on
  • jardinejardine Posts: 1,190

    hi again, singular...

    well, i tried running the script on that morph package subset again, and got the same results.  i uninstalled and reinstalled the morph set, deleted the old studio log, launched studio, loaded g3f, favorited the morph, loaded g8f, selected g3f and then g8f, ran the script, and quit.  then i relaunched studio, loaded g8f, and looked up the morph.  it still shows as having a parameter range of -100 to 100, and limits are now off again. 

    i know zip about this stuff, but toward the very end of the script's debug output, i see:  "WARNING: Object::disconnect: Unexpected null parameter".

    then when g8f is loading the second time around, there's a stream of "Could not find output property for formula:" warnings, most of which seem to be related to the lHeel and rHeel geometry of the failing morph. so i opened up the .dsf file for the morph, and sure enough, lHeel and rHeel push definitions are present.  (who knew breast morphs contained heel geometry?  not me...)

    so i'm guessing that there's some aspect of these particular morphs that thwarts translation, though they apply comfortably enough to their intended base figure.  and i'm not going to fret about it, though i will be happy to retry the transfer if that's helpful to you.  as i said, i haven't had any issues translating any of the PA's other zone-specific morphs with your script, breast morphs included. 

    happy trails!

    j

     

    txt
    txt
    log02.txt
    303K
  • Singular BluesSingular Blues Posts: 737
    edited February 2018
    Haruchai said:
    Haruchai said:

    Don't know if it'll fix the issue, but you can always give it a shot :)

     

    And it was as simple as that it seems. Apologies for missing that particular bit of information.

    Thank you so much for pointing that out, it has in fact solved the issue.

    Again apologies for not reading the thread carefully enough.

    Not at all.

    In fact, that bothers me a great deal since, in theory, Studio should be able to deal with the morphs being anywhere, at the end of the day. I'm gonna have to do some thinking about why this is happening

    Mind, the script and supporting files need to be in content directory 0 (Daz counts everything from zero base, so the first of anything it is counting is item 0) so they can be sure to find each other. I hope to extend that to a more general case, but it bugs me that this actually causing it to fail to work. That's unexpected. it might have been fail ... Oh, yes. Indeed.

    You get read my mind working. Lucky you.

    So maybe it's exactly that. I expected the script to fail if it didn't find the support files because I was thinking the clones would break. But my first thought is correct. The clones can be in any active library and Daz will find them. What was breaking was parenting, not because of whatever broke the Sixus1 stuff, but because since the script could not find the support files, the script did not know what to rewrite the parenting data from or to. That's part of the key to making the script "scalable" it doesn't actually care what figure you attempt to run it on. the info it needs to do the translation is in the support files and it finds those files by a combo of the figure name and info in the script. Since it expects those files to be in library directory 0, it wasn't looking elsewhere for them.

    Thanks everyone. I was utterly stumpted there.

    jardine said:

    hi again, singular...

    well, i tried running the script on that morph package subset again, and got the same results.  i uninstalled and reinstalled the morph set, deleted the old studio log, launched studio, loaded g3f, favorited the morph, loaded g8f, selected g3f and then g8f, ran the script, and quit.  then i relaunched studio, loaded g8f, and looked up the morph.  it still shows as having a parameter range of -100 to 100, and limits are now off again. 

    i know zip about this stuff, but toward the very end of the script's debug output, i see:  "WARNING: Object::disconnect: Unexpected null parameter".

    then when g8f is loading the second time around, there's a stream of "Could not find output property for formula:" warnings, most of which seem to be related to the lHeel and rHeel geometry of the failing morph. so i opened up the .dsf file for the morph, and sure enough, lHeel and rHeel push definitions are present.  (who knew breast morphs contained heel geometry?  not me...)

    so i'm guessing that there's some aspect of these particular morphs that thwarts translation, though they apply comfortably enough to their intended base figure.  and i'm not going to fret about it, though i will be happy to retry the transfer if that's helpful to you.  as i said, i haven't had any issues translating any of the PA's other zone-specific morphs with your script, breast morphs included. 

    happy trails!

    j

     

    I'm not sure the unexpected null is script related. I'd guess not since the log tends to expressly say things like "script [path] error line n" when it's an error there. as a guess it's an error in the IRT plugin that crops up next, but I'm iffy about that since it's almost 1.5 seconds before that comes up. OTOH it's a full 23 seconds between the last script entry and the null warning. My guestimate is that the script ould take less that 10 seconds to complete in total since it only took 2 seconds to get that far.

    Are you still getting this first group of morphs showing up with no limits? Are they still not dialing in as expected? are you seeing similar issues with other morphs?

    If they are still showing up without limits, please go to D:/oh3d/DAZ 3/Library 3/data/DAZ 3D/Genesis 8/Female/Morphs/3anson/3A Creative MR 01/Breast MR 1/ and right click any dsf file and use the open with to open it in a text editor. You'll see code but near the top will be a section that looks like so:

    	"modifier_library" : [		{			"id" : "PBMMorph",			"name" : "PBMMorph",			"parent" : "/data/DAZ%203D/Genesis%208/Female/Genesis8Female.dsf#Genesis8Female",			"presentation" : {				"type" : "Modifier/Shape",				"label" : "",				"description" : "",				"icon_large" : "/data/DAZ%203D/Genesis%208/Female/Morphs/Some%20Vendor/Some%20Product/PBMMorph.png",				"colors" : [ [ 0.2196078, 0.3019608, 0.3882353 ], [ 1, 1, 1 ] ]			},			"channel" : {				"id" : "value",				"type" : "float",				"name" : "Value",				"label" : "Morph",				"auto_follow" : true,				"value" : 0,				"min" : 0,				"max" : 1,				"clamped" : true,				"display_as_percent" : true,				"step_size" : 0.01			},

    The key point is, assuming a morph that does not show limits while loaded on G8, do the values in "channel" for  "min", "max" and "clamped" read -1, 1, and false respectively. (note, "clamped" may not even appear, but min and max will.)

    They should not. 

    As to the heel thing, that's a present limit of the prototype I'm working on. G8 and G3 don't have the same bones, exactly. specifically, the heel bone was deleted for G8. The heel error actually is a sign the  morph is correctly being read, since there are no other bone failures.

    What that is actually telling you is the author ran adjust rigging to shape without limiting it to the likely affected bones, which will cause G3/G8's entire skeleton to shift slightly, because the skeleton is somewhat hand made. The bones are placed where they work best, not where autorig will place them. So running autorig on an unchanged figure will often cause minor shifts in the bones. That's the issue.

    By the closed beta, my aim is to have the script intelligently removing bones that don't apply to the target figure. It's a necessary aim, as the Beta will introduce Genesis or Genesis 2 support (likely Genesis, though I know people will want G2 more, but Genesis means only one figure, and G2 support means 2. Yes, I have to do all 3 in the end, but the difference between G1 and G2 are not so large as either is different from G3/8 so once G1 is integrated, G2 should be fairly easy). Because they have completely different bone structures, the script will need to have code that accounts for that, and supportfiles that know tell it what to add and remove on the fly.

    Post edited by Singular Blues on
  • nonesuch00nonesuch00 Posts: 17,890
    edited February 2018

    Yes, it's not going to fly to tell John & Jane Doe tht they have to reconfigure all their DAZ content product path names to use something they've bought out of the DAZ Store. There were quite a few people last year that returned a couple of products that wouldn't won't work if the DAZ content was changed from anything but the default DAZ configuation.

    Post edited by nonesuch00 on
  • Yes, it's not going to fly to tell John & Jane Doe tht they have to reconfigure all their DAZ content product path names to use something they've bought out of the DAZ Store. There were quite a few people last year that returned a couple of products that wouldn't won't work if the DAZ content was changed from anything but the default DAZ configuation.

    I know it can be done. I just didn't expect it to cause this particular issue. Ultimately, I think the script has to be written such that it runs correctly even out of the connect library, which is no real issue. The final script will default to library 0 but will give the option to save to any library but connect, (just because I don't know how to safely save anything there, and think it's probably a bad idea to try). But I'm pretty sure there's actually a method in DzDir that automatically searches all content libraries for the relative path provided. So it should be easy enough. For testing, it was a low priority, again. I was sure there would be issues like the as yet unsolved long fingernail issue that need solving, and unfortunately, there's not an easy fix for these things because, unlike the old system, there no easy to predict what this will do unless you stress test it. Before, when there were distortion, I could say "this vertex here is getting the wrong data. it's either out of order or it's mis placed in the "clone" morph, and it was fairly simple to figure out where it needed to be. In this system, I still haven't a solid clue as to why the nails are doing what they do. Given that I'm 99.999% sure there's a plug and play solution to getting the script to run from anywhere, It's not a first line issue to solve.

  • nonesuch00nonesuch00 Posts: 17,890

    OK, that's good. I've been waiting for the fingernail fix myself before I test. I will only transfer toony styles to G3 to G8 and then both ways G8F - G8M. Genesis 2 and Genesis I'll buy the product although I have some weird Joe Quick characters that I could use to test it seems you have plenty of testers already.

  • dreamfarmerdreamfarmer Posts: 2,128

    I used this last night for the first time. Initially I did it wrong but I sorted out the problem (same as Haruchai's above, which I repeated because I used the instructions in the post SB's sig links to). Except I had somehow _partially_ transferred morphs (they did nothing but change height and generate a lot of log errors) and then couldn't get rid of them even when I deleted and uninstalled and reinstalled the entire base. I started to ask for help here, then realized I ought to look in the directory that had originally been first in my Content Directory Manager -- and there they were. Once I deleted them I was able to transfer the morphs correctly. (It was Sakura 8 to G8M, btw.)

    Anyhow, I wanted to leave this experience here, in case other people come along in the same pickle, or in case it helps SB figure out a workaround for the final product to use.

    Thank you very much!

  • Since most of the feedback indicates the recent troubles are solved, I've updated the package file to the most recent script version, so there's no longer a need to download two sets of files.

  • So I've been testing transferring between genders, especifically G3F to G3M. I was successful with transferring Sakura 8 to G8M > G3M > G3F, but results vary when I try to transfer other figures between males and females. For example, I transferred Aiko 7 to G3M. I ran the script successfully, but the morphs won't show up when I clear the scene, close Daz, restart and load a G3M.

    • So I looked up the path for Aiko 7 morphs: W:\DAZ RESOURCES\My DAZ 3D Library\data\DAZ 3D\Genesis 3\Female\Morphs\DAZ 3D\Aiko 7
    • And compared them to the Aiko 7 transferred morphs:  W:\DAZ RESOURCES\My DAZ 3D Library\data\DAZ 3D\Genesis 3\Male\Morphs\DAZ 3D\Aiko 7

    The 66 morphs did get transferred (or at least they show up in G3M data folder), but they just don't show up like Sakura 8 did. I also checked in the Parameters tab (since I did manage to get Aiko 6 & Keiko6 (from Gen2 legacy shapes) transferred to G3M, but they only shows up in the parameters tab, not the shaping tab). However, Aiko 7 wasn't there either. I then tried to transfer Victoria 7 to G3M, but it's the same as Aiko 7. The folder is there inside the \data\DAZ 3D\Genesis 3\Male\Morphs\DAZ 3D\Victoria 7, but the morphs themselves don't show up inside DAZ. The names for each morph transferred over in small caps, but even replacing them to match didn't make them appear. Will try with other non "flagship" Daz characters next. 

  • Singular BluesSingular Blues Posts: 737
    edited February 2018

    Made a change to the support files. Should fix that.

    It was related to the pesky Genesis3Female-1 issue.

    Post edited by Singular Blues on
  • barbultbarbult Posts: 23,049

    Made a change to the support files. Should fix that.

    Is that change in the package in your signature now?

  • Yup. I uploaded it before I posted.

  • jardinejardine Posts: 1,190

    hey again, singular...

    so i went to check those values in the exported g8f morphs last night, and...well, let me just summarize what i wound up figuring out last night and today; it'll be a lot easier to follow than an explanation of how i got there.  :)   but i have repeated the experiment several times...to confirm that i was being consistent, at least. 

    the g3f morph that i was favoriting is subfoldered in the original morph package.  running the script produces two different versions of the set's morph files in the g8f data folder--one at the base directory of the package, and one in a correctly-named subfolder thereof.  the files created in the base directory and the subfolder have different parameter values (as per your note above).  png files appear only in the subfolder.  the morph files in the base directory have limits off, and their dials can be set to + or - thousands without affecting the figure.  these are the values that studio seems to be reading when both the base and subfoldered versions of the morphs are loaded.  quitting studio and replacing the files in the base directory with the subfolder files and relaunching gives morph dials that display at the correct values of 0-100%, and have limits on...but dialing these morphs in distorts the entire figure.  the breasts themselves are distorted, and weird flanges of flesh appear elsewhere.

    call that run transfer01.

    for transfer 02, i went into the g3f source directory, transferred the breast morphs up one level from their subfolder and into the base folder, and deleted the subfolder i'd taken them from.  then i restarted studio, used the utility script to purge memory, set up the g3f and g8f and ran the script.  this gave me breast morphs that all worked perfectly, and also translated the four other subfolders in the base directory...body, ear, head, and nose. and this is where things get weird.  the morphs from the body and head subfolders showed up correctly as 0-100% dials, were limits on, and worked like a charm.  the morphs from the nose and ear folders had the same off range i'd seen in transfer01, and had limits off.  (i should have checked to see if those subfoldered morphs had also generated evil twins, as the breast morphs did in transfer01.  but i forgot to.  sorry...)

    for transfer03, i went back into the g3f source directory, dumped all of the subfoldered morphs into the main folder, and deleted the empty subfolders.  then et cetera et cetera, ran the script.  the morphs all transferred perfectly.

    i saved logs and sample files and a ton of window captures while i was doing this, but i'm not uploading them at the moment...for one thing, half of my window captures include unclad base figures.  and i'm not sure what my ref folder would zip down to, sizewise.  but i would be happy to set up a dropbox for you, if you like--just DM me if that sounds good.

    yt,

    j

     

Sign In or Register to comment.