When you first load a new Genesis 9 figure please go to currently used and see what morphs are listed. You said that new figures are still malformed and that shouldn't be the case. There is a morph that is loading when it shouldn't be.

Havos said:

Cybersox said:

Torquinox said:

Is it fair to say all the shooting stars items have been g9 characters?

Specifically, they're all been morph-only characters with no original textures, just presets to reuse the base Geneis 9 materials. 

Do they include any bend correctives? If not, even 2.99 seems a bit steep. I have not bought any of them so far.

Not sure about bend correctives, but agreeing on the steep, regardless. The morphs themselves seem kind of... off, and hastily done. With a new one every day, I suppose it's quantity over quality, but there are full G9 characters in QG for less than that. 

Cybersox said:

Torquinox said:

Is it fair to say all the shooting stars items have been g9 characters?

Specifically, they're all been morph-only characters with no original textures, just presets to reuse the base Geneis 9 materials. 

Do they include any bend correctives? If not, even 2.99 seems a bit steep. I have not bought any of them so far.

Cybersox said:

Specifically, they're all been morph-only characters with no original textures, just presets to reuse the base Geneis 9 materials. 

I didn't look that closely. Good to know! Thanks!

Torquinox said:

Is it fair to say all the shooting stars items have been g9 characters?

Specifically, they're all been morph-only characters with no original textures, just presets to reuse the base Geneis 9 materials. 

You create a figure from scratch, you get the basic morphs. You want to use a morph you purchased called "heads vol 2", you go to the library and "attach" the morphs within it to the figure. Now the figure is "base morphs" plus "heads vol 2" (and whatever else heads v2 loads). Later you save and reload this figure. When it reloads, it load "Heads vol 2" automatically because the scene/character file tells it to. 

 Which is, to an extent, what the ExP system used with Victoria/Michael 4 did - it added its own data files to /Runtime/Libraries/!DAZ/Figurename and in order to use them we had to run a script that added those files to the master list of files to load that the figure read in. People hated this, hence the Genesis system.

TheMysteryIsThePoint said:

A design that creates "very important practical reasons" why it must be inefficient is not a very good design. There is no degree of rationalization or explanation that is more important than the user experience, which is the reason  why the design exists in the first place. Knowing why it is inefficient is no consolation while I'm twiddling my thumbs while waiting for the scene to load; I'd vastly prefer to simply be ignorant and not know why it can load a scene so quickly rather than knowing all the exact design decisions, as you've carefully explained, that make it painfully slow.

Hating the experience of the current system doesn't mean that an alternative system's experience would be better. There are always trade-offs, as I noted in reference to ExP above, and Daz chose what they thought would be the lesser evil. It is possible that history has shown a different approach would have been a lesser evil, but it can't be assumed that that is the case. It is possible that DS 6 will try to adjust the system, but there will probably be downsides to that too.

TheMysteryIsThePoint said:

Matt_Castle said:

TheMysteryIsThePoint said:

Why force the user to wait for dials that the user has expressed no interest in, instead of initializing them into some kind of inactive state and only loading them if/when they are actually used?

Because, for very important practical reasons, control links have to be able to be defined in either direction.

...

A design that creates "very important practical reasons" why it must be inefficient is not a very good design. There is no degree of rationalization or explanation that is more important than the user experience, which is the reason  why the design exists in the first place. Knowing why it is inefficient is no consolation while I'm twiddling my thumbs while waiting for the scene to load; I'd vastly prefer to simply be ignorant and not know why it can load a scene so quickly rather than knowing all the exact design decisions, as you've carefully explained, that make it painfully slow.

What's the alternative, remove product features that people use? There's trade-offs sometimes. Some features create a benefit, but create a cost elsewhere. That cost might be considered small at the time, or go unnoticed for years until circumstances change. The world is complicated like that. 

