mistressphoenix74 said:

PerttiA said:

Ok, one of those morph files contains the reference to "4-9-20 Azu Upgrade.duf" and it got there when you saved the morph as an asset. Now, as the location is being read when opening or loading any and all characters/scenes with G8F and the morph is then merged with G8F, DS tries to locate that scene file in the location that is recorded inside the morph file, that location is not necessarily the same where the file is stored at the moment.

Since the logfiles do not give better clues to which morph file is the culprit, the only way to find it is using process of elimination - Unhide the folder and move some of those morph files outside the DS Content Library (desktop or some other drive).

If you don't have that many morphs that you have made, try moving them one by one, if you have a lot, move half of them at first and if the problem went away, you know the problem file was amongst the ones you moved. Unfortunately the process takes some time as you should close DS before moving the files and then open it up again to test.

I only have maybe 6 in there right now so it should not be too difficult to find.

Once I locate the morph causing the issue, what do I do then? Delete the morph?

The morph files are text files, either compressed that can be uncompressed with 7Zip or non-compressed which can be opened as they are in Notepad or Notepad++ (Notepad++ is better)

If the morph file is important to you, it is be possible to open it in Notepad++ and remove the reference to the scene file. When you find the one, we can help you fix it.

Deleting the morph file is the easiest solution.

PerttiA said:

Ok, one of those morph files contains the reference to "4-9-20 Azu Upgrade.duf" and it got there when you saved the morph as an asset. Now, as the location is being read when opening or loading any and all characters/scenes with G8F and the morph is then merged with G8F, DS tries to locate that scene file in the location that is recorded inside the morph file, that location is not necessarily the same where the file is stored at the moment.

Since the logfiles do not give better clues to which morph file is the culprit, the only way to find it is using process of elimination - Unhide the folder and move some of those morph files outside the DS Content Library (desktop or some other drive).

If you don't have that many morphs that you have made, try moving them one by one, if you have a lot, move half of them at first and if the problem went away, you know the problem file was amongst the ones you moved. Unfortunately the process takes some time as you should close DS before moving the files and then open it up again to test.

I only have maybe 6 in there right now so it should not be too difficult to find.

Once I locate the morph causing the issue, what do I do then? Delete the morph?

LenioTG said:

Hi everyone! :D

As a content creator, I need to keep many morphs installed, and they dramatically lengthen both the loading and the closing time of Daz studio, to the point they sometimes take MOST of the time I need to create content.
So no, I won't create folders for my morphs and turn them on and off based on what I'm doing, that's not convenient for my workflow. And it's not what this thread is about.

I've already done everything that's in my power to reduce these loading and closing times (uninstalled what I don't need, upgraded to NVMe SSD only library, upgraded my CPU/RAM), and I've actually made a guide about it a while ago, that helped me reduce the loading times by almost 80% (https://www.daz3d.com/forums/discussion/411446/why-does-it-take-so-long-to-load-figures-solved-with-guide/).
Although, they're still pretty long.

So, my question is: "Are you making this a priority, and trying to reduce the lengthening of loading and closing times due to G8 morphs installed?"

Thanks!

I've been experimenting to find options to solve this problem with an easy workflow. One solution I found is to use multiple directory sets pictured in attachment which is a feature I discovered recently.  One set has everything which you can use to create characters, the other is a trimmed down directory that only has the things needed for that scene or commonly used characters.

To get only the files I need for the scene easily without hunting down folders, I use https://www.daz3d.com/content-gatherer.

Eventually I'm going to segregate Figures with morphs from everything else. So I will have one directory for Figures, one for everything else and one that with only what is needed for a scene.

If i want to load everything I will have a directory set with the figures directory and the everything else directory. If I'm animating or doing something that doesn't require every morph I load the directory set with the optimized directory  and everything else directory.

Once you've created your characters that you use often which you only have to do once. The workflow is:

Open content directory manager > Select the optimized directory >load the scene.

If you wan to create a new character which you only have to do once per character:

Open content directory manager > select the full content set > create and save character > drag and drop it in content gatherer and get all the assets to the optimized directory > Then proceed to the steps above for the previous workflow.

Like stated before in the thread something like Fit control's Remove Unused Morph's would be nice to have but this is the next best thing I've found that you can do now.

Ok, one of those morph files contains the reference to "4-9-20 Azu Upgrade.duf" and it got there when you saved the morph as an asset. Now, as the location is being read when opening or loading any and all characters/scenes with G8F and the morph is then merged with G8F, DS tries to locate that scene file in the location that is recorded inside the morph file, that location is not necessarily the same where the file is stored at the moment.

Since the logfiles do not give better clues to which morph file is the culprit, the only way to find it is using process of elimination - Unhide the folder and move some of those morph files outside the DS Content Library (desktop or some other drive).

If you don't have that many morphs that you have made, try moving them one by one, if you have a lot, move half of them at first and if the problem went away, you know the problem file was amongst the ones you moved. Unfortunately the process takes some time as you should close DS before moving the files and then open it up again to test.

In other words, if you look at the parameter settings sub-components and controllers you will see that those are fully populated in advance and you cannot change them without reloading the figure.

Under my proposition, those lists would be pretty much totally empty when you load base G8 character and they would only get populated on demand when you activate appropriate top morphs. This is why loading time would be near to instant (if you load from SSD).

Activating morph for the first time would take some extra time, but not that much because only very few files have to be read and parsed in a very straightforward way. 

This also allows easy installation of new morphs anytime just in the same way as you install new figures, you just refresh the list, new morphs appear and you can apply them.

Ok yeah I kinda agree this should be the approach but not fully. It need to address the following issues:

1. It should be for advanced user only. Why? Because it will break shaping and posing pane. Being able to find all the poses and shapes applicable for the figure is very useful for a beginner. It is also the quickest way to find things when you want to modify a body part. 

2. It doesnt work for dial only shapes or expression. For example Zev0's shape shift are a bunch of shape dials. It is not a character so there is no file to apply it. This goes to reason 3

3. There need to be some way to select contents that should be loaded with base figure. For example, I want the shape shift dial to be populated when I load the base character.

4. This need to be backward compatable with exisitng content. How do you propose to make it backwards compatable with existing contents? At least work with stuff bought via Daz store, custom work is less of a problem.

What you are propossing can already be achieved currently by going around the daz install process and creating virtual file links, but I dont think it is the solution that Daz dev will want to adopt. 

 you just refresh the list, new morphs appear and you can apply them.

This is what I want implemented first, but in a way that is faster and more convinent than reloading the character. Everything else already be worked around.

onix said:

If parsing the file would be a bottleneck then multithreading would be an obvious solution  as I understand bottleneck is the function that populates morph dependencies with appropriate formulas

We are talking about the same thing, Parsing the data from text file and creating formula

No what I mean is if I have a figure loaded and then I unhide a character preset or morph set, I can't use it unless I reload the figure because there is no other way to get new shape dials and pose dials to appear.

This is not a problem because Daz should read all names to get a list of sliders and built all that property tree, It should just not go any deeper and don't loom at their dependencies until something from that tree is activated.

The problem is Daz don't know if a slider is active until it done the work of building all the formulas associated with the formula.

Take this example:

{
    "output" : "neck:/data/DAZ%203D/Genesis%208/Female/Genesis8Female.dsf#neck?center_point/y",
    "operations" : [
        { "op" : "push", "url" : "Genesis8Female:#FHMVictoria8?value" },
        { "op" : "push", "val" : 0.06736755 },
        { "op" : "mult" }
    ]
},

This formula is applies a correction to the base genesis 8 when Victoria 8 is used.The formula is "inactive" when victoria 8 is not used, ie when Genesis8Female:#FHMVictoria8?value is 0.But there is no way for Daz to know the formula is "inactive" until it parsed and created the formula. Daz need to know all the inputs value and output value to workout if the formula is going to have an effect on the character. This is the slow part that we want to address, but it is evident that it is nessasary for Daz to fully process all the formulas when loading the character to work out how the character should actually look and behave. 

I hope it is now clearly established that Daz need to process all morph data to get the correct character look/behaviour because there is no way for Daz to differentiate if a formula is active or not. Just loading the name of the slider is insufficient. Currently we can work around it by hiding morphs we dont need, we need a better process for it but also not too laborious. Like the entire process should only take a few click of button, not a check all the morphs you want to use.  (beside I think scanning all the files looking for name is not an negligble part of the parsing data to create formula work so will still be slow, but not as slow as doing the full work). Like I said, having a way to add load morph package we added after loading a character without having to reload the character would improve this hide morph from Daz process. In a sense it will achieve the delay load morph objective people have been asking.

In a sense this formula is always "active" but just do nothing unless we use Victoria 8. I think this is part of your complaint, but this appears to be the standard way of doing things. Not sure what alternative there is, but I certainly dont want to manually activate each morph required for an character. Any solution need to maintain the current way of automatically apply when it is needed.

I agree its possible to multithread, just the implementation will be non trivial. The issue to consider is: thread 1 load morph A which reference morph B, at the same time thread 2 is loading morph B. How can thread 1 figure out morph B has been loaded or not. Its solvable but care must be take to ensure the solution dont accidentally end up being single threaded. Another issue: thread 1 create morpha A with name X, thread 2 create morph B also with name Y, how does Daz ensure the names are unique because duplicate formula is an issue that need to be detected.

If you look at the morph properties it is not that hard, after all, you can see that every property parameter contains Sub-components and controllers  list which has to be populated, (I think populating that list takes most of the time.)

Agreed, as explained above, the problem is Daz lack a way to indicate to it this morph is not used. The only way we can do it now is to hide the file from Daz.

I can't see any problems with multithreading because every entry in that list is independent. You load a morph and then add the appropriate formula to the appropriate list the order of how things will be added to the list does not matter.

Except the list is stored all over the place and generating the list is the slow formula creating process. Take the above example, neck:/data/DAZ%203D/Genesis%208/Female/Genesis8Female.dsf#neck?center_point/y is in one file, Genesis8Female:#FHMVictoria8?value is in another file, the formula that use it is in another. Daz would only get all the infomation it need after it processed all the formulas in all the files.

It is the parsing of all the files that is slow, that we want to multithread, but notice how the formulas is not independent, it require an input that can be another formula from somewhere else. This is where multithreading is wanted but difficult to implement.

https://diffeomorphic.blogspot.com/p/morphs-section-version-15.html

I imported the facial morphs through'Import Units' referring to the above document and they worked fine.
But the problem is that the eyebrows don't move along the morph.
(The same goes for eyelashes.)
How can I fix this?

I have read the documentation below, but I don't have'Easy Import DAZ'.
The version in the document is 1.6, but the current version is 1.51c.

http://diffeomorphic.blogspot.com/2021/03/easy-import.html

j cade said:

then how is what you are describing anything different than how things currently work? unless I am manually turning on those jcms one by one, what you are describing is exactly how things currently work - 'aiko_smilejcm' doesnt get dialed by 'smile' unless aiko is dialed in - otherwise it sits at zero

 

and while loading happens eveytime you load a character that is still many many many many les interactions than anytime a jcm gets dialed since what you were describing before sounded like you wanted to make those more manual that would be for me hundred to thousands of times per session if that becomes even slightly more manual any loading speed increase would be absolutely irrelevant compared to the vast increase in time i would have to spend adjusting exra dials

The only difference is that now Daz just loads all files it can find in the morph directory and then spends lot of time processing them and establishing all those dependencies because it is a big mess and nobody knows what controls what

Under my proposition, every file must contain references to all subcomponents and so if you load any file anytime you will also load all its subcomponents if necessary without any need to search for them. 

Because there is no such requirement now. Aiko vendor does not bother to "register" all the stuff he uses, he just throws up a bunch of correction morphs into the Aiko directory and expects that Daz will pick them up and establish all dependencies automatically

im just very confused by what system you are trying to explain. earlier you said

This formula  injects extra logic that if you turn on the default Daz provided "angry" expression  AND if you turn on Dandelion slider at the same time the  Dandelion-Angry morphs will be activated

but then

Aiko or Girl vendor would be responsible that the Aiko head slider will turn on appropriate correction morphs. [...] but content vendors now have to care that they will activate appropriate JCMs when that is necessary.

what is the difference between these two. functionally what difference are you seeing between "if you turn on the default Daz provided "angry" expression  AND if you turn on Dandelion slider at the same time the  Dandelion-Angry morphs will be activated"

and

"Aiko head slider will turn on appropriate correction morphs" as those will also only need to be on if whatever theyre correction morphs for are turned on.

 

Both sound like systems where jcms are only turned on if the correct 2 conditions are met.

yes, as you see there is no difference for the user, JCMs get turned on either way under the same conditions. 

However, now Daz has to scan all files and build those dependencies, and under my idea vendors manually register JCMs and correction morphs telling Daz under what condition they have to be loaded 

In other words, if you look at the parameter settings sub-components and controllers you will see that those are fully populated in advance and you cannot change them without reloading the figure.

Under my proposition, those lists would be pretty much totally empty when you load base G8 character and they would only get populated on demand when you activate appropriate top morphs. This is why loading time would be near to instant (if you load from SSD).

Activating morph for the first time would take some extra time, but not that much because only very few files have to be read and parsed in a very straightforward way. 

This also allows easy installation of new morphs anytime just in the same way as you install new figures, you just refresh the list, new morphs appear and you can apply them.

onix said:

j cade said:

quick q. lets say I dial spin a character made with the Girl, Bette, and Aiko and a couple other head morphs all characters with large eyes that require jcms to close correctly. under your system how do I now close the eyes?

 

My load time for the genesis figures could be 5 times as long as it is and I'm pretty sure this would still be slower. I only have to load once - having to dial everything specifically for every character expression every time I wanted to change it would add up astronomically

 

For you, it would all work the same as now. You would turn on those JCMs with Girl or Aiko head sliders. Aiko or Girl vendor would be responsible that the Aiko head slider will turn on appropriate correction morphs. maybe you would have an extra slider along with other Aiko properties which say "Aiko expression correctors" but it would turn on automatically as a subcomponent as "Aiko head". and you would be able to turn it off if you decide that you don't want it.

From the user side, no functionality is lost at all. and no extra tinkering required but content vendors now have to care that they will activate appropriate JCMs when that is necessary.

 

Loading, unfortunately, happens more than once every time you add an extra character to your scene it takes the same amount of time. also, it affects your posing performance so you are working slower.

Just do the test and temporarily move all morphs from the morph directory away then load G8 character and you will see how incredibly fast and responsive it becomes you even can use IK  as it works instantly.

then how is what you are describing anything different than how things currently work? unless I am manually turning on those jcms one by one, what you are describing is exactly how things currently work - 'aiko_smilejcm' doesnt get dialed by 'smile' unless aiko is dialed in - otherwise it sits at zero

and while loading happens eveytime you load a character that is still many many many many les interactions than anytime a jcm gets dialed since what you were describing before sounded like you wanted to make those more manual that would be for me hundred to thousands of times per session if that becomes even slightly more manual any loading speed increase would be absolutely irrelevant compared to the vast increase in time i would have to spend adjusting exra dials

im just very confused by what system you are trying to explain. earlier you said

This formula  injects extra logic that if you turn on the default Daz provided "angry" expression  AND if you turn on Dandelion slider at the same time the  Dandelion-Angry morphs will be activated

but then

Aiko or Girl vendor would be responsible that the Aiko head slider will turn on appropriate correction morphs. [...] but content vendors now have to care that they will activate appropriate JCMs when that is necessary.

what is the difference between these two. functionally what difference are you seeing between "if you turn on the default Daz provided "angry" expression  AND if you turn on Dandelion slider at the same time the  Dandelion-Angry morphs will be activated"

and

"Aiko head slider will turn on appropriate correction morphs" as those will also only need to be on if whatever theyre correction morphs for are turned on.

Both sound like systems where jcms are only turned on if the correct 2 conditions are met.

j cade said:

quick q. lets say I dial spin a character made with the Girl, Bette, and Aiko and a couple other head morphs all characters with large eyes that require jcms to close correctly. under your system how do I now close the eyes?

 

My load time for the genesis figures could be 5 times as long as it is and I'm pretty sure this would still be slower. I only have to load once - having to dial everything specifically for every character expression every time I wanted to change it would add up astronomically

For you, it would all work the same as now. You would turn on those JCMs with Girl or Aiko head sliders. Aiko or Girl vendor would be responsible that the Aiko head slider will turn on appropriate correction morphs. maybe you would have an extra slider along with other Aiko properties which say "Aiko expression correctors" but it would turn on automatically as a subcomponent as "Aiko head". and you would be able to turn it off if you decide that you don't want it.

From the user side, no functionality is lost at all. and no extra tinkering required but content vendors now have to care that they will activate appropriate JCMs when that is necessary.

Loading, unfortunately, happens more than once every time you add an extra character to your scene it takes the same amount of time. also, it affects your posing performance so you are working slower.

Just do the test and temporarily move all morphs from the morph directory away then load G8 character and you will see how incredibly fast and responsive it becomes you even can use IK  as it works instantly.

Richard Haseltine said:

Better for whom? Certainly not most users who would be trying to find the right corrective morphs, once they realised that was what was needed. Espeically if they were using expression presets and didn't know immediately which expression they should be correcting. This type of function is a long-standing, and expected, feature.

There is no need to look for specific corrective morphs manually. all current functionality can be fully retained with the only difference that all those morphs are turned on and loaded only when the appropriate character is turned on.

And if not they are neither loaded in memory neither they can even potentially affect anything at all.

People are likely to have and use the expressions (and in fact, many expression packs use the base expressions). People will expect them to work, hence the inclusion of fixes. Adding a slew of fesh expressions for each character would not be a practical solution.

There is no need to lose that functionality but I am quite sure many people do not even know that it is being done. so the least that should be done is to mention this in the character description that it contains correction morphs.

Also, most vendors do not use fixes and release separate expression packs.

But why would you want breakage to be the default behaviour? And how would an extra ERC controller help reduce load times?

You do seem to be labouring under a slight misapprehension, though - nothing is injected into the default expressions in this case; rather the corrective morph has two links, one to the default expression and one to the head shape, one of which will add its value and the other of which will multiply (so the net value is head shape strength * expression strength, ensuring the correct amount of adjustment is applied).

Just because it would be much faster and reduce memory usage significantly.  In that situation, all morphs have to be processed just top-down and there is no longer any need to even care or load any dependencies for morphs that are not in use. Broken-buggy content no longer can harm anything and it becomes easy to identify.  This extra ERC controller essentially would act as an index to indicate what else has to be loaded and when it has to be loaded. (Now Daz just loads everything because it can't know what it should load and when.)

Of course, I do not expect that anyone will go so far as to make changes that will beak half of the existing content so it is just theoretical thinking on how things could be done in the beginning. and I even brought it up because I was not fully aware of how things work. The current system where Daz just loads everything is simpler because vendors do not need to track their morphs either and they can just create some Correction morph and drop it for Daz to process. That alternative system would require them to track everything they do and apply appropriate changes. 

So looks like we are quite doomed to live with this forever.  The best thing to expect now is maybe some kind of cashing so that rather than processing all this list of morphs every time, daz could just save the entire structure and just look if anything changed in the directory.

Also, it would be possible to create those extra erc controllers automatically as it is not that hard to look up for correction morphs that are referencing some common property to index them for faster loading (and that index file also becomes extra erc controller which consolidates all those morphs ) but later ask all vendors to do things in another way when they generate those index files themselves. or just give an option to regenerate those index files from time to time when new content is installed.  This way none of the current functionality would be broken. 

Maybe my terminology was inaccurate because I meant that extra formula is injected into the expression controller making it do some additional calculations every time it is used.

if such a link is added, extra CPU time will be consumed to perform all those extra checks. 

It turns out it was the transfer utility that would do what I needed. 

Hi everyone its me again I need help with Morph Loader Pro my first time. I want to create a custom morph for my Gen8 "Basic Wear - Tank top" and did some exporting from Daz to Blender (this is the confusing part). I have all the models namely - Genesis 8, Tank Top set at "Base Resolution" and did apply all the "Shader Mixer" for Genesis and Basic Wear Tank Top. Afterwards I tried to export them to Blender as .OBJ one by one @ 1% scale. So I went to the blender(2.92) to import the .OBJ one by one and this is how it looks like and then began doing some minor movements to the TanK Top (no vertex deletion) see the photo reference. Afterwards I delete Genesis just to make sure that it dont get exported and proceed to export the Tank Top with the scale of "100", on Daz3d again on the tank top using morph loader pro but after applying the morph it came out weird. Need help please if someone can correct or direct me to a  proper way of doing the custom morph on Daz4.15 would really appreciate the help, did try alot of things but still the morphs came out weird its really a let down for me. : (

PerttiA said:

First make sure that DS is not running, then if you start from the base folder of your content library in Windows Explorer (File Explorer) and navigate to;

...\data\DAZ 3D\Genesis 8\Female\Morphs\

Do you remember the name under which you have saved your own morphs?
That name is the name of the folder that contains morphs and characters that you have saved as assets. Choose that folder and right-click to get a menu, choose "Properties" and change the attribute to "hidden" - Some have said this is enough to hide the morphs in that folder from DS and if it does work, it's easy to change back.

Now with the morph folder hidden, start DS and when it's open go to "Help->Troubleshooting->View Log File", select everything and press "Delete", close the logfile and choose "Save" when asked.

Load the "Genesis 8 Basic Female" and once it has loaded, open the log file again and save it somewhere you can easily find.
Did DS complain about the missing file?

If DS still complained, attach the log to your post with the "Attach a file" under the "Leave a Comment" window, that way we can have a look at it.

I found where my morphs were, hid the folder and when I loaded a base Genesis 8, the error did NOT happen. So, it's an issue with the morphs inside that folder? Or, the lack of a morph as it were? I've attached two log files. log is the one with the morph folder hidden. log2 is with the morph folder not hidden.

I'm still super confused on why DAZ is saying it's missing a scene though. ><

onix said:

Richard Haseltine said:

Consider a simple example, a figure with big, round eyes. The morphs for cl;osing eyes are set up to work with the base shape of the eyes, something that chnages the shape or size will not combine well with that - there would probably be a gap with the closing morph at 100%, and there would probably be overlap at the edges if the morph was dialed to a value sufficient to close the eye fully in the centre 9because the rounding will increase the separation there more than at the edges). To make sure that users get the expected result when closing the eyes the creator will add an additional morph that can be applied when both their character and the closure morph are set, so the that eyelid is then properly down, and the ERC makes sure that that additional morph is applied when needed. The Dandelion character https://www.daz3d.com/dandelion-fae makes some marked chnages to the ehad shape, so there are a lot of extra morphs to make the basic expressions look right.

Yes I understand that this may be useful, but there is a better way to do it by adding extra morph which you turn on manually rather than automatically.

And also if default expressions don't work he can just provide his own list because it is quite possible that I will not even use basic expressions at all but use some other expression pack that is totally unaffected by those corrections. How anyone even can be aware that such corrections are taking place?

Even If it is required to do  ERC this can be initiated with an extra controller which has to be turned on by the user or can be turned on from another morph.

rather than injecting itself into the basic expression controller author could just add an extra controller which turns on an extra correction morph if both character and Daz expression controller are turned on.  this way the need to load all files is avoided because turning on dandelion character tells Daz that now it has to load all those correction morphs that are referenced by this character.

The main idea of this principle is that to implement any kind of correction vendor has to add his own controller which turns that correction on and nobody can inject my corrections into any other vendor content without asking the user to turn those corrections on in some way.

(I this situation they can be turned on by turning on the character slider which would also tell Daz to load all  those corrective morphs)  

This looks so obvious and logical that I always thought that it is how things work in the first place and could not understand why all morphs have to be processed

It was a big surprise that Daz even allows that kind of stuff.

quick q. lets say I dial spin a character made with the Girl, Bette, and Aiko and a couple other head morphs all characters with large eyes that require jcms to close correctly. under your system how do I now close the eyes?

My load time for the genesis figures could be 5 times as long as it is and I'm pretty sure this would still be slower. I only have to load once - having to dial everything specifically for every character expression every time I wanted to change it would add up astronomically

onix said:

Richard Haseltine said:

Consider a simple example, a figure with big, round eyes. The morphs for cl;osing eyes are set up to work with the base shape of the eyes, something that chnages the shape or size will not combine well with that - there would probably be a gap with the closing morph at 100%, and there would probably be overlap at the edges if the morph was dialed to a value sufficient to close the eye fully in the centre 9because the rounding will increase the separation there more than at the edges). To make sure that users get the expected result when closing the eyes the creator will add an additional morph that can be applied when both their character and the closure morph are set, so the that eyelid is then properly down, and the ERC makes sure that that additional morph is applied when needed. The Dandelion character https://www.daz3d.com/dandelion-fae makes some marked chnages to the ehad shape, so there are a lot of extra morphs to make the basic expressions look right.

Yes I understand that this may be useful, but there is a better way to do it by adding extra morph which you turn on manually rather than automatically.

Better for whom? Certainly not most users who would be trying to find the right corrective morphs, once they realised that was what was needed. Espeically if they were using expression presets and didn't know immediately which expression they should be correcting. This type of function is a long-standing, and expected, feature.

And also if default expressions don't work he can just provide his own list because it is quite possible that I will not even use basic expressions at all but use some other expression pack that is totally unaffected by those corrections. How anyone even can be aware that such corrections are taking place?

People are likely to have and use the expressions (and in fact, many expression packs use the base expressions). People will expect them to work, hence the inclusion of fixes. Adding a slew of fesh expressions for each character would not be a practical solution.

Even If it is required to do  ERC this can be initiated with an extra controller which has to be turned on by the user or can be turned on from another morph.

rather than injecting itself into the basic expression controller author could just add an extra controller which turns on an extra correction morph if both character and Daz expression controller are turned on.  this way the need to load all files is avoided because turning on dandelion character tells Daz that now it has to load all those correction morphs that are referenced by this character.

The main idea of this principle is that to implement any kind of correction vendor has to add his own controller which turns that correction on and nobody can inject my corrections into any other vendor content without asking the user to turn those corrections on in some way.

(I this situation they can be turned on by turning on the character slider which would also tell Daz to load all  those corrective morphs)  

This looks so obvious and logical that I always thought that it is how things work in the first place and could not understand why all morphs have to be processed

It was a big surprise that Daz even allows that kind of stuff.

But why would you want breakage to be the default behaviour? And how would an extra ERC controller help reduce load times?

You do seem to be labouring under a slight misapprehension, though - nothing is injected into the default expressions in this case; rather the corrective morph has two links, one to the default expression and one to the head shape, one of which will add its value and the other of which will multiply (so the net value is head shape strength * expression strength, ensuring the correct amount of adjustment is applied).

I have bought many of Polgyonal Miniatures stuff on other marketplaces, but i think it's ridiculous that Daz thought it was a good idea to put such a product on the store without even the bare minimum of packaging it as a figure/prop asset with a material preset.  Not to mention they didnt even bother to rig it with transfer utility for you.  It would have taken them five seconds to do that for you. Crazy.

Anyway, to answer your question: You can add the texture maps to their respective slots of the shader on the Surfaces tab.

By the looks of things, it has a Normal Map and a Base Color map.  So just browse to where the files are located on your system and either drag-drop them into the Base Color and Normal Map slots on the shader or alternatively import them via the Surfaces tab.

imo, turn glossy roughness up high.

Richard Haseltine said:

Consider a simple example, a figure with big, round eyes. The morphs for cl;osing eyes are set up to work with the base shape of the eyes, something that chnages the shape or size will not combine well with that - there would probably be a gap with the closing morph at 100%, and there would probably be overlap at the edges if the morph was dialed to a value sufficient to close the eye fully in the centre 9because the rounding will increase the separation there more than at the edges). To make sure that users get the expected result when closing the eyes the creator will add an additional morph that can be applied when both their character and the closure morph are set, so the that eyelid is then properly down, and the ERC makes sure that that additional morph is applied when needed. The Dandelion character https://www.daz3d.com/dandelion-fae makes some marked chnages to the ehad shape, so there are a lot of extra morphs to make the basic expressions look right.

Yes I understand that this may be useful, but there is a better way to do it by adding extra morph which you turn on manually rather than automatically.

And also if default expressions don't work he can just provide his own list because it is quite possible that I will not even use basic expressions at all but use some other expression pack that is totally unaffected by those corrections. How anyone even can be aware that such corrections are taking place?

Even If it is required to do  ERC this can be initiated with an extra controller which has to be turned on by the user or can be turned on from another morph.

rather than injecting itself into the basic expression controller author could just add an extra controller which turns on an extra correction morph if both character and Daz expression controller are turned on.  this way the need to load all files is avoided because turning on dandelion character tells Daz that now it has to load all those correction morphs that are referenced by this character.

The main idea of this principle is that to implement any kind of correction vendor has to add his own controller which turns that correction on and nobody can inject my corrections into any other vendor content without asking the user to turn those corrections on in some way.

(I this situation they can be turned on by turning on the character slider which would also tell Daz to load all  those corrective morphs)  

This looks so obvious and logical that I always thought that it is how things work in the first place and could not understand why all morphs have to be processed

It was a big surprise that Daz even allows that kind of stuff.

Well, is the OBJ export using one or is it set to Custom? What happens if you export the morph OBJ as an object, does it come in at the same size as an import of the original prop's OBJ?

I lost several of my own characters a few weeks back during a data transfer to a new SSD (not my fault), and I've been trying to recreate her ever since. But nothing is going right.

If I can't recreate her in 3D, I might go back to trying to recreate her in 2D.