no said:

I'm trying out the Daz to Unity script and while it's useful, there's a few major issues which I think the dev team (and users) should be aware of.

 

The importer generates way too many materials! The importer should combine any materials which use the same texture maps. For example, on a G8 figure, Face+Lips+Ears+Eyesocket can be combined into one material. Also, Mouth+Teeth, Arms+Fingernails, and Legs+Toenails. Realtime assets should use as few materials as possible, so it's very silly to have so many unneccessary duplicates.

 

In the import settings, "Blend Shape Normals" is set to "calculate". This is very bad! This will cause unwanted changes to the normals across the entire mesh any time a blendshape dial is used. Just look at any figures ears while turning up a dial to see what I mean. "Blend Shape Normals" should be set to "None".

 

The script allows the export of JCMs, but there doesn't seem to be a way to have them be automatically driven by the figure's pose inside of Unity. Are there plans to include a JCM driver script in a future version of Daz to Unity?

Limits on bone rotations would also be very useful for posing.

I've also noticed that every selected morph is exported for every item. This is very wasteful of resources. We do not need JCMs on eyelashes and hair, for example. Or upper-body morphs on pants, etc. Please give us the option to select which morphs we want to export for each item that is attached to the figure. This is probably the biggest issue with the addon, because there is no way to remove blendshapes after importing.

Thanks very much for your feedback!  There are plans to do duplicate material merge as well as many other game optimization operations.  JCM drivers are also planned, but may be a little further out, since it would involve developing an efficient "runtime module" that is incorporated into the end-user game executable rather than just scripts which are run in Editor-only mode.  Regarding exporting of all morphs, we are aware of the issue.  Unfortunately, it is more difficult to solve in the short term.  For many reasons, the Daz Studio FbxExporter is currently being treated as a black-box for DazBridge development.  In the longer term, that and many other things will definitely get overhauls.

felis said:

Here are 3 images:

1: Shirt just fitted

2: Shirt fitted, followed by dForce simulation

3: Shirt fitted, breast (here character) dialed in during the timeline, and done dForce simulation

And if wanted, you could export the last, and import it as a morph for the shirt.

Would you mind explaining point 3 in more details, for total dummies like me, please? 

Here are 3 images:

1: Shirt just fitted

2: Shirt fitted, followed by dForce simulation

3: Shirt fitted, breast (here character) dialed in during the timeline, and done dForce simulation

And if wanted, you could export the last, and import it as a morph for the shirt.

Hey Fellow Daz entousiast !

i'm following the tutorial here (https://www.deviantart.com/3dstrobist/journal/Transfering-Mixamo-Animations-to-Daz-Genesis-8-1-906594358) to import mixamo animation into Daz and apply it to a G8 model, but when I try to execute the script from this tutorial to fix the messed up rotation, i get this error:

it seems that the script is not able to grab t2 (the genesis 2 model)

here is the script if you dont need to go through the tutorial:

<span style="color:inherit"><em>function transferY(a,b){</em></span>

<span style="color:inherit"><em>var t8,t2;</em></span>

<span style="color:inherit"><em>t8=Scene.findNodeByLabel(a);</em></span>

<span style="color:inherit"><em>t2=Scene.findNodeByLabel(b);</em></span>

<span style="color:inherit"><em>var valr=t2.getYRotControl().getValue ();</em></span>

<span style="color:inherit"><em>t8.getYRotControl ().setValue (valr); </em></span>

<span style="color:inherit"><em>}</em></span>

<span style="color:inherit"><em>function transferX(a,b){</em></span>

<span style="color:inherit"><em>var t8,t2;</em></span>

<span style="color:inherit"><em>t8=Scene.findNodeByLabel(a);</em></span>

<span style="color:inherit"><em>t2=Scene.findNodeByLabel(b);</em></span>

<span style="color:inherit"><em>var valr=t2.getXRotControl().getValue ();</em></span>

<span style="color:inherit"><em>print (valr);</em></span>

<span style="color:inherit"><em>t8.getXRotControl ().setValue (valr); </em></span>

<span style="color:inherit"><em>}</em></span>

<span style="color:inherit"><em>var nframes=Scene.getAnimRange().getDuration ().valueOf()/Scene.getTimeStep().valueOf();</em></span>

<span style="color:inherit"><em>for( var fr = 0; fr &lt;= nframes; fr+=1 ){</em></span>

<span style="color:inherit"><em>Scene.setFrame( fr );</em></span>

<span style="color:inherit"><em>transferY(&quot;Left Thigh Twist&quot;,&quot;lThigh&quot;);</em></span>

<span style="color:inherit"><em>transferY(&quot;Right Thigh Twist&quot;,&quot;rThigh&quot;);</em></span>

<span style="color:inherit"><em>transferX(&quot;Right Shoulder Twist&quot;,&quot;rShldr&quot;);</em></span>

<span style="color:inherit"><em>transferX(&quot;Left Shoulder Twist&quot;,&quot;lShldr&quot;);</em></span>

<span style="color:inherit"><em>transferX(&quot;Left Forearm Twist&quot;,&quot;lForeArm&quot;);</em></span>

<span style="color:inherit"><em>transferX(&quot;Right Forearm Twist&quot;,&quot;rForeArm&quot;);</em></span>

<span style="color:inherit"><em>} </em></span>

thank you in advance for your help!

lou_harper, I'd try:

https://www.daz3d.com/sy-clothing-breast-helper-genesis-8-female

and

https://www.daz3d.com/sy-universal-breast-helpers-genesis-genesis-2-and-genesis-3-female-s

These are not the same as Sickleyield's Clothing Morphers.  Completely different set of sliders.  Can help with both the "no bridging between the breasts" and the "too snug below the breasts" aspects of the shrink-wrap problem.  Almost certainly less time-consuming than running a dForce simulation or export/import to other apps.

Looking at your sample renders, I think it's unlikely that dForce will really help.  The shirts would need to be looser fitting to begin with.  If the fabric is already stretched tightly over a body part, simulating gravity or air resistance isn't going to do that much.  

I'm trying out the Daz to Unity script and while it's useful, there's a few major issues which I think the dev team (and users) should be aware of.

The importer generates way too many materials! The importer should combine any materials which use the same texture maps. For example, on a G8 figure, Face+Lips+Ears+Eyesocket can be combined into one material. Also, Mouth+Teeth, Arms+Fingernails, and Legs+Toenails. Realtime assets should use as few materials as possible, so it's very silly to have so many unneccessary duplicates.

In the import settings, "Blend Shape Normals" is set to "calculate". This is very bad! This will cause unwanted changes to the normals across the entire mesh any time a blendshape dial is used. Just look at any figures ears while turning up a dial to see what I mean. "Blend Shape Normals" should be set to "None".

The script allows the export of JCMs, but there doesn't seem to be a way to have them be automatically driven by the figure's pose inside of Unity. Are there plans to include a JCM driver script in a future version of Daz to Unity?

Limits on bone rotations would also be very useful for posing.

I've also noticed that every selected morph is exported for every item. This is very wasteful of resources. We do not need JCMs on eyelashes and hair, for example. Or upper-body morphs on pants, etc. Please give us the option to select which morphs we want to export for each item that is attached to the figure. This is probably the biggest issue with the addon, because there is no way to remove blendshapes after importing.

There isn't a special tool that allows PAs to CREATE HD morphs; that can be done in any modeling software. What PAs do have is the ability to import them into DS as morphs. The Morph Loader that you and I have access to will only import morphs at base resolution. 

kyoto kid said:

....this is the statement from the product page:

Note - This product does not transfer HD Morph Detail higher than Base Resolution.

So it sounds like you just can't use higher HD settings (though there is also Render HD)

Isn't Disco Bob his current script partner?  

Crikey if I had any appreciable skill at modelling I'd consider doing it myself but I don't and modelling "organic" forms is more difficult  than "hard" ones.

Also don't have ZBrush so no way to do sculpted morphs.

Even if you made the morphs yourself, you as an end user rather than a PA would have no ability to import the morphs into DS. If you were feeling particularly adventurous, you could export your scene to Blender, make the morphs there, and then render your scene in Blender. 

There are many other products which end up in Lost and Found. I make it a habit to cruise Lost and Found, and just go in the Category edit screen, find the product/articles, and uncheck them, and then make a category and check into the category I want. Gives a lot of flexibility and so much easier than wrangling a ticket or the metadata directly. I try to do this after each download, so I don't forget the original product. I find the Lost and Found most often goes by the Title given to a product, which is awkward to find, if you can't remember was it "Boho" or "Dark Ishkabibble" or "Glamourous Night" or "Night of the Iguana" or "Leslies Lovley Gala".  I tie all such products togeter in a Category of my own making that I can remember, using the root product. Doensnt hurt the product, the metadata, or title, just forms an easy search term in Smart Content. If I had asked for tickets on all the products I have found in Lost and Found, I could have clogged up the ticket system.

AprilYSH said:

Richard Haseltine said:

The file in the support folder should be present and the same for all packages as I understand it,

That's missing entirely from the 2nd zip. It's not the only product I see it missing, I just checked a few multi part products in my DIM downloads folder... BUT it isn't a problem for these other products because their subsequent zips mostly contained texture images, no user facing dufs.  I don't know if QA are told/required to copy the support dsx across all zips.

and if it were missing from one (so that it wasn't actioned) reimporting the metadata from the other package should fix the issue

Yes, I believe North did that but other users might not know this workaround, so still need to fix at the source. :) 

 I did an informal check of multi-part products in my collection, and found most had only one metadata file, in the first part, by a margin of about 4 or 5 to one. If it is a standard, it is not being applied very well. Personally, I am against repeating information, in case, for some reason, they diverge.

There are some cases, though, like with older Poser and StudioCF files where user-facing content must be included in each part of the product. Sometimes there is one metadata file in the Companion file, sometimes it is in both, and sometimes, when in both, they are different. But, those were early days, so maybe the process wasn't clear.

PerttiA said:

NorthOf45 said:

Connect? Never had it, never will

You have always had it and will have it until DAZ decides to remove it (unlikely to happen).

DAZ Connect is the one inside DS and integrated into DS and if one is logging into DS, that is all DAZ Connect needs to start messing with the metadata. 

 Oh, I know all about that. The first thought I had was the old 7-UP commercial. Crisp and clean, no caffeine, nevah haddit, nevah will...

Richard Haseltine said:

The file in the support folder should be present and the same for all packages as I understand it,

That's missing entirely from the 2nd zip. It's not the only product I see it missing, I just checked a few multi part products in my DIM downloads folder... BUT it isn't a problem for these other products because their subsequent zips mostly contained texture images, no user facing dufs.  I don't know if QA are told/required to copy the support dsx across all zips.

and if it were missing from one (so that it wasn't actioned) reimporting the metadata from the other package should fix the issue

Yes, I believe North did that but other users might not know this workaround, so still need to fix at the source. :) 

But the metadata isn't in the manifest, it is in the /Content/Runtime/Support/ folder in the zip - the manifest in the zip just lists the included files and what to do with them. The file in the support folder should be present and the same for all packages as I understand it, and if it were missing from one (so that it wasn't actioned) reimporting the metadata from the other package should fix the issue - unless the paths were wrong in the package (or the metadata) in which case, as I said above, orphaned files don't get entered at all.

I am not quibbling over what is being seen or needs to be chnaged - just trying to avoid any misunderstanding of what it represents and why it is an issue.

Sounds like the database is missing metadata, should fix itself if you refresh metadata for the database.

NorthOf45 said:

Connect? Never had it, never will

You have always had it and will have it until DAZ decides to remove it (unlikely to happen).

DAZ Connect is the one inside DS and integrated into DS and if one is logging into DS, that is all DAZ Connect needs to start messing with the metadata. 

Richard Haseltine said:

The .djl files are meant to get their metadata, and everything else, from, the file to which they are pointing.

Yes, the djl files are not meant to get metadata directly - djl are irrelevant in the Smart Content tab anyway, they are "shortcuts" (asset links) for use in the Content Library tab.  Actually assigning compatibility metadata to djl files caused a lot of problems with my past products resulting in most files getting dumped to lost and found (as discussed originally in this thread.)  Since those were removed the metadata has behaved properly. ---> If anyone hasn't checked for updates to my past products, please do so :) 

All packages should ahve the same metadata, when it is process only the entries matching files instaled from the current zip will be added to the database as part of the instyallation or reimporting of metadata - otherwise there would be no guard against bad data entering the database.

So if zip 2 had the identical metadata dsx in it as the complete one present in zip 1 this wouldn't have happened.  That's a good point but not reliable during packaging as seen here (and evidenced by the auto-generation of the missing dsx file!)  So I think making sure all user facing duf files are in the primary zip is a good way to hedge my bets ;)  

The .djl files are meant to get their metadata, and everything else, from, the file to which they are pointing.

All packages should ahve the same metadata, when it is process only the entries matching files instaled from the current zip will be added to the database as part of the instyallation or reimporting of metadata - otherwise there would be no guard against bad data entering the database.

For me if i import a charater into blender 2.97 for example i get the rigify rig and expressions and shapekeys. If i then save the file and open it in blender 3.1 the control rig and shapekeys are intact but it will no longer show the expressions pannel.

If i import a character straight into blender 3.1 i get shapekeys and expressions but not the rigify rig functions. 

if i import the character into 3.1 to get all the shapekeys and expressions  and then try to pair it with the rigify rig from 2.97 the facial expressions disappears again. 

I assume due to some update on blenders end to rigify but i cant figure out how to get around it. 

NorthOf45 said:

Okay, that worked out. I just moved the "Ursula Hair Genesis 3 Female.duf" and its two thumbnail files, and the folder icon file, into their own "People\Genesis 3 Female\Hair\Ursula Hair" folder in the first archive, and updated the manifest to make sure they got installed (and removed them from the second archive and its manifest). The rest of the files I left in place in part 2. No second metadata file was generated by part 2 when installed, so no impact on the metadata from part 1. G3 Ursula Hair's metadata was complete (Content Type, CompatibilityBase, etc.). Loaded a Genesis 3 Female and Smart Content showed Ursula Hair as compatible. Ursula Hair showed its materials and shaping presets as compatible, so I would say: all clear.

Well that was interesting. I didn't know DIM generated that part 2 support metadata dsx - seemingly because there was a user facing file (not counting djl files) in the second zip, even though the first zip had the complete metadata.  Plus I thought that auto-generated dsx happened because I logged into Connect (the usual suspect.) 

I have done as you did and moved the g3f duf to zip 1 and will request Daz to update it this way.  I will note it for future products also, to have all user facing files in one zip, ie the first zip, which tends to contain the complete DazQA-made metadata.  It seemed to be an issue with that autogenerated dsx but so long as there's a preventive measure I can deal with this. :)

Thanks very much @NorthOf45 for your troubleshooting and isolating the cause of this issue! 

Okay, that worked out. I just moved the "Ursula Hair Genesis 3 Female.duf" and its two thumbnail files, and the folder icon file, into their own "People\Genesis 3 Female\Hair\Ursula Hair" folder in the first archive, and updated the manifest to make sure they got installed (and removed them from the second archive and its manifest). The rest of the files I left in place in part 2. No second metadata file was generated by part 2 when installed, so no impact on the metadata from part 1. G3 Ursula Hair's metadata was complete (Content Type, CompatibilityBase, etc.). Loaded a Genesis 3 Female and Smart Content showed Ursula Hair as compatible. Ursula Hair showed its materials and shaping presets as compatible, so I would say: all clear.