The feature you're complaining about wasn't a problem at the time. It only became a problem later. The current design wasn't intended to handle 5000+ morph files. And yet, Daz artist keep turning out characters with loads of custom morphs and such. 

Now that has indeed became a problem, Daz is going to have to deal with it. As has already been discussed, there would be ways to speed up loading that aren't going to be added to the current DS platform. We'd have to wait for the next major version release. There are other ways to deal with the issue in the meantime. The main one is removing or disabling some of the figure morphs to take the load of a system that wasn't designed to handle it. 

You can't put a 2 ton load in a 1/2 truck and expect it to get up 70+ on the freeway. You can either reduce the load, or wait for Daz to redesign the truck with better load capacity. 

I recently obtained Lycan 9. I was interested in having a shape morph from it that only affected the legs, but by default Lycan 9 is all or nothing with its body morphs. I tried to follow the advice provided by Esemwy in 2018 here. I have followed his instructions to a T, but when I go to apply the morphs with morph loader pro, it won't load. 
I'm fairly amateur using Daz3D. My assumption is that I'm missing something that has changed between now and 2018 when Esemwy made his guide. Thank you in advance.

Have you by chance installed the premier addon shape of Sigrid? Because there are know problems since thrusday about faulty morphs that are not zeroed.

If you have, uninstall for now. If not, look for the faulty morph in your particular case (load base G9 only and see what morphs are active).

TheMysteryIsThePoint said:

Richard Haseltine said:

...

Well, it has to read all the morphs, UV sets and so on to have them appear in the options for the figure - unless it read them when the option list was opened, which would speed the initial load at the expense of slower operation while working (which would probably be the worse user experience for most of us). That pre-loadgn of all the optiions was what i was sayng Blender doesn't do, rather than claiming that there was no way to add elements explicitly (but having to go through UI interactions to do so).

And that is exactly what I think @gniiial and I are referring to when we say that the design of the application does not provide an acceptable user experience. Why force the user to wait for dials that the user has expressed no interest in, instead of initializing them into some kind of inactive state and only loading them if/when they are actually used? That part is not speculation but empirically observed and is a mild criticism in all events. The dev team gets a lifetime pass for the Genesis framework, in my book :) say what you may, the thing otherwise works. Well. Projection morphs are an ingenious innovation.

Here's my sepculation: It is difficult to believe that the same devs who can make something as complicated as a 3D application like DAZ Studio just didn't know about the concept of Lazy Loading. What is believable, though, is that no one suspected DAZ studio to be the smash success that it is, and the combinatoric operation of linking all the morphs and their dependencies was manageable when the catalog was small. It's a victim of its own success, so to speak. But whatever, it has improved greatly in any case.

Just my two cents.

I believe the poser origins is the issue here. Or more likely, backward compatibility is the issue.

I think keeping the extensibility and having fast response would require redoing how morphs are setup. For example:

You create a figure from scratch, you get the basic morphs. You want to use a morph you purchased called "heads vol 2", you go to the library and "attach" the morphs within it to the figure. Now the figure is "base morphs" plus "heads vol 2" (and whatever else heads v2 loads). Later you save and reload this figure. When it reloads, it load "Heads vol 2" automatically because the scene/character file tells it to. 

I'm sure there are problems with my scheme as well. But if load times were basically "instant", maybe those other problems wouldn't have as bad an impact. After all, if all those morphs are loaded, they take up memory. Saving time and memory can't be toooo bad.

Matt_Castle said:

Semicharm said:

One way to handle that is each file has a header with all of the metadata about dependences. That can be read without having to process the entire file. 

This is already how it is done. The formulas for any morph are stored near the start of its DSF file, immediately after the basic parameters of said morph. The morph deltas are further through the file, and indeed do not get processed and loaded until the morph is actually activated.

However, looking in the morph file has reminded me of something I'd forgotten. The basic parameters of a morph include things like what the morph's minimum and maximum limits are. Unless the file is opened and its header sections processed, then DS does not know whether a morph's slider should be displayed to the user with a range of 0% to 100%, -100% to 100%, -50% to 100%, 0 to 200%, or whatever.

