Regardless of a complete character or base character, if you load a Genesis X character all morphs for that generation are loaded or at the very least indexed at the time of loading.
I probably have expressed myself unclearly, my apologies.
If you are loading the file yourself, and have all the morphs/assets actives, then yes.
If you have disabled the assets/morphs, either with the "change extension" method or tools like turboloader, then the situation changes.
In that situation (disabled morphs), especially if using the tools, the fact the file contains only the information about the morphs effectively used, means DAZ+tools will load only the morphs you left active and the ones required by the file, nothing more, and the difference in loading time, can be a monster.
One could obtain the same effect without the tools, but I admit either one can script/program DAZ well enough (not my case), or doing the equivalent of those tools by hand, could take enough time to offset the advantage of keeping stuff disable and only enable the ones needed.
Well, it depends, thousands of assets ago, I had already reached the situation where DAZ could take almost one hour to load the basic G8F or a file, though also due to errors, the more assets and morphs, the more probable there will be also errors, so, even opening a DUF for a character and find the non-base things needed, maybe would have taken less time
.
In other words, turbo loader (and anything similar, I only refer to it because is the one I know and use) can work only because in reality DAZ has already something (its scripting, and the ways it creates its save files and loads them) that does not require you to load everything in the library all the time when you are opening a file or loading a character.
Why DAZ did not put make that kind of functionality/behaviour available from scratch, instead of having to get an additional product to get it ?
Hypothesis, maybe the building block are there not specifically for that reason, DAZ Support itself hinted they never thought about people having a very big (maybe huge ?) library.
Also, making the loading and unloading of morphs more dynamic is not impossible, but would make the programming much more complex.
At the moment, in practice the loading and unloading is linked to the scene, if you create a new scene after you have disabled the morphs/assets, then the scene and the character loaded in it have only the active morphs and is faster (well, depending on the quantity of morphs enabled/disabled, and the errors with the active ones, most often disabling two morphs does not help).
Effectively, even turbo loader indicated that when one is inside DAZ, if just activated morphs with turbo loader that you had disabled before and want to use them, one should create a new scene - but then they added a "merge" and a "load" that can activate and add the assets without requiring to create a new scene, though still with some limitations.
In practice, it seems rather than clearing the memory for each morph, they allocate the memory for the scene when they create it, and allocate the memory for all the possible (active) morphs for the character, then, when the scene is eliminated and replaced by a new one, they can free the allocated memory by using the pointer to the memory area allocated before when they created the scene.
I don't know (never checked, and will not) what language they used to create DAZ, but that would seem to correspond well with the behaviour, even with the turbo loader, and some indications from the DAZ support - the new functions added to turbo loader do not really contradict the indication, I have in mind a way in which they could have implemented it.
This is well documented behavior, all over the DAZ forums with workarounds on how to speed up character loading, which work with varying effectiveness. Having tested this myself, there basically is no time difference in loading a custom character that you create, Victoria, Base Genesis, PA created character or even a character that is saved as a Scene Subset. As long as there are
Yes, I can see what you mean, and I am not completely disagreeing, but I can see you are talking about a installation not using tools and non fully optimised.
The only reason for the "not completely", is because even without the full optimisation (and in part even with it, for some things I did not want to disable), if at the extreme you used hundreds of assets and morphs in a file, or you used only a few, you will see anyway a difference (practica experience), because DAZ will nonetheless need to load all the assets and set the value for all the morphs that are not at default (in theory, 0, though we know some do not respect that rule
)
The basic solution given, time after time, is to put your DAZ library on an faster storage media. Generally SSD vs HDD. This doesn't address the actual issue but it makes it more tolerable. At the minimum, placing the DAZ database on fast storage media can have some effect on load times also.
Actually, the DAZ support itself suggested also to reduce the library, and install only what needed (maybe to avoid adversitising tools like turbo loader, or saying that you can disable by changing the extension), basically installing and removing.
Using SSDs was also mentioned, but they admitted with a library of thousands of assets (much less than now, but still, I think I was already above 12k at the time), it was not going to be a real solution alone.
The simple truth is that I like DAZ, but the base tool was never meant to have a huge library - the database used is PostgreSQL, which is a workhorse and can deal with TB of data without a sweat
, but DAZ is a different matter, without additional tools, it is
100% agree with these last statements, but I can't vouch for DSON Editor or Turbo Loader. I use multiple libraries, one that is stripped down to a bare minimum and load times are very fast. But I have heard very good things about both those products.
I can. I have already experience using them, especially good with Turbo Loader and its utilities (bought license), that I use all the time.
On the computer I am using at the moment, I have 2 libraries on 2 disk, a total of ca 5.37 TB of assets and morphs, 25302 assets installed (counting only the ones loaded with DIM, most packaged or repackaged by me), with a number more (a few hundred) waiting to be packaged and installed.
In general I avoid the kind of "who has the bigger one" :-D stuff (though considering the forum we are on, it is kind of fitting :-D), but I still have to find someone with a bigger installed library.
No, I did not "download" ;-) or download (there is free stuff that is really free) all of them, and some I converted from other formats.
Effectively, I tended to use the discount/bargains/"prime" and stuff like that to keep it cheap, but I realised over the years I ended up spending a lot in assets :-(, I guess the money I did not spend during COVID to go out and to travel, ended up for a good part spent in assets
- but that, is a different matter.
These two libraries in reality come from another computer which is on another location, where I had three libraries on 3 hard disks - converted to the two disks, so I can carry them between computers, without bothering reinstalling, I just have to copy over the files for DIM, DB, some DAZ files, keep a base of consistency in the installation directories, and make sure the two disks get the same letter when connected to the different computers (which have the same OS).
Daz searches with relative paths without the hard disk letter when loading morphs and assets (can see it in the logs), a smart move from them, but in the studio configuration and the DIM configuration, the disk letter matters (and in DIM, you can see it does use the disk letter).
It requires to be a bit careful, but it does work, and should hopefully continue to work for some time.
It will depend on how DAZ will change the application, though in any case from the way they announced it, no intention to move to the next major release.
They did not like a post of mine raising a concern, but they admitted themselves all the utilities and add-ons will need at least a recompilation with new libraries to work with the new version.
There is no guarantee that the new libraries will be 100% retrocompatible with the code of those add-ons, thus not requiring a partial rewriting.
And even if they were, there is no guarantee of not having the risk that when they recompile to be compatible with the new DAZ version, the add-on/tools do not ask to buy a new version (tried to ask about that risk, that was what pissed them off
).
Have fun !!
