Morphs from G3 to G8

FenixPhoenix

Ichiban said:

I can't get it to work when I try to transfer G3M morphs to G8M. I don't know much about accessing the log, but I also noticed my My Daz Library is not at the top of the list, Daz Connect is. Would that make a difference? If I can get my setup right to try this, I'll be more than happy to give logs. Just needing a little help with getting them and setting up for this. I appreciate the effort put into this.

If you're not using Daz Connect, then it's fine. Just check that wherever your main library is, is at the top of the "Daz Studio Format" list. To do that right-click on the Content Library tab > Content Directory Manager... Then open Daz Studio Formats (by clicking on that small plus sign) and check the paths. If your main library isn't the first path, simply select it and click Move: To top.

Singular Blues

I think theweezel didn't reload the figure after the transfer, as they indicated that other FBMs had the same issue. WHich means that the ERC links don't exist, as barbult deduced. One ERC not working suggests an issue with given file. Every FBM ERC suggests that the figure wasn't reloaded.

Honestly, I'm also concerned that they may damage their G8 installiton, because the way they are approaching this risks overwritten files, but I don't know exactly what's up. I am 90% certain that the morphs will have correct ERC links after a reload.

theweezel_c08014c91f

Singular Blues said:

I think theweezel didn't reload the figure after the transfer, as they indicated that other FBMs had the same issue. WHich means that the ERC links don't exist, as barbult deduced. One ERC not working suggests an issue with given file. Every FBM ERC suggests that the figure wasn't reloaded.

Honestly, I'm also concerned that they may damage their G8 installiton, because the way they are approaching this risks overwritten files, but I don't know exactly what's up. I am 90% certain that the morphs will have correct ERC links after a reload.

The not reloading is very possibley the reason.  I'll have to test that out, I didn't really have a lot of time initially since I was at work and all.  Also as for the file overwrites and such I don't think will be an issue.  See my master library is on my server.  Nightly that copies down to my desktop computer which gives me quicker access on that system and acts as a backup.  My little computer I play with while working also gets periodic updates from the master.  So I will test out doing something on it until I am confident it works right then I will do it to the master library which will then filter down, basically everything on my little computer and desktop is regularly overwritten for consistency across systems.  So long as my tests are on the more volitile systems no matter how bad or often I mess up it can always easily be undone.  As such my test tonight doing the transfer without the SC Rain did seem to work fine without the finger issue, so I will set it to be reset to the master library tonight, tomorrow I will try again with the SC Rain and reloading the model and if that works then I will plan to make those changes permanent, if not I know what will work and consider moving forward with that.

Singular Blues

The script works on per product basis. Many dial based presets use products that have G3 and G8 versions.

Running script on a collection of every dial used in a preset will likely cause the script to overwrite files from such products. It's not designed to do that kind of thing, which is why it's called a script for transfering morphs, not presets.

If one whishes to transfer a preset, one has to take the script's actual purpose into consideration and realize that it only does what it says on the tin, as it were.

To begin, one should start by identifying what elements already exist on the target figure.

I understand that because Poser formats did this differently, and people still talk about aspects of Daz figures in poser terms that it can be confusing for many just what character/preset/figure/morph etc is. Vendors still use terms like INJ/REM for Daz figures, despite the fact these concepts don't even apply to the Genesis line. So to be clear, a character preset is just a collection of settings (generic animation settings keyed to frame 0) that tell a Daz figure to change values of the morph/property sliders it contains. Unless the preset is hierarchal, it doesn't matter what figure it is used on. It will attempt to set the values of the sliders anyway. So any items that script would overwrite by attempting to collect all elements in a preset can be ID'd by applying that preset to the target figure and seeing what changes. Anything that changes should not be transfered, because it's already there.

There are other aspects to consider, though they are less dangerous. Like some morphs may have been renamed between generations, and thus transfering one to the other will just create two copies of the same thing. (someone wrote a script that reads G3 presets and spits out the related G8 settings, and that's the first tool one should use for dialspun characters at least G3->G8. I don't recall who or where, but I know it is out there.) Only when you get to the point that you have identified the things that don't exist at all on the target figure should one consider using my script. And, of course, my script is totally alpha and may break your stuff.

It's not your backup system that concerns me as much as it is your approach. Even if your system saves you trouble, other people will see what you did, and see it worked at some point and skip the rest of the thread. They are vulnerable to these issues, even if you ultimately are protected.

theweezel_c08014c91f

Singular Blues said:

The script works on per product basis. Many dial based presets use products that have G3 and G8 versions.