This makes the problem of speeding up the processing of morphs a considerably more complicated process than I initially considered, and I'm now not actually sure I can see a better way that actually achieves the aims Daz need to meet.

Either the range info would have to be moved to the meta data section, which would start to bloat things a bit, or it would have to be displayed without specific info until it's completely loaded. That's where using a background task would help. Things the user tries to access can be moved to the front of the queue. 

That of course can be sped up if loading and decoding files was done in paralellel. For example, which file can be processed by a separate thread.

I believe Daz Studio 6 is already moving towards being able to paralellise these things more, but it's not an option we can expect to see added to DS4, which has reached the end of its development life and would have been extremely impractical to rebuild anyway.

I figured as much. Much of the framework for DS4 was set when CPUs only had a few cores and most people still relied on spinning hard drives. Older ones didn't handle multitasking well. Command queuing helps, but the drive was still a massive bottleneck. Parallel processing files would require investing time that would benefit few users back then. 

I'm sure such things were a "next gen" feature. I doubt they ever planned for that next major release to be pushed back this long. 

Semicharm said:

One way to handle that is each file has a header with all of the metadata about dependences. That can be read without having to process the entire file. 

This is already how it is done. The formulas for any morph are stored near the start of its DSF file, immediately after the basic parameters of said morph. The morph deltas are further through the file, and indeed do not get processed and loaded until the morph is actually activated.

However, looking in the morph file has reminded me of something I'd forgotten. The basic parameters of a morph include things like what the morph's minimum and maximum limits are. Unless the file is opened and its header sections processed, then DS does not know whether a morph's slider should be displayed to the user with a range of 0% to 100%, -100% to 100%, -50% to 100%, 0 to 200%, or whatever.

This makes the problem of speeding up the processing of morphs a considerably more complicated process than I initially considered, and I'm now not actually sure I can see a better way that actually achieves the aims Daz need to meet.

That of course can be sped up if loading and decoding files was done in paralellel. For example, which file can be processed by a separate thread.

I believe Daz Studio 6 is already moving towards being able to paralellise these things more, but it's not an option we can expect to see added to DS4, which has reached the end of its development life and would have been extremely impractical to rebuild anyway.

Matt_Castle said:

TheMysteryIsThePoint said:

Why force the user to wait for dials that the user has expressed no interest in, instead of initializing them into some kind of inactive state and only loading them if/when they are actually used?

Because, for very important practical reasons, control links have to be able to be defined in either direction.

That is to say that if you have a Controller A, with child morphs B, C & D, then the code can be in A to say "when A is dialled in, dial in B, C & D". Or the code can be in each of B, C & D to say "Go and look at A. If it's dialled in, dial me in too, thanks". Or various combinations.

Being able to link in either direction is very important, both practically and legally.

Let's say someone creates some new expressions, but *also* wants to have correctives for those expressions to make them look their absolute best on Victoria 9. So, they need to link the correctives to Victoria 9's morph so those correctives only activate on her shape. But they cannot update Victoria 9's morph because a) if everyone who needed to link to Victoria 9's morph had to alter it, then only one person could ever link to it, b) it would stupidly bloat everything if you needed to send around updated morphs for everything you wanted to link to, and c) they do not have the copyright to alter and redistribute Victoria 9's morph. So the link to Victoria 9's morph needs to be saved in the expression corrective file, not Victoria 9's.

As such, an on-demand top-down indexing of the morph library of "only look in the files once you know you need them" is impossible, because a lot of morph links are defined bottom-up and thus you don't know for sure whether you do or don't need a file until you've looked in it.

Now, possibly there are better ways to handle this infrastructure. Maybe the links could exist as files themselves, and their file names are encoded such that DS can tell for sure "Hey, that link file has a name that matches this morph file's name, so I know that it tells me about a link I will need to use if I ever dial this morph in, but I don't need to look in it right now", but it would not be possible to migrate an existing figure base to a new system like that.

For now, Daz Studio is forced to work the way it does, opening and checking every morph file it can find in the library folders for that base figure to find all possible links before proceeding.

One way to handle that is each file has a header with all of the metadata about dependences. That can be read without having to process the entire file. The rest can be posponed untill the file is required or as a background task. Wating until a dial is used can trigger 50 or more dependences being loaded, which can cause the app to freeze while that's being processed.

That of course can be sped up if loading and decoding files was done in paralellel. For example, which file can be processed by a separate thread. The best way to do that depends on where the bottlenecks in the pipeline are. 

SonixUK said:

barbult said:

It is not just you. It looks like a bug or undocumented limitation to me. I can reproduce this problem in DS 4.24.0.3 using G9M with his anatomical elements, a geoshell with geograft visibility off as you described, and a morph extracted from a simulated garment he is wearing. As soon as the morph is created by Archmage Morph Extractor, the geoshell graft visibility is turned back on. 

Appreciate you testing it out to confirm. Thanks.

Hopefully it can be fixed; it's frustrating and slows productivity having to adjust all the geoshells after every morph extraction.

I'm afraid if the Morph Extractor script switches the current tool to Geometry Editor or sth., the geo-grafts will be unfitted, then all geo-shell visibility properties will be reset... which is a default behavior of DS ~~

I can understand the reason why the script changes the tool to GeoEditor... because some wearables use the settings of AutoHide with geo-grafts ~~ If the wearable is fitted, when importing the morph with MLP, the geometry will mismatch.

I think maybe the PA can save the properties of all geo-shells and load them back within the script ~~ or there maybe other better ways to avoid that the users have to reset the visibility settings, etc.

TheMysteryIsThePoint said:

Why force the user to wait for dials that the user has expressed no interest in, instead of initializing them into some kind of inactive state and only loading them if/when they are actually used?

Because, for very important practical reasons, control links have to be able to be defined in either direction.

That is to say that if you have a Controller A, with child morphs B, C & D, then the code can be in A to say "when A is dialled in, dial in B, C & D". Or the code can be in each of B, C & D to say "Go and look at A. If it's dialled in, dial me in too, thanks". Or various combinations.

Being able to link in either direction is very important, both practically and legally.

Let's say someone creates some new expressions, but *also* wants to have correctives for those expressions to make them look their absolute best on Victoria 9. So, they need to link the correctives to Victoria 9's morph so those correctives only activate on her shape. But they cannot update Victoria 9's morph because a) if everyone who needed to link to Victoria 9's morph had to alter it, then only one person could ever link to it, b) it would stupidly bloat everything if you needed to send around updated morphs for everything you wanted to link to, and c) they do not have the copyright to alter and redistribute Victoria 9's morph. So the link to Victoria 9's morph needs to be saved in the expression corrective file, not Victoria 9's.

As such, an on-demand top-down indexing of the morph library of "only look in the files once you know you need them" is impossible, because a lot of morph links are defined bottom-up and thus you don't know for sure whether you do or don't need a file until you've looked in it.

Now, possibly there are better ways to handle this infrastructure. Maybe the links could exist as files themselves, and their file names are encoded such that DS can tell for sure "Hey, that link file has a name that matches this morph file's name, so I know that it tells me about a link I will need to use if I ever dial this morph in, but I don't need to look in it right now", but it would not be possible to migrate an existing figure base to a new system like that.

For now, Daz Studio is forced to work the way it does, opening and checking every morph file it can find in the library folders for that base figure to find all possible links before proceeding.

Under the Sea

KT Child G9 by katyee (morph)
https://www.renderosity.com/freestuff/items/98181/kt-child-g9
Iuno for G9 by Shinteo (hair)
https://www.deviantart.com/shinteo/art/Iuno-for-G9-1244909157
Trekant Bikini G8F by pjz99
https://www.renderosity.com/freestuff/items/97491/trekant-bikini-g8f
Free Mermaid for V4 by Most Digital Creations
https://www.most-digital-creations.com/free_poser_poses_textures_morphs_props_16.htm
Little Star Plushy by paulawbs
https://www.renderhub.com/paulawbs/little-plush-star
G9 Underwater Poses 01 to 10 by richardandtracy
https://www.renderosity.com/freestuff/items/99579/g9-underwater-poses-01-to-10

Coral Reef - Great Barrier Reef by Shreddder
https://www.renderosity.com/freestuff/items/94286/coral-reef-great-barrier-reef
Underwater Hdri by Namtaar
https://www.deviantart.com/namtaar/art/Underwater-Hdri-805776729

PAID:
Filatoon Skies (for Underwater Hdri)
https://www.daz3d.com/filatoon-skies

@genaris thank you for the suggestions - the clenched hands/bent fingers idea would have to be achieved through HD morphs, something that's currently out of my wheelhouse/comfort zone. Unfortunately due to ill health my scope for work is very limited atm so I would have to explore products that are less complex and/or that I have familiarity with, I'm sorry but hope you understand. I know Luthbellina has been releasing a lot of hd morph packs for different body areas recently, perhaps she already has something sutiable for you?

I mentioned earlier that eyebrows would be tricky to offer mixed color support for because of UV mapping differences between products.To get a natural and convincing salt n pepper or mixed color, it needs to be built into the product itself through surface zones that different colors can be applied to. The G9 Starter Essentials brows with their primary and secondary zones are a step in the right direction but unfortunately don't go far enough IMO becasue the secondary zone is only a smattering of hairs and would only be clearly visible for closeup portraits. A long time ago I was looking into creating a product not just for eyebrows but for hair too, and the results were just not good.

gniiial said:

midgard229 said:

Blender saves the entirety of a scene into one enormous file..... My blender scenes are 4 gb for something simple and I despise it, where my daz takes 40 seconds to load and the scene weighs 20mb. Sure my add is full 3tb worth of daz assets but 40 seconds load time isn't bad imo. Now the old versions of daz where it'd take an hour to load... Yes that was a problem xD
Blender is by far the fastes program on the market. Maybe you should consider updating your hardware or set things straight in Blender by it's settings and all these possibilities to tweak it properly. And I don't know why your files are this big (4GB rly?!). I even transfer so much stuff into Blender, and it loads like a charm. Not even 5 seconds and it's there. And we are talking - Program start - while hitting just a blend file! Just used the lounge ( nightclub https://www.daz3d.com/night-lounge-iray ) where I added some stuff. The .duf File is 11.8 MB big. I hit the file: 
Daz loads the entry screen 5 seconds, 
Then reading asset 3-5 seconds...
Then clearing the scene & deleting objects. It's not even done after 2 Minutes waiting and we are talking one camera, empty scene... so basically NOTHING! (3 Minutes!)
Then the lounge appears and the login pops up (I don't know why that even has to happen... but that's not the problem...)
Clearing the scene for example is and loading the stuff with one core only too for sure. Not even a "bigger spike" on my ssd's, ram, in the cpu or gpu performance part... Which means, this stuff will only be used when DAZ3D renders. 
Hit the rendering button: 2 Minutes 40 Seconds (not even crisp and with fireflys after 350 iterations)
The blend file of the same scene - 71.8 MB! 
Hit the blend file - 5 Seconds - scene there! 
Hit rendering - 27 seconds (250 iterations crisp and usable, no need for more! Even though, it's a brighter light) 
But I cannot do that with all the character stuff. That's way too much to transfer to achive an overall smooth workflow. 

It still should be possible in 2026 to think of a way and realize something, to really use the full advantages of a high end computer system. Look at blender, look at unreal, they achive stuff one can dream off to use in DAZ3D directly.
I mean, my sceene (8 Gen 9 + Hair and clothes) needs 10+ minutes to come up in full. Not even the rendering time takes this much time to get the crisp result I want to. And it's no wonder, if everything is just dumped onto one core, that, for example is also already pacially in use by standart programs that need this first core.
Surely it should be possible to split this load and reduce the loading time, without conflicting the program itself somehow. And if everything depends for example on the genesis figure, then at least this could be loaded first and then those other features, like morphs, hair, clothings props or whatever else has it's own category could be loaded after the figure is "available" to fit stuff on. I mean for real, if you create a character - once - it also cann be a very fast process. (...if we for example have all these features we want to use in one place and just click through them) 
And don't get me wrong here. We have turbo loader out there, which basically - forces - DAZ3D to ignore all these genesis oriented features and does a great job making this program faster. But that cannot be all... 
For example, why not add a feature, where one hooks a library (let's say clothing), and - only then - the features that are needed will be loaded?! 
I already splitted my libraries in nature, environments, hair and other categories, so I could just dump the load manually, If I want to (with the preferences, deleting a folder, adding it when I need it). But that is tideous! Turbo loader gives you the opportunity to save settings, with for example only female oriented morphs, characters and stuff. 
Why is - that feature - not part of literally everything as an automatic process?! Or even as a manual one, the folders just as "links" and only if accessed, the features will be loaded. I assume that would make even starting a saved file faster, since there could be an "link to a lib" like it's done in programing. Okay, this is a scene with only nature, only some buildings, some cars... Nothig else needed to be load. So the result is faster for sure. 
Blender does not even load any library, because - what for - when the user does not even started to do something?! 
If we open a file, the libraries are shaders, textures, stuff that is actually - really - used and nothing else. 
If we then again add a chair, this chairs stuff get's loaded.. 
The linking or appending part is also very interesting... I mean these are great ideas, right?! Adapt them somehow...
Look at unreal, how it deals now with their camera (you can do that with blender too easy!) and for example trees, bushes, grass and nature in general... It's incredible what is possible there. 
You can clearly see the idustries future there... 
Btw first Image is DAZ3D second is Blender... notice the difference when rendering. Even though it's not a heavy scene, the difference is pretty clear. The GPU is used more, the cpu is quite involved in the process. 

Well the blend files are large when porting a daz character that has hairs, clothing and etc. my pc is fine, i have an nvidia 3080 10gb with 64gb ram. Also a hint; when you save a scene in daz, just task force close it out. I've been doing it for years.
My scene with g8 +g9 and everything takes less than a minute to boot up, so may be something up with your system 

midgard229 said:

Blender saves the entirety of a scene into one enormous file..... My blender scenes are 4 gb for something simple and I despise it, where my daz takes 40 seconds to load and the scene weighs 20mb. Sure my add is full 3tb worth of daz assets but 40 seconds load time isn't bad imo. Now the old versions of daz where it'd take an hour to load... Yes that was a problem xD
Blender is by far the fastes program on the market. Maybe you should consider updating your hardware or set things straight in Blender by it's settings and all these possibilities to tweak it properly. And I don't know why your files are this big (4GB rly?!). I even transfer so much stuff into Blender, and it loads like a charm. Not even 5 seconds and it's there. And we are talking - Program start - while hitting just a blend file! Just used the lounge ( nightclub https://www.daz3d.com/night-lounge-iray ) where I added some stuff. The .duf File is 11.8 MB big. I hit the file: 
Daz loads the entry screen 5 seconds, 
Then reading asset 3-5 seconds...
Then clearing the scene & deleting objects. It's not even done after 2 Minutes waiting and we are talking one camera, empty scene... so basically NOTHING! (3 Minutes!)
Then the lounge appears and the login pops up (I don't know why that even has to happen... but that's not the problem...)
Clearing the scene for example is and loading the stuff with one core only too for sure. Not even a "bigger spike" on my ssd's, ram, in the cpu or gpu performance part... Which means, this stuff will only be used when DAZ3D renders. 
Hit the rendering button: 2 Minutes 40 Seconds (not even crisp and with fireflys after 350 iterations)
The blend file of the same scene - 71.8 MB! 
Hit the blend file - 5 Seconds - scene there! 
Hit rendering - 27 seconds (250 iterations crisp and usable, no need for more! Even though, it's a brighter light) 
But I cannot do that with all the character stuff. That's way too much to transfer to achive an overall smooth workflow. 

It still should be possible in 2026 to think of a way and realize something, to really use the full advantages of a high end computer system. Look at blender, look at unreal, they achive stuff one can dream off to use in DAZ3D directly.
I mean, my sceene (8 Gen 9 + Hair and clothes) needs 10+ minutes to come up in full. Not even the rendering time takes this much time to get the crisp result I want to. And it's no wonder, if everything is just dumped onto one core, that, for example is also already pacially in use by standart programs that need this first core.
Surely it should be possible to split this load and reduce the loading time, without conflicting the program itself somehow. And if everything depends for example on the genesis figure, then at least this could be loaded first and then those other features, like morphs, hair, clothings props or whatever else has it's own category could be loaded after the figure is "available" to fit stuff on. I mean for real, if you create a character - once - it also cann be a very fast process. (...if we for example have all these features we want to use in one place and just click through them) 
And don't get me wrong here. We have turbo loader out there, which basically - forces - DAZ3D to ignore all these genesis oriented features and does a great job making this program faster. But that cannot be all... 
For example, why not add a feature, where one hooks a library (let's say clothing), and - only then - the features that are needed will be loaded?! 
I already splitted my libraries in nature, environments, hair and other categories, so I could just dump the load manually, If I want to (with the preferences, deleting a folder, adding it when I need it). But that is tideous! Turbo loader gives you the opportunity to save settings, with for example only female oriented morphs, characters and stuff. 
Why is - that feature - not part of literally everything as an automatic process?! Or even as a manual one, the folders just as "links" and only if accessed, the features will be loaded. I assume that would make even starting a saved file faster, since there could be an "link to a lib" like it's done in programing. Okay, this is a scene with only nature, only some buildings, some cars... Nothig else needed to be load. So the result is faster for sure. 
Blender does not even load any library, because - what for - when the user does not even started to do something?! 
If we open a file, the libraries are shaders, textures, stuff that is actually - really - used and nothing else. 
If we then again add a chair, this chairs stuff get's loaded.. 
The linking or appending part is also very interesting... I mean these are great ideas, right?! Adapt them somehow...
Look at unreal, how it deals now with their camera (you can do that with blender too easy!) and for example trees, bushes, grass and nature in general... It's incredible what is possible there. 
You can clearly see the idustries future there... 
Btw first Image is DAZ3D second is Blender... notice the difference when rendering. Even though it's not a heavy scene, the difference is pretty clear. The GPU is used more, the cpu is quite involved in the process. 

ArgleSW said:

Daz promos hurt new character intros by mixing them with other morphs and themes right away (male/female gender swap, wizard, spy, doctor, athletic, lean... plus bonus morph). It blurs what the actual core character is. If you think back to Daz Originals Genesis 3, I bet you have a better memory of what the core characters looked like and how they differed from on another. Now its all about mix and match morphs and themes.

I would be all in favour of mix & match if they were actually modular and accessible. One of the things I like about the daz original pattern is every character comes with both male and female textures. But then werewolf came with both male and female textures but female morph is locked behind premium - which means I can't get an interactive license for it. Or there's Maryam which has a glorious stylized shape and texture set but no other characters I'm aware of were released in that style to match the aesthetic.

I'd love to see some of that variety expanded on with more frequency.