Best way to speed up Genesis X & big libraries?
mambanegra
Posts: 586
So, my old SSD was getting close to being full and Genesis 8 F was taking forever to load, so I purchased a decent sized NVMe to house a runtime primarily to house the data in hopes that it would speed character loading, but it doesn't seem to have helped (it could be that windows is interfering with the load times while it does some indexing and things may improve when that is done).
So, the question is what are people doing to make these figures with tons of content more usable? I'm aware of several alternatives, none of which really sound great to me:
1) Delete -- Yeah, there are things I really don't need...but it takes time to find them and it's such an extreme solution
2) Create minimal runtime with only necessary morphs and basically make the complete runtime optional by deleting it from the preferences/content manager. Again, extreme but I guess not too crazy. I guess the biggest problem is that, to make this work, you really have to bake all those tweaks into the characters you want to reuse which is a few different steps. I haven't tried this, and but it seems better than #1.
Are there any other options?
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
So, after letting things settle down, the load time went from just short of 7 minutes (base Genesis 8 Female) to 4 minutes and 15 seconds. So, I did get a nice little boost. Still longer than ideal, though.
What frustrates me the most, as a software developer, I know this problem isn't really necessary. They could have a simple file that contains outcome of scanning that data directory for all of those files and simply loads it if it exists. When new content is added, that file could be deleted or, for folks who install content from non-DAZ sites a simple menu click could delete the file for them (ideally, each figure would have it's own cache file, so if you install new Gen 8 Female content, but no changes were made to Gen 8 Male, then the male cache would remain and be reused. I imagine the problem isn't really a problem for most DAZ Studio users, but there are obviously a lot of us that have huge libraries and, for us, it is a very real problem.
This has been discussed here over and over again, and there is very little to do about load times of Genesis x figures when theres a ton of morphs installed, drive speed has just negligible effect which is why many are using external USB drives for bigger capacity.
Just about the only thing you can do to speed up the loading without deleting characters/morphs, is to get rid of the errors/warnings in your log, some of them will add quite a lot to the loading as DS is trying to figure out what to do with them.
Help->Troubleshooting->View Log File
Sadly, nothing you are saying here is new and, even more sadly, is the fact that nothing is likely to change. The DAZ studio team seems to be working under the assumption that the user base is constantly upgrading to more powerful computers and faster graphic cards, so there's no reason to make provisions for older systems, and this accelerated through the roof when Iray became the default renderer. That said, one of he biggest single issue with loading is that with Genesis ALL of the morphs that the user has installed have to load up every time before it can go any further... and since any facial expression that has a parameter dial is at least partially a morph, just getting rid of all of the ones except for a core base of the ones that you actually use will usually give your load ins a major kick in the pants.
Yeah, except my NVMe card only shaved off 30% of the load time (compared to a SATA SSD drive), so I don't think they expect the issue to go away with new machines (plus, my machine is only a couple of years old and was pretty powerful back when I bought it). The issue has impacted some of my spending. I've become much pickier about characters I'll consider and pretty much ignore expression sets unless there is something particularly interesting there even when they are 1.99 or less. So, from a business perspective, this is a problem for both DAZ and their PAs.
I really do think it's a perfectly solvable problem, and I imagine what I described above wouldn't be particularly difficult to implement, however, I don't know anything about how their software is laid out, so that's purely guesswork on my part.
Pretty much why I put on hold getting any new characters. I like my loading times not taking dozens of minutes.
TBH, unless new characters are either ethnic or non-human, Daz toons usually recycle the same so it's not a huge sacrifice.
I had about 900 G8F characters plus a ton of morphs packages installed with DIM (not using Smart Content / Connect, only Content Library) in a 1.5 TB DS library. With that it took over 5 minutes to load a G8F, and that's on 10 year old hardware with a Core2 Q6600, 8 GB DDR2 RAM. I've now uninstalled most of the characters (but not the morph packages) so there's currently 199 installed, and G8F base loading time is now down to about 2 minutes.
Just for a comparison. If it takes half an hour or more to load a character on equal or more powerful hardware then there must be issues other than the default performance of DS, probably related to defective characters or other products.
There are already cache files for the characters, but essentially they are just a collection of the morph files, still in their original format (sans the morph deltas). If they were compiled versions, DS would not have to do the same work over and over again with every character that's loaded - But that is not how the system currently works.
I'd really like to see a script, similar to Fit Control's 'remove unused morphs', for Genesis X. Basically, once you've finalised a character, unused character and shaping morphs are removed. You then save the character as a Character or scene subset.
Whether the script could be clever enough to determine which JCMs to keep (if in same parent folder as used character/shaping morphs?) is the biggest issue I can imagine. There would have to be some kind of flag in the file that tells Daz to 'Load all available morphs' or 'Just load morphs listed in this file'. This could be set by a checkbox in the Character/Scene Subset save options. It would be practical, from the user's perspective to save the character twice - one with and one without morphs removed, in case you need to edit later or create variations.
So, it sounds like I'll need to go the route where I have a "All Content" runtime that is only used for character creation and "bake" my character into a single dial that is saved in a regular runtime. From what I've seen, to do this, there are a few steps that are required to create the morph, then applies some ERC fixes. Is there a product that does this in a single click? I'm lazy:)
Have you checked your log for warnings and errors?
There are a handful of references to products I don't own listed, but that's it. No duplicates or whatever. The problem is entirely my studidly large amount of content. It's probably mostly the result of these 1.99 sales :O
If it's truly finalised, no updating needed for any reason, you could use File>Save As>Support Assets>Figure/Prop Asset. You'd then have to cancel the AutoFit dialogue when loading clothes etc. but it should work (obviously, test before committing
It has very little to do with system specifications, it's just that when there are a lot of property links (it has nothing to do with whether they are morphs) it gets progressively slower. The system has worked well for Genesis, Genesis 2, and Genesis 3, but Genesis 8 - perhaps due to a mixture of its longer life giving it more proeprties and people getting more ambitious in what they want to achieve when setting them up - has exposed its limitations. It is/was a good design, it gave the flexibility of the old ExP system without having to run an updater (and as I recall Victoria 4 wasn't without its load-time issues by the end). I'm sure daz is looking at the issue, but we need to be aware that there are competing pressures - load/close time is one issue, but people want an easy and flexible way to add characters and morph packs too; reconciling those is extremely non-trivial, however it may look to those with experience in other fields.
For me, we're reaching a point where the flexibility of the systems don't justify the load/close times any more. Maybe my personal workflow is highly atypical, but I'm not using character-specific sliders to customize characters very often--I'm sure some percentage of users do this constantly. The frequency of complaints about load times leads me to believe that the cost/benefit ratio no longer favors having every character or morph pack I own available as a (probably unused) slider.
Every business that develops or sells software applications has to consider both what the ever-improving state-of-the-art is for their type of application, and the specifications of the machines owned by potential users/purchasers of those applications. Obviously, developing content that is obsolete upon release isn't good, but developing stuff that can run on too small of a slice of the potential market is an even bigger problem.
Two things to consider:
1. We're keeping our machines longer. I bought my first PC in the 1990s. I bought a new machine about every 24 months, and I often added RAM or changed the graphics card. Now, I expect to get at least 48 months, and maybe 72 months, out of either a desktop or laptop, and I will probably never upgrade the hardware of my current machines.
2. My students (mostly in their 20s) were raised with the constant use of devices (especially phones and tablets) which lack the specifications and capabilities of a high-end desktop. For them, features like portability and cost take priority over performance (and even features like screen size, adequate internal storage, and a proper keyboard). Now, I'm not suggesting that Daz Studio become a phone app, but I am saying that assumptions from 25 years ago about ever-improving capabilities of the end user's devices aren't valid now. There will always be some market share for high-end applications, but that share won't necessarily be the largest and almost certainly won't be the most profitable.
It's not the number of morphs, per se. The problem is that Daz runs some things asynchronously, one of which is "fit". You can continue to pose while it runs in the background. Sweet, right? Well, when you merge into a scene, you sometimes get an infinite loop. Try this. Take a figure that takes a long time to load. Unparent all your clothes and then save all of them as a Scene Subset. Create a new scene, then merge the subset in. Fast. All the morphs are still there, they just aren't firing all at the same time during loading and forcing the others to fire, then it reacts, forcing the others to fire. Ever see the "drop a ping pong ball into a cube filled with mouse traps" explanation of how nuclear fission works? I wish there was a global switch "Pause All Fit" you could turn on while loading.
It is not, as you have been told numerous times in the past, a loop. it is probably at least in part that morphs used on the figure do not have custom support on the fitted items, so morphs have to be projected into the clothing.
If you use Connect you can of course install and unisntall inside DS - and if you haveuninstalled a character or morph set that you need when opening a scene or applying a preset DS will let you know and ofer to install it (for Daz store content).
There is no fitting to anything when loading a Genesis 8 Basic Female/Male into an empty scene.
This has a lot to do with the fact that the process is single threaded.
Have a look at performance monitor while it is loading your character, you will see that there is only one CPU thread working hard at the time.
I dont know if there is a technical reason for it being single threaded, other than multithread support just not being implemented yet, but the process would be orders of magnitude faster if it could actually use more than a small portion of your CPU's potential to get the job done
As far as I am aware the dependencies prevent the process from being multi-threaded.