Running script on a collection of every dial used in a preset will likely cause the script to overwrite files from such products. It's not designed to do that kind of thing, which is why it's called a script for transfering morphs, not presets.

If one whishes to transfer a preset, one has to take the script's actual purpose into consideration and realize that it only does what it says on the tin, as it were.

To begin, one should start by identifying what elements already exist on the target figure.

I understand that because Poser formats did this differently, and people still talk about aspects of Daz figures in poser terms that it can be confusing for many just what character/preset/figure/morph etc is. Vendors still use terms like INJ/REM for Daz figures, despite the fact these concepts don't even apply to the Genesis line. So to be clear, a character preset is just a collection of settings (generic animation settings keyed to frame 0) that tell a Daz figure to change values of the morph/property sliders it contains. Unless the preset is hierarchal, it doesn't matter what figure it is used on. It will attempt to set the values of the sliders anyway. So any items that script would overwrite by attempting to collect all elements in a preset can be ID'd by applying that preset to the target figure and seeing what changes. Anything that changes should not be transfered, because it's already there.

There are other aspects to consider, though they are less dangerous. Like some morphs may have been renamed between generations, and thus transfering one to the other will just create two copies of the same thing. (someone wrote a script that reads G3 presets and spits out the related G8 settings, and that's the first tool one should use for dialspun characters at least G3->G8. I don't recall who or where, but I know it is out there.) Only when you get to the point that you have identified the things that don't exist at all on the target figure should one consider using my script. And, of course, my script is totally alpha and may break your stuff.

It's not your backup system that concerns me as much as it is your approach. Even if your system saves you trouble, other people will see what you did, and see it worked at some point and skip the rest of the thread. They are vulnerable to these issues, even if you ultimately are protected.

That is understandable.  Is the creation of a new and unique morph such as the with the Single Morph technique in SickleYield's tutorial on transfering morphs (https://sickleyield.deviantart.com/journal/Tutorial-Transferring-Character-Morphs-G1G2G3G8-409437916) a viable option with your script.  Since it is creating a new morph it should not be overwriting any pre-existing items it seems like a possible solution.

Singular Blues

theweezel_c08014c91f said:

Singular Blues said:

The script works on per product basis. Many dial based presets use products that have G3 and G8 versions.

Running script on a collection of every dial used in a preset will likely cause the script to overwrite files from such products. It's not designed to do that kind of thing, which is why it's called a script for transfering morphs, not presets.

If one whishes to transfer a preset, one has to take the script's actual purpose into consideration and realize that it only does what it says on the tin, as it were.

To begin, one should start by identifying what elements already exist on the target figure.

I understand that because Poser formats did this differently, and people still talk about aspects of Daz figures in poser terms that it can be confusing for many just what character/preset/figure/morph etc is. Vendors still use terms like INJ/REM for Daz figures, despite the fact these concepts don't even apply to the Genesis line. So to be clear, a character preset is just a collection of settings (generic animation settings keyed to frame 0) that tell a Daz figure to change values of the morph/property sliders it contains. Unless the preset is hierarchal, it doesn't matter what figure it is used on. It will attempt to set the values of the sliders anyway. So any items that script would overwrite by attempting to collect all elements in a preset can be ID'd by applying that preset to the target figure and seeing what changes. Anything that changes should not be transfered, because it's already there.

There are other aspects to consider, though they are less dangerous. Like some morphs may have been renamed between generations, and thus transfering one to the other will just create two copies of the same thing. (someone wrote a script that reads G3 presets and spits out the related G8 settings, and that's the first tool one should use for dialspun characters at least G3->G8. I don't recall who or where, but I know it is out there.) Only when you get to the point that you have identified the things that don't exist at all on the target figure should one consider using my script. And, of course, my script is totally alpha and may break your stuff.

It's not your backup system that concerns me as much as it is your approach. Even if your system saves you trouble, other people will see what you did, and see it worked at some point and skip the rest of the thread. They are vulnerable to these issues, even if you ultimately are protected.

That is understandable.  Is the creation of a new and unique morph such as the with the Single Morph technique in SickleYield's tutorial on transfering morphs (https://sickleyield.deviantart.com/journal/Tutorial-Transferring-Character-Morphs-G1G2G3G8-409437916) a viable option with your script.  Since it is creating a new morph it should not be overwriting any pre-existing items it seems like a possible solution.

The script can handle any kind of morph or property, in theory. Some would not work properly but should do no harm. It is a viable option to use the script to move preset based characters, but it takes planning to do it safely, and it's not the point of the script. We're a long way from product stability where I'd be inclined to weigh in on what one could do with this script, which is quite a lot, actually. 

There really isn't a good "one click" solutiong for transfering dial spun characters between figures. GenX can sort of do it, but it can really make a mess of your figure doing it. My scripts can sort of do it, and can equally make a mess of you figure doing it. In all cases, it's pretty advanced figure hacking to do it, including SY's tut. It's all figure hacking, just different flavors. Pick what you like best.

dracorn

I gave up on trying to transfer my G1 dial spun characters via GenX. I even transferred Vicky 5, but her face still warped in Gen2. I just started over. Seems I get better at dial spinning with each generation, so the final G8 results are preferable to the G1 versions. I attribute this to better morph packages with more choices as well as increased skill. So I'll just start from scratch with a fresh G8 model.

What I really want are heads from previous generations as well as morphs. Claws and fingernails are really a plus.

[email protected]

So, I just had an idea to add functionality to the commercial version of the script: how hard would it be to add a morph-splitter function? People often ask for asymmetrical morphs or for separate head and body morphs for characters, and it occurs to me that maybe the script could have a function to transfer only part of a morph and, in doing so, provide this functionality for packages that usually don't have it. Obviously, there may be issues that I am completely unaware of that would make this impractical, but I think it would greatly increase the popularity of the tool.

Singular Blues

Uthgard said:

So, I just had an idea to add functionality to the commercial version of the script: how hard would it be to add a morph-splitter function? People often ask for asymmetrical morphs or for separate head and body morphs for characters, and it occurs to me that maybe the script could have a function to transfer only part of a morph and, in doing so, provide this functionality for packages that usually don't have it. Obviously, there may be issues that I am completely unaware of that would make this impractical, but I think it would greatly increase the popularity of the tool.

Pretty hard.

Not impossible, but pretty hard. Honestly, I wouldn't want to incorporate that in the script because it is really a whole other concept.

Think of the script as automating a number of manual actions (because that is what it is doing). Morph editing is a different set of manual actions. I can think of how to do it, but it's really hard to think of where it would fit into the other process. This strikes me as feature creep of a dangerous sort. I'm one guy. I can focus on one thing and do the best I can, or many things and do them all poorly. Since the scope of the script, right now, is support all genesis figures, I'm already pushing the limits of sanity.

Again, as a seprate issue, it's not a really difficult concept. But the basis of how the script works means adding completely different workflows. It makes it massively more complicated. You can use a butter knife to spready food or as a flat tip screwdriver. You probably shouldn't try to do both at once, unless you are very good. I feel the same way about scripting. You can do a huge number of thingswith it. Safety and sanity suggest not trying to do all of them at once. And as I've said, I'm hacker in the least flattering sense. I can be clever, but I'm not so good as to think I can butter my toast and assemble the bikes at the same time with the same tool.

jardine

are there any particular kinds of morphs or morph sets you'd like to have someone trying the g3/g8 script on, at this point, singular?  or any direction, generation-wise? 

Singular Blues

G8 fingernails to G3 would be useful, but they need to be fairly extreme. I can see where the issue is G3 to G8, but I'm having a hard time getting my head around it.

I mean to do some tests myself, so it'll probably be fine. Anything else aimed at G3F as the target may help. Because the core file for that one is ... odd, there's a lot of extra stuff going on just for that target, so I need to get as much data as I can on how it's working.

I've been feeling out of it. Ear infection. I need to package up the fixed prototype script and update the package, but that's not any major change. Just fixing the thing I messed up. I think I'm right on the point of starting the Beta, which means getting G1 sorted, but the fingernails thing is still outstanding. If I'm right about whats going on, there should be similar but opposite effect when nails are sent from G8 to G3. The main issue  I have is that I'm not at all sure if anything can be done about it. It's due to the A pose. I don't mean to say the issue is impossible. It isn't, necessarily. But I don't have the math to fix what's going on, if I the one idea I have doesn't work.

Basically, If I'm wrong, and the G8 to G3 nails work properly, then my fix will work. If I'm right, it won't.

[email protected]

Singular Blues said:

Uthgard said:

So, I just had an idea to add functionality to the commercial version of the script: how hard would it be to add a morph-splitter function? People often ask for asymmetrical morphs or for separate head and body morphs for characters, and it occurs to me that maybe the script could have a function to transfer only part of a morph and, in doing so, provide this functionality for packages that usually don't have it. Obviously, there may be issues that I am completely unaware of that would make this impractical, but I think it would greatly increase the popularity of the tool.

Pretty hard.

Not impossible, but pretty hard. Honestly, I wouldn't want to incorporate that in the script because it is really a whole other concept.

Think of the script as automating a number of manual actions (because that is what it is doing). Morph editing is a different set of manual actions. I can think of how to do it, but it's really hard to think of where it would fit into the other process. This strikes me as feature creep of a dangerous sort. I'm one guy. I can focus on one thing and do the best I can, or many things and do them all poorly. Since the scope of the script, right now, is support all genesis figures, I'm already pushing the limits of sanity.

Again, as a seprate issue, it's not a really difficult concept. But the basis of how the script works means adding completely different workflows. It makes it massively more complicated. You can use a butter knife to spready food or as a flat tip screwdriver. You probably shouldn't try to do both at once, unless you are very good. I feel the same way about scripting. You can do a huge number of thingswith it. Safety and sanity suggest not trying to do all of them at once. And as I've said, I'm hacker in the least flattering sense. I can be clever, but I'm not so good as to think I can butter my toast and assemble the bikes at the same time with the same tool.

Ah, sorry, I was thinking about the way the previous script worked, by manually mapping the vertices, in which case it would be a simple matter of excluding unwanted parts of the morph. Obviously, if you consider this at all a risk of feature creep, forget I ever mentioned anything--feature creep is the mind-killer. Good luck with your health issues, I will poke around and see if I've got any extreme morphs for G8's nails that would provide useful data.

Redz

Singular Blues said:

G8 fingernails to G3 would be useful, but they need to be fairly extreme. I can see where the issue is G3 to G8, but I'm having a hard time getting my head around it.

I mean to do some tests myself, so it'll probably be fine. Anything else aimed at G3F as the target may help. Because the core file for that one is ... odd, there's a lot of extra stuff going on just for that target, so I need to get as much data as I can on how it's working.

I've been feeling out of it. Ear infection. I need to package up the fixed prototype script and update the package, but that's not any major change. Just fixing the thing I messed up. I think I'm right on the point of starting the Beta, which means getting G1 sorted, but the fingernails thing is still outstanding. If I'm right about whats going on, there should be similar but opposite effect when nails are sent from G8 to G3. The main issue  I have is that I'm not at all sure if anything can be done about it. It's due to the A pose. I don't mean to say the issue is impossible. It isn't, necessarily. But I don't have the math to fix what's going on, if I the one idea I have doesn't work.

Basically, If I'm wrong, and the G8 to G3 nails work properly, then my fix will work. If I'm right, it won't.

Hi Singular. I've downloaded what I hope is the latest script from your signature, and tested on the two G8M characters I own that have extreme nails. The verbose script works, the basic one throws errors.

The Orc nails look okay but there is indeed an issue with RawArt's Vampyre nail curvature (see pics attached). Hope this helps.

Singular Blues

Thanks. That's potentially a killer.

I'd hoped I was wrong, because if I was, the fix was easy. I'm not wrong, so I need to at least step back to the drawing board, because the nail problem is not solvable within the current frame work of the support files. At least not by me. Again, there is one way but I don't have the math for it.

Redz

Singular Blues said:

G8 fingernails to G3 would be useful, but they need to be fairly extreme. I can see where the issue is G3 to G8, but I'm having a hard time getting my head around it.

I mean to do some tests myself, so it'll probably be fine. Anything else aimed at G3F as the target may help. Because the core file for that one is ... odd, there's a lot of extra stuff going on just for that target, so I need to get as much data as I can on how it's working.

I've been feeling out of it. Ear infection. I need to package up the fixed prototype script and update the package, but that's not any major change. Just fixing the thing I messed up. I think I'm right on the point of starting the Beta, which means getting G1 sorted, but the fingernails thing is still outstanding. If I'm right about whats going on, there should be similar but opposite effect when nails are sent from G8 to G3. The main issue  I have is that I'm not at all sure if anything can be done about it. It's due to the A pose. I don't mean to say the issue is impossible. It isn't, necessarily. But I don't have the math to fix what's going on, if I the one idea I have doesn't work.

Basically, If I'm wrong, and the G8 to G3 nails work properly, then my fix will work. If I'm right, it won't.

Hi Singular. I've downloaded what I hope is the latest script from your signature, and tested on the two G8M characters I own that have extreme nails. The verbose script works, the basic one throws errors.

The Orc nails look okay but there is indeed an issue with RawArt's Vampyre nail curvature (see pics attached). Hope this helps.

Singular Blues said:

Thanks. That's potentially a killer.

I'd hoped I was wrong, because if I was, the fix was easy. I'm not wrong, so I need to at least step back to the drawing board, because the nail problem is not solvable within the current frame work of the support files. At least not by me. Again, there is one way but I don't have the math for it.

Don’t lose hope. It’s a very minor issue that affects only a handful of characters (mostly HD monsters that you can’t transfer the HD details of anyway) I would think you could provide a simple nail correction morph to counteract the curvature in these extreme cases.

Singular Blues

It's a pretty big little thing, tho. This is also the source of the curved arms issue that has impacted every transfer method. I need to find a way to fix it to go from nice free tool to product.

I haven't exactly lost hope. OTOH, all I have is a huge WAG as to how I might fix it.

nonesuch00

Singular Blues said:

It's a pretty big little thing, tho. This is also the source of the curved arms issue that has impacted every transfer method. I need to find a way to fix it to go from nice free tool to product.

I haven't exactly lost hope. OTOH, all I have is a huge WAG as to how I might fix it.

What modeling data did change between G3 & G8? I thought just the eyes & the fingernails.

LOL and doesn't the problem affect toenails or are you telling us those monster models keep neatly manicured toenails? 

If it were possible to exclude transferring of fingernail and toenail morphs consider that maybe?

Singular Blues

nonesuch00 said:

Singular Blues said:

It's a pretty big little thing, tho. This is also the source of the curved arms issue that has impacted every transfer method. I need to find a way to fix it to go from nice free tool to product.

I haven't exactly lost hope. OTOH, all I have is a huge WAG as to how I might fix it.

What modeling data did change between G3 & G8? I thought just the eyes & the fingernails.

LOL and doesn't the problem affect toenails or are you telling us those monster models keep neatly manicured toenails? 

If it were possible to exclude transferring of fingernail and toenail morphs consider that maybe?

It's more fundamental than a modeling data change. It's how morphs work.

Basically all a morph does is tell each vertex "move." Move n units in the X direction, n units Y and n units Z.

It has seemed that it did this based on the vertex normal, but alas, not. It does it on the object or world space coordinates of the un modified figure. So for G3, fingernail extention is mostly along the X. For G8 it is along X and Y. When you do the transfer, this is transfered faithfully to original, not adjusted for the target. So you get nails that move in X on G8 and XY on G3, thus the curve. There's probably a math method to turn rotate these, but the more complex the figure difference, the more rotations are going to be needed, and I don't know that math. Thus both a fix morph or a manual adjustment are probably not going to work. (if you look at the T pose differences between figures, you'll see a lot of rotations that are all going to create artificats.) I have on WAG idea that might solve all of that. If that doesn't work, I can try to look into dealing with each rotation individually, but I'm not seeing that working out. Perhaps in time for Genesis 9.

It's not just the nails. It is the whole arm and whole leg. It's just harder to see the leg effects because the leg rotations are smaller. If my WAG is wrong, then there's not going to be anything I can do to progress in the near term.

murgatroyd314

Singular Blues said:

It has seemed that it did this based on the vertex normal, but alas, not. It does it on the object or world space coordinates of the un modified figure. So for G3, fingernail extention is mostly along the X. For G8 it is along X and Y. When you do the transfer, this is transfered faithfully to original, not adjusted for the target. So you get nails that move in X on G8 and XY on G3, thus the curve. There's probably a math method to turn rotate these, but the more complex the figure difference, the more rotations are going to be needed, and I don't know that math.

For the G3-G8 T-pose to A-pose transfer, it should be fairly straightforward trigonometry.

Singular Blues

Murgatroyd said:

Singular Blues said:

It has seemed that it did this based on the vertex normal, but alas, not. It does it on the object or world space coordinates of the un modified figure. So for G3, fingernail extention is mostly along the X. For G8 it is along X and Y. When you do the transfer, this is transfered faithfully to original, not adjusted for the target. So you get nails that move in X on G8 and XY on G3, thus the curve. There's probably a math method to turn rotate these, but the more complex the figure difference, the more rotations are going to be needed, and I don't know that math.

For the G3-G8 T-pose to A-pose transfer, it should be fairly straightforward trigonometry.

Which is math I don't have. Then there's getting from the Genesis t pose to the G8 A pose.

I'm not saying I couldn't learn. I could. But I'm not going to learn trig tomorrw. Certainly not enough to accurately transpose every vertex transform for both arms and both legs correct across all combinations of 7 figures. On the other hand, if my guess is correct, I need to do one thing. Well, 10 things, but that's better than 42 and an education in math in terms of productivity.

marth_e

The script is awesome. It's understandable that with very extreme morphs the results may vary but that's the way it is. It does a great work with 98% of the other morphs. Nothing in the store is completely perfect. GenX was far from perfect IMHO. That doesn't mean I won't buy it if you sell it. I absolutely will because even with the limitations it may have it's such a usefull tool!!!

I can't wait to try it with G1 and G2.

 

nonesuch00

Singular Blues said:

Murgatroyd said:

Singular Blues said:

It has seemed that it did this based on the vertex normal, but alas, not. It does it on the object or world space coordinates of the un modified figure. So for G3, fingernail extention is mostly along the X. For G8 it is along X and Y. When you do the transfer, this is transfered faithfully to original, not adjusted for the target. So you get nails that move in X on G8 and XY on G3, thus the curve. There's probably a math method to turn rotate these, but the more complex the figure difference, the more rotations are going to be needed, and I don't know that math.

For the G3-G8 T-pose to A-pose transfer, it should be fairly straightforward trigonometry.

Which is math I don't have. Then there's getting from the Genesis t pose to the G8 A pose.

I'm not saying I couldn't learn. I could. But I'm not going to learn trig tomorrw. Certainly not enough to accurately transpose every vertex transform for both arms and both legs correct across all combinations of 7 figures. On the other hand, if my guess is correct, I need to do one thing. Well, 10 things, but that's better than 42 and an education in math in terms of productivity.

Well since I don't need your scripts, just the transforms, you could send me the polygons with their vertex positions for the fingernails for G8 & G3 and I could look at it for you. It's been over 20 years since I graduated with a degree in math but I still have my CRC Math Tables & Formulas book and my Numerical Analysis book. LOL, no promises though. And I go on vacation for a few weeks 27 Feb.

Also what products' links does this happen for as I don't buy vampires & other monsters unless it was a freebie or in some bundle I bought because I would need to test the math one of the problem products.

Singular Blues

nonesuch00 said:

Singular Blues said:

Murgatroyd said:

Singular Blues said:

It has seemed that it did this based on the vertex normal, but alas, not. It does it on the object or world space coordinates of the un modified figure. So for G3, fingernail extention is mostly along the X. For G8 it is along X and Y. When you do the transfer, this is transfered faithfully to original, not adjusted for the target. So you get nails that move in X on G8 and XY on G3, thus the curve. There's probably a math method to turn rotate these, but the more complex the figure difference, the more rotations are going to be needed, and I don't know that math.

For the G3-G8 T-pose to A-pose transfer, it should be fairly straightforward trigonometry.

Which is math I don't have. Then there's getting from the Genesis t pose to the G8 A pose.

I'm not saying I couldn't learn. I could. But I'm not going to learn trig tomorrw. Certainly not enough to accurately transpose every vertex transform for both arms and both legs correct across all combinations of 7 figures. On the other hand, if my guess is correct, I need to do one thing. Well, 10 things, but that's better than 42 and an education in math in terms of productivity.

Well since I don't need your scripts, just the transforms, you could send me the polygons with their vertex positions for the fingernails for G8 & G3 and I could look at it for you. It's been over 20 years since I graduated with a degree in math but I still have my CRC Math Tables & Formulas book and my Numerical Analysis book. LOL, no promises though. And I go on vacation for a few weeks 27 Feb.

Also what products' links does this happen for as I don't buy vampires & other monsters unless it was a freebie or in some bundle I bought because I would need to test the math one of the problem products.

Well, as I said, the major issue is that the arms are affected entirely. That's kinda the thing. I could overlook the arm issue because it is fairly well hidden by posing, but the nails part obviously isn't. Still, if you want to see the best example I know of the issue, you need GenX 2. Transfer 3DU's Kimberly to G3 via GenX2 then transfer her to G8 via the script. You'll see the most extreme example of the over all issue  and just how far up the arm it goes. All of this happeing because the vertexes are shifing at an angle with respect to where they would have gone if they'd been on G3.

I'm going to try my WAG first, tho. Basically because individually rewriting the vert positions of a good 40% of the model would slow it down, and if my wag is wrong I s lose nothing. If it is right, I fix the nails and the arms and the legs all in one go., and I don't need new math for each of the 5 other figures I've trying to support along the way.

nonesuch00

Singular Blues said:

nonesuch00 said:

Singular Blues said:

Murgatroyd said:

Singular Blues said:

It has seemed that it did this based on the vertex normal, but alas, not. It does it on the object or world space coordinates of the un modified figure. So for G3, fingernail extention is mostly along the X. For G8 it is along X and Y. When you do the transfer, this is transfered faithfully to original, not adjusted for the target. So you get nails that move in X on G8 and XY on G3, thus the curve. There's probably a math method to turn rotate these, but the more complex the figure difference, the more rotations are going to be needed, and I don't know that math.

For the G3-G8 T-pose to A-pose transfer, it should be fairly straightforward trigonometry.

Which is math I don't have. Then there's getting from the Genesis t pose to the G8 A pose.

I'm not saying I couldn't learn. I could. But I'm not going to learn trig tomorrw. Certainly not enough to accurately transpose every vertex transform for both arms and both legs correct across all combinations of 7 figures. On the other hand, if my guess is correct, I need to do one thing. Well, 10 things, but that's better than 42 and an education in math in terms of productivity.

Well since I don't need your scripts, just the transforms, you could send me the polygons with their vertex positions for the fingernails for G8 & G3 and I could look at it for you. It's been over 20 years since I graduated with a degree in math but I still have my CRC Math Tables & Formulas book and my Numerical Analysis book. LOL, no promises though. And I go on vacation for a few weeks 27 Feb.

Also what products' links does this happen for as I don't buy vampires & other monsters unless it was a freebie or in some bundle I bought because I would need to test the math one of the problem products.

Well, as I said, the major issue is that the arms are affected entirely. That's kinda the thing. I could overlook the arm issue because it is fairly well hidden by posing, but the nails part obviously isn't. Still, if you want to see the best example I know of the issue, you need GenX 2. Transfer 3DU's Kimberly to G3 via GenX2 then transfer her to G8 via the script. You'll see the most extreme example of the over all issue  and just how far up the arm it goes. All of this happeing because the vertexes are shifing at an angle with respect to where they would have gone if they'd been on G3.

I'm going to try my WAG first, tho. Basically because individually rewriting the vert positions of a good 40% of the model would slow it down, and if my wag is wrong I s lose nothing. If it is right, I fix the nails and the arms and the legs all in one go., and I don't need new math for each of the 5 other figures I've trying to support along the way.

OK, well I'm not going to buy GenX2 but I would buy Kimberly. Hopefully, your solution you are going to try will work.

murgatroyd314

Right off the top of my head (there may be a plus that should be a minus, or vice versa, but I'm pretty sure the basics are correct):

xtarget = xsource*cos(rotation) + ysource*sin(rotation)

ytarget = ysource*cos(rotation) - xsource*sin(rotation)

All the T-poses are close enough to the same angles that G8 should be the only one that causes problems, and the G3↔G8 solution should work for all the other Genises.

Singular Blues

Murgatroyd said:

Right off the top of my head (there may be a plus that should be a minus, or vice versa, but I'm pretty sure the basics are correct):

xtarget = xsource*cos(rotation) + ysource*sin(rotation)

ytarget = ysource*cos(rotation) - xsource*sin(rotation)

All the T-poses are close enough to the same angles that G8 should be the only one that causes problems, and the G3↔G8 solution should work for all the other Genises.

As they say, swoosh.

Okay, I exaggerate. But (and keeping in mind, there are a whole bunch of rotatations for a whole bunch of verticies) I'm not at all clear how to apply this.

And the t poses between Genesises (Genesisi?) are rather different. G3 is really a pretty blatant T, but G2's arms are rotatated slightly back at the shoulder, tilting the thumbs up, and bent at the elbow pretty far. G1 has all that , plus being a bit lowered at the shoulder so the tilt very slightly down, AND have really annoyingly bent fingers that result in all the fingertips being pointed down and off in different directions. I'd need to not only be spoonfed what to do with this set of equations (Again, I exagerate on my lack of understanding. I could in fact, emplement them so long as the functions exist in DazScript, and if they don't, but basic math does, I could probably, maybe, write the functions with the help of google. OTOH, I really don't know trig, so I don't "know" what they say, and thus don't grasp how to use them, per se). Then I'd have to apply that to dealing with all the various rotations (fortunately, there's a place where all those rotations are collected, baring Generation 4, so I at least have that) and be able to deal with things like G1's fingers which are subject to multiple rotations (like dealing with the upper arm is a Y rotation and Z rotation, but the forearm is both of those and another Y, then the hand may be another Y and Z then each finger is a Y and Z then each of the two joints beyond the finger base is a Z rotation and again, each is compounded by all the rotations before it.

Possible? Yes. I won't lie. But can see the headaches. Anyway, my WAG (which was that morph projection used the same logic as Morph Loader) was wrong. Basically, projection takes the nearest vertex (or possibly an average of the nearest verticies) and assigns the same deltas to the target vertex. I got the WAG from an obscure bit of Genesis 8, but the WAG was wrong, in the end. I see what that bit is really doing, and why it ends up working. I was just hoping it was doing soomething else. So I can't trick my way out of it. I have one last idea that might work (exploiting some other insanity that I'm doing already). I'm gonna see about testing it manually. If it works, there'll be a lot of work to do but still a lot less than dealing with all the rotations by math. (That obscure bit of G8 comes in handy in that it reduces the workload compared to the math route.) If it doesn't, I'm not sure what I'll do. I'll definitely keep working the bugs out of the alpha, so there will be a solution for the gap between GenX2 and Genesis 8, but if I keep at the aim of supporting all of Genesis, it will be a good long time before G2 and G1 support happens.

nonesuch00

Murgatroyd said:

Right off the top of my head (there may be a plus that should be a minus, or vice versa, but I'm pretty sure the basics are correct):

xtarget = xsource*cos(rotation) + ysource*sin(rotation)

ytarget = ysource*cos(rotation) - xsource*sin(rotation)

All the T-poses are close enough to the same angles that G8 should be the only one that causes problems, and the G3↔G8 solution should work for all the other Genises.

So what is the value of the rotation(s) variable or are you going to calculate that using the before & after sets of polygons so that you know the value(s)?

Cris Palomino

Singular Blues said:

It's the little things that drive you mad.

If anyone has an idea about how to make DazScript recursively delete folders, I'm all ears. I'm tired of thinking about that.

Anyway, here's a prototype.

The use of this script is different than the old, but it's not massively so. All the old warnings apply. This could break your stuff, use at your own risk, etc. The point is to help develop it so that it is very unlikely to break your stuff.

What's the same?
You still need to load the figure you want to transfer from.
You still need to select a favorite morph to tell the script what to transfer.
It will still transfer ALL the morphs in the same product as the targeted morph.

What's changed?
You now need to load the Target figure. 
Both figures need to be selected when the script is run.
The selection order is important. First select the source figure, then select the target.
The number of favorites is no longer important. The script should transfer all products associated with all favorites.
No more progress bar. No real point. The script moves so fast, there's not a lot of need for it.
The script is part of a system of files, and probably won't work if not installed correctly. It's not hard to install, but it has to be in the primary library (EDIT: Studio and you may disagree about the definition primary. For Studio this is the first library in your list libraries in Content Driectory Manager under DAZ Studio Formats). It depends on that to be able to find all the other bits it uses. nIt's already packaged. Just extract the contents of the content folder into your primary library and all will be well.
It should work with Connect, however, it will not save to the connect library.
EDIT: You must reload the target figure to see the changes. Some morphs will show immediately, but the will not be correctly configured. ATM I can't do that on a loaded figure.

Use it responsibly. Use it in peace.
 

Is this script derived from the samples in the Documentation center? If so you do need to make sure you use them according to the license - which doesn't stop you from writing the script but does require attribution, as explained in the link to the CC with attribution license.

Singular Blues

Cris Palomino said:

Is this script derived from the samples in the Documentation center? If so you do need to make sure you use them according to the license - which doesn't stop you from writing the script but does require attribution, as explained in the link to the CC with attribution license.

The kneejerk answer would be "no." But then one considers what one might mean to be "derived." The DazScript documentation leaves more than a bit to be desired. I'm aware they are an unfunded project, but that means to grasp what much of DaScript does, one must read the samples.

In view of that, the script has been updated to avoid any possible similarity to scripts I've had to examine to get my results. That's necessary. The script in not open source primarily because it will take time to develop and the method it is using would be easy to duplicate. My "intellectual property", as it were, is that I'm the only person I'm aware of who has thought of this method. If the source were open, I suspect anyone interested in the problem would be doing a bit of head slapping. And then doing an end run around my slower speed of production.

Because it is necessary, I've endeavored to comply with a basic reading of the CC3 licence, but the word "derive" is difficult to pin down, and I am not a lawyer. As I read the CC3 this script is not a remix or retread or copy of the samples. It probably goes out of its way to be unlike them. If it didn't, it does now.

EDIT: In related news, the paste error in prototype.dse has been corrected.

agent unawares

If you do use sections of the example scripts in the future, CC BY 3.0 does not require open source or that you be noncommercial, just credit and a link to the license.