Why does G8F take FOREVER to load?
n.jmurov
Posts: 89
in The Commons
DAZ 4.15-4.16. Takes up to 10 minutes to load the vanilla G8F character. There are tons of memory and disk space available, and generally I have a very powerful gaming machine. Custom characters that I save as Scene Subsets also occasionally take a long time to load but nowhere near as long as the G8F.
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
https://www.daz3d.com/turbo-loader-booster-utilities
are supposed to help alleviate this issue. But I haven't tried them, so perhaps someone else can share their experience and say how well they work. Might be worth watching for a good price during the holiday sales.
True. G8F is just no fun without lots and lots of morphs.
It does not explain a few things, though, e.g. why it takes so long to load the vanilla G8F specifically but much less for G8F-based characters. They have the same morphs.
.
You're lucky. It takes about 45 minutes for me with all my morphs and characters. Turbo loader can reduce time but then you choose which morphs and characters you want to load and if you're spontaneous like me and like to have a lot of morphs available to work with, it's still frustrating. I picked a bunch of morphs and characters that I felt essential, which was still a LOT, so it now only takes about 15 minutes to load but I feel frustrated I can't spontaneaously use ALL my morphs and characters. The more morphs and characters you own, the longer it will take. And I discovered through Turbo Loader that many Z pose packages contain a lot of extra morphs so you'll have to disable those too to get a faster G8 load time.
45 minutes is insane! and I'm also very spontaneous. My solution to slow software performance has been to get really powerful hardware and until a couple of months back, I was not having any memory issues at all. But there's something clearly weird that's been going on lately. Things have been taking much longer to load, with that G8F being the champion.
Check your logs! If you have any products that are causing duplicate forumlas then it will drastically slow the loading time to the figure. I managed to speed up my loading times the other day by fixing a product that was spamming my logs with duplicate forumla errors due to using a stupid value for the unique id.
I do get duplicate product warnings every time, but I have no idea how to resolve that. I also get a "migration failed' warning first, wait about 45 minutes, then get a pop up that says duplicate formula found, click OK, then it finally loads. I've sent several tickets to CS with the log, they wait a month or so then close the ticket. I've given up on them helping me.
The first character scene subset (mats/hair/clothing already included) I load takes about 20 seconds. Loading a duplicate takes about 3 minutes. Each successive duplicate thereafter seems to increase load time exponentially. Strangely, if I restart Daz and load a scene subset with, say, 5 characters - this takes about 2.5 minutes.
What is irritating is that there's no apparent activity from Daz whilst it's loading - after the initial SSD/HDD activity it will sit there, at a steady 2% or so cpu utilisation, with ram usage slowwly increasing.
Long story short, a lot of morphs will adversely affect load times but there’s still something apparently wrong with the way Daz loads assets.
Well, I will not name-names, but when I was researching into the product that was causing my issues I saw that several threads had been complaining about it and it had reported to CS as early as April - and yet I was still having issues with it in December. Therefore, the only possible assumptions I could take away from that is that either CS was not forwarding the error to the PA or the PA has no interest in fixing their product. I am aware that duplicate formulas are caused by "ID clashes" and while it has been said (quite fairly) that it's not possible for all PAs to always pick unique values, the IDs for this product were incredibly-poorly named and so there was no excuse there (IMO).
Here are the steps I took to resolve this issue myself. Please note that I am not an expert so this was very much a "bull in a china shop" approach, however it seemed to resolve the log-spam & load times while nothing "visibly" broke. Also, there is the caveat that if you amend a morph file this might also break other morphs that use/link it - in my case it was a set of expressions and so it seemed unlikely that there would be a linked chain of files.
Important: take a backup of any files before you edit them and only change them if you feel confident updating JSON files without breaking the syntax.
Again, please note that the above is very much a hack-job and so if you do follow them you do so at your own risk (so do not ignore the bit about making a backup copy first). One or two of the above steps may not entirely be necessary and there is a chance that there is also a step or two that I am missing but this worked for me.
Obviously, in an ideal world, these things would be fixed properly by Daz QA or the PA themselves, but like with the "//Runtime" issue it currently does appear to be a thing we have to fix ourselves.
'Wow, thanks, but that looks really complicated. For now, could you let me know which known products have these issues so I can just uninstall them?
Yeah, unfortunately it's not quite simple to self-fix and probably a little off-putting if you are not technically-minded.
Also, it's not quite so simple to provide either a global list of products that cause duplicate formulas or to even tell from the logs which products are in conflict. Mainly because the logs only point to a file (and so you would then need to workout which product that file is part of) and also it only lists the second file that is in conflict - the first file is not mentioned anywhere.
It is probably possible to write a script to do this but I haven't yet had time to delve into Daz scripting myself. For my own issue I never even got round to locating the first product that was clashing - I just fixed the second one.
However, if you want to attach your log to this thread I can take a look at it and see if I can figure out one of the products from the error messages? Might be tricky if it points to a product I don't have tho.
Thanks, I'm starting up DS now and have to disable Turbo Loader (which still has the same errors with less characters) and load a G8 which can take a WHILE...
It also takes DS a long time just to start and takes like 10 minutes to load all the products I own. I just realized it was updating metadata from Connect so I logged out. I may have duplicate products installed through Connect. How do I uninstall anything that's installed through Connect?
@Wonderland, just thought of a plan B if you wanted to try and disable the errors yourself. In Turbo Loader you can search for the morph that is throwing the error and uncheck it from there.
For example, in my previous example if the duplicate formula line listed the file "data/DAZ 3D/Genesis 8/Female 8_1/Morphs/PUBLISHING_ARTIST_NAME/PRODUCT_NAME/MORPH_FILE_TRIGGERING_CLASHES.dsf" then you could then put MORPH_FILE_TRIGGERING_CLASHES in the Morph search box and hit enter and that would give you the item to disable.
Again, that will only give you the option of disabling the second of the two products with a clash but perhaps allows you to have some control over managing this?
I just added to my last post while you were posting this. DS was updating metadata through Connect so I must have several items installed through Connect which maybe leads to duplicate formulas. I logged out of DS and now all products are in the wrong order but how do I uninstall all Connect items/?
Yeah, having Daz Studio able to connect to the internet just seems to break stuff unfortunately. You'll want to specifically uninstall all products that Daz Connect thinks is installed and then reinstall them dia DIM (or Central I suppose). Working out which products to uninstall is the tricky part. It's been a while since I have done that and I know how to find them by connecting directly to the CMS using a PostgresSQL client but again that is a route for someone who is comfortable with such things.
It might be possible to find them within the filesystem, however as I don't have any Connect products installed this is a bit of guess-work: See if you can find a folder called "My Daz Connect Library" - for some reason on my machine this is in the Documents/DAZ 3D/Studio folder. In there you can ignore the files in the data/cloud/meta subfolder as those are Connect's updated metadata and not related to Connect installs. However, if there are any other files/folders in there then I think that will be what you are looking for to tell you what products Connect has installed. If you find any references to a product in there then try and uninstall that product from within Daz Studio and the file/folder should hopefully disappear which means you are on the right track.
Thanks, I will try that. For now I logged out and set it up so it won't connect me automatically. I'm now not getting the Migration Failed notice but it's already been 30 minutes and G8 still has not loaded. Just says reading asset... I'll check the log after it finally loads...
I heard fhe other day that having multiple libraries can also slow down the loading as its has to search each library for files. Just what I heard. I only have one library, i dont use smart content and despite all my characters and morphs, it takes up to 30 seconds for my G8F to load.
It's now been 1 HOUR and G8 is still loading! I disconnected from the internet and am no longer getting the Migration Failed notice but it seems to be taking even longer! The other folder only has G9 stuff, should that make it slower?
The potential issue is that, given a relative path from a scene or content file (e.g. /data/daz 3d/Genesis 8/female/genesis8female.dsf - that may not be correct, just going from memory to give an example) DS will have to add that to each Content Directory to generate an absolute path, see if it exists, then try with the enxt content directory until it finds the file or runs out of directories. So with a large number of directories to check (DS warns of potential issues at ten) files in the later directories, or with bad paths, may take a while to process. When loading an asset with geometry DS will also have to check the base path (/data/daz 3d/genesis 8/female/) for morphs, UV sets, and other additions so again that can have a bit of a speed impact. Still, for a low number of additional directories the impact should be relatively small - especially compared with the time taken to hook up the links between properties, which tends to be the real killer.
So now it's been an HOUR AND A HALF and it just got to the pop up that says duplicate formulas found and now going through a whole other section loading eyelashes and tears and now stuck on that.
After 5 minutes of that, there is just the Windows timer thing. I'm still waiting for it to actually load.
It's been 10 minutes now with just the Windows timer thing now, still no G8. This is even slower than when I was logged in.
I have to leave the house now. It's been 1 hour and 50 minutes and it still hasn't loaded. Hopefully it will by the time I get home. This is ridiculous! How can I fix this?
!
Well, the time to load will be massively dependant on hardware and number of morphs aswell as how many clashes and other errors you might have but that seems way too excessive. I don't have the logs from when I still had my own issues anymore to get the exact times but I would still put it at below 10 minutes - this is with almost 13.5K Total Morphs according to Turbo Loader. Now that I cleaned up all the duplicate formulas I have just timed the load to 1m 39s.
For that amount of time I would suspect you are either hitting a massive load of clashes/duplicates or Daz Studio has just given up at that point.
While DS is still busy you can still view the log file by opening it directly. It should be in the C:/Users/USERNAME/AppData/Roaming/DAZ 3D/Studio4/log.txt. If you can open that file and scroll to the bottom you can see what it's currently upto.
EDIT:
That is indeed ridiculous. Hopefully the log.txt file will be very illuminating and provide some answers. If you can attach that (if the forum will let you attach an upload today) then I (and hopefully some smarter users too) can take a look at it and give you some pointers.
EDIT 2:
Although for me it's 11pm so I might not be able to have a look at it till the morning.
So Richard you'd say that having a directory on a HD compared to a faster SSD isn't really going to make much difference with load times because nearly all of the lag is DS looking up links. I think this has been discussed before and you are correct. The only caveat from my experience being that HDs can go to sleep and take several seconds to spin up. This wouldn't affect a model's initial load time much, but when adding stuff to scenes it can be annoying and happen multiple times slowing things down.
Just tested it with a new empty scene. The original G8F took about 4 minutes. A custom G8F saved as a sub-scene - the file is pretty large, hundreds of Mb's - took under 2 minutes to load.
...does not actually seem to depend on the file size - the largest G2F custom character I've got, close to 1 Gb, loads in slightly over a minute.
Under a minute for me
I just got home and checked and somehow DS had added a whole bunch of directories from my C drive that I had never put there! Directories from One Drive, a bunch from users. There were several hundred duplicate formulas! I removed those within DS and will remove everything from my C drive. Hopefully this will fix things.
Oh dear, that sounds like it would definitely be adding to your slow-loading woes. Hopefully if you sanitise that situation you'll atleast have a more sensible load time and can look to improve things further from there.
I am no expert with OneDrive - I actively try and avoid using it since it seems to work backwards (IMHO) - but it seems to "absorb" everything in the Documents folder by default and that is where Daz Connect installs it's data and so I imagine that this would not be good for efficiency. When Daz Studio is launched there is a check to see if anything new is installed and if it's in a location outside any of your base directories it does throw up a little prompt to ask if you want to add it, probably easy enough to accidentally just click accept which will then add a new base folder. Also, never tried loading DazStudio in a multi-user setup on the same machine - so if the app configuration is not coded to cope with that then I can imagine it could get messy with base folders from multiple users - which may then slow things down if there are access/permission issues coming in to play?
I HATE ONE DRIVE! I wish I could figure out how to disable it completely. I think at one point I tried to uninstall it but Windows wouldn't let me. It never asked for permission to do anything and just added any new downloads to it automatically. I thought I had directed it to an external hard drive but apparently it's still adding stuff to my C drive. I don't want it to add anything anywhere. I had a ton of stuff in the Connect library although I had never clicked on anything to download. I trashed the whole folder and am hoping that helps. I'm only going to use DS in offline mode from now on. A bunch of stuff was in my C drive in user documents, got rid of that. DS seems to have a mind of its own installing things where I don't want it. In DIM I directed everything to external hard drives including the app itself which is on an external SSD drive but stuff keeps ending up on my C drive!
Open up Task Manager, go to the "Startup" tab, right-click on Microsoft OneDrive and click Disable.
Ah thanks! I was a lifelong Mac person until I got into DAZ Studio and iRay. Will that disable it completely?
File size is pretty negligible - it will load into ram as fast as the storage it is on can deliver it. It's the processing Studio has to do afterwards that is the real timesink.