What makes loading/writing assets slow to a crawl?
kgrosser
Posts: 141
With a x3700 Ryzen, 64Gigs of RAM, a 1080Ti my machine should probably not be dconsidered "bad". But even if system, programs and DazLibrabry on dedicated NVME SSDs saving (and loading) scenes takes somewhat 15minutes easily. the same if I load a character in place of another one - DAZ studio takes ags "loading assets" (and writing on save) albeit the resource manager shows no memory/CPU/stprage activity. Any clues highly appreciated.
Another issue enccoutnered is frequent CTD in iray preview (single window on a 4K screen) due to a "neuraylib" error, but, first things first....
Comments
Loading is usually down to building the ERC links between all the morphs, and is geernally proportional to the number of morphs installed (the links have to be established even if the morphs aren't used). Saving may depend on content - if you have a dForce simulation then the position (or for playrabnge simulations the postiions) of each vertex have to be recorded - in the absence of simulations, or other large batches of embedded data such as custom morphs, imported models, or custom weight maps, I woudl usually expect saving to be faster since it needs to write only the local values of proeprties and doesn't care about their influence through links.
In addition to richards explanation.
Scene complexity plays a factor.
The more assets, the longer the load time. When i say 'asset' that's everything in the scene, characters, geographs, clothing, hair, props, sets, lights, everything.
LIE, Layered image editor, presets also take longer to load as the software has to rebuild the texture maps each time.
Thanks if that info holds true it is in fact very disturbing. This basically implicates DAZ not really being suited for larger libraries, effectively compromises the attraction of investing into such, and consequently, the whole business concept of DS as a free programm and purchasable content.
Correct me if I'm wrong but as each charakter inserts head, body and full morphs and so do expression sets etc. and so the sheer presence of products in ones library despite being in use inevitably slows down the program to a crawl spending money in effectively degrading your performance is not what I deem an incentive.
Now, I understood ACTIVE morphs could slowdown loading and saving, why I just set out to creating single morphs instead of for my character presets (that in my case are heavily kitbashed with PLENTY of morphs). Based on this information it seems a futile undertaking and the only way out of this mess was to crate my characters on a machine with a full library and do the scenes on a crippled installation?
But, then again, If I build a comparable scene with the same count of characters, but basic it should give the same load and save times, and that's definitely not the case.
Yes, each character you buy slows down Daz Studio loading of even the base character of that generation. I quit purchasing all but truly unique characters/morphs once I learned that fact. I agree that is is not an incentive to buy! There are some threads in the forum where people talk about uninstalling a lot of morphs for this reason.
You wouldn't necessarily need to use a separate machine, DS does support content directory sets so you could have one with a full installation and one with a more limited instalaltion (they can each have their own database). With Daz content, if DS is allowed to connect to the net, it would even offer to install needed products if you opened a scene saved from a fully loaded set in a session using a restricted set.
Thanks again, seems I need to readjust my strategies then.
The fact you need to do this points to a very big problem in the software design.
@Richard Haseltine, I have slept over it, yet when I woke up I found the elephant still comfortably sitting in the middle of my bedroom.
While I may accept (as in "will have to") the fact that ERC morphs will be created for ALL morphs for ALL different morphable objects in the scene, it doesn't answer why the horsepower of my computer is not put to use in even the slightest way to speed this up? I literally see no RAM,HDD or CPU load during that process - quite contrary to when DS for unexplainable reasons decides to not use iray although the scene easily would fit into the VRAM according to the log. DAZ seems to trickle on a thread not optimized for the task the program appears to have hardwired into its guts.
Not every task lends itself to multi-threading. rendering does, very efficiently, so it can easily eat all your CPU cycles.
Completely understood. However, I don't even see considerable load on any core during loading and saving, even if I tie DS to certain cores it does not really seem to compute in the meaning of the word.... very confusing.