Removing old morphs from saved scenes

evacyn

Like a lot of people, I've started to notice that my G8 characters and scenes are taking forever to load so I started uninstalling some morphs I no longer use. However, even after I've removed ~75 characters, I haven't noticed any speed increase when loading my scene files, so I was wondering whether the old morphs are still saved in the project files? If so, is there anything I can do to clean up the files (i.e., remove no longer installed morphs)?

PerttiA

Load the scene and save again.

Bejaymac

The attached image is a small part of a scene file, it shows the morph data for one of my custom morphs, if the morph has been saved to the data folder correctly, then those ten lines are all the morph data you will find in a scene/subset/character/shaping file. Different story if someone has made a total ass out of saving the morph, then you might just have the whole thing in the DUF file.

Long load times mean one of three things

One - to much crap in the data folder for DS to cope with, the more files your scene is loading the worse it gets, and I'm not just talking about character morphs here either.

Two - to much poorly done crap in the data folder, the more errors DS has to deal with the longer it takes, one example - bad parent data in one file sometimes causes DS to stall for a couple of minutes during loading.

Three - a mix of the other two, so dealing with the errors might not dramatically reduce load times.

Only way to find out which is with the log file, a huge list of "Warning" messages in there should give enough of a hint, but checking time stamps on each error for jumps in time of 30 seconds or more, will point to the problem products.

 

 

PerttiA said:

Load the scene and save again.

That's only going to work if they are getting the "missing file" popup in DS when they are loading the scene files.

PerttiA

Bejaymac said:

The attached image is a small part of a scene file, it shows the morph data for one of my custom morphs, if the morph has been saved to the data folder correctly, then those ten lines are all the morph data you will find in a scene/subset/character/shaping file. Different story if someone has made a total ass out of saving the morph, then you might just have the whole thing in the DUF file.

Long load times mean one of three things

One - to much crap in the data folder for DS to cope with, the more files your scene is loading the worse it gets, and I'm not just talking about character morphs here either.

Two - to much poorly done crap in the data folder, the more errors DS has to deal with the longer it takes, one example - bad parent data in one file sometimes causes DS to stall for a couple of minutes during loading.

Three - a mix of the other two, so dealing with the errors might not dramatically reduce load times.

Only way to find out which is with the log file, a huge list of "Warning" messages in there should give enough of a hint, but checking time stamps on each error for jumps in time of 30 seconds or more, will point to the problem products.

 

 

PerttiA said:

Load the scene and save again.

That's only going to work if they are getting the "missing file" popup in DS when they are loading the scene files.

If the morphs were indeed uninstalled, the "missing file" popup should show itself - If it doesn't, the morphs were not uninstalled for real.

Checking the effect on load times vs. the amount of morphs/characters uninstalled is best done with loading the base figure or the developer version into an empty scene and by clearing the logfile before doing so.

For G8F the files that matter are located in;
...\Data\DAZ 3D\Genesis 8\Female\Morphs\...
...\Data\DAZ 3D\Genesis 8\Female\Projection Morphs\...
...\Data\DAZ 3D\Genesis 8\Female Eyelashes\...

The total number of files and the total number of folders seems to have a bigger effect than the overall size of the files, but the biggest effect comes from the warnings for duplicate formulas, missing files and unsuccesful attempts of creating aliases.

evacyn

Thank you both! I'll take another look at the log and see if there's anything there that could be the culprit.