Is there a thread about "character bloat"?

sean2_7606d08833

Richard Haseltine said:

I would think the whole file would be read in (presumably it just reads in the whole thing and uses the JSON parser on the resullt) but the detas are jettisoned until needed.

I'm fairly certain this is what is going on.

I have a fast computer and all content on an internal SSD, but I also have hundreds of characters. Daz Studio was great when I initially tried it out, and then I spent lots of money buying characters from multiple sites and when I started trying to use them seriously I realized load time made Daz Studio basically unusable for my purposes.

It's definitely the morphs, as I moved them in and out of the data folder to test performance.

I ran a whole bunch of timing tests to see what mattered, e.g. JCMs and pose morphs vs. character morphs, creating new morphs consisting of body & head morphs merged. The main determiner seems to be the size of the morphs; a bunch of small body part morphs load as fast as a single character morph. Replacing one morph for body & head instead of two morphs doesn't help at all. So to a first approximation the size of the file (though compressed vs. uncompressed made no meaningful difference on my machine) is the main issue, so I would bet it's just the cost of loading & parsing the JSON files.

It seems like it could improved straightforwardly if anyone cared; for example, the overhead due to having more morphs available for a scene with 4 G8F characters requires 4 times as long to load as one with a single G8F, so it seems like it's loading and throwing away this data over and over during a scene load. Since the only purpose seems to be to be able to display the dials, it would make a lot more sense to me to cache that data (in memory, or better yet to disk). I realize that each character stores their own copy (since each can have different morphs loaded dynamically), but the issue here is just reading the ones on disk to populate the character--just putting a cache between this 'load the dials' reader and the actual morph files.

I've done a few things to deal with this:

1. I split all my morphs up into dozens of content libraries and only keep a couple loaded at a time

2. I mainly use purchased characters for their skins, and I use dial-spun characters with those skins 95% of the time.

But I'm still not happy. It's really tedious to map and unmap content libraries; it's still slower to load than it should be; and I wasted a lot of money on character morphs I will never use unless this gets fixed.

Robinson

"But I'm still not happy. It's really tedious to map and unmap content libraries; it's still slower to load than it should be; and I wasted a lot of money on character morphs I will never use unless this gets fixed."

Speed scales with the number of items you're not using, yes.  That's a software design issue.

msgclaude-3d_f3a798a45e

sean2_7606d08833 said:

Richard Haseltine said:

I would think the whole file would be read in (presumably it just reads in the whole thing and uses the JSON parser on the resullt) but the detas are jettisoned until needed.

I'm fairly certain this is what is going on.

I have a fast computer and all content on an internal SSD, but I also have hundreds of characters. Daz Studio was great when I initially tried it out, and then I spent lots of money buying characters from multiple sites and when I started trying to use them seriously I realized load time made Daz Studio basically unusable for my purposes.

It's definitely the morphs, as I moved them in and out of the data folder to test performance.

I ran a whole bunch of timing tests to see what mattered, e.g. JCMs and pose morphs vs. character morphs, creating new morphs consisting of body & head morphs merged. The main determiner seems to be the size of the morphs; a bunch of small body part morphs load as fast as a single character morph. Replacing one morph for body & head instead of two morphs doesn't help at all. So to a first approximation the size of the file (though compressed vs. uncompressed made no meaningful difference on my machine) is the main issue, so I would bet it's just the cost of loading & parsing the JSON files.

It seems like it could improved straightforwardly if anyone cared; for example, the overhead due to having more morphs available for a scene with 4 G8F characters requires 4 times as long to load as one with a single G8F, so it seems like it's loading and throwing away this data over and over during a scene load. Since the only purpose seems to be to be able to display the dials, it would make a lot more sense to me to cache that data (in memory, or better yet to disk). I realize that each character stores their own copy (since each can have different morphs loaded dynamically), but the issue here is just reading the ones on disk to populate the character--just putting a cache between this 'load the dials' reader and the actual morph files.

I've done a few things to deal with this:

1. I split all my morphs up into dozens of content libraries and only keep a couple loaded at a time

2. I mainly use purchased characters for their skins, and I use dial-spun characters with those skins 95% of the time.

But I'm still not happy. It's really tedious to map and unmap content libraries; it's still slower to load than it should be; and I wasted a lot of money on character morphs I will never use unless this gets fixed.

I noticed a problem like your's with some of my scenes with Victoria4. It seems that the problem comes from certain morphs. Each time I reworked a scene, it takes more and more time to load.

There is an option in the scene pannel that shows the hidden nodes. I try that and discovered thousends of identical morphs. They all were non parented and have absolutely no action ! I discovered one of my scenes containing 20.000 such morphs ! Each time the reworked scene is saved, DAZ seems to add dupicates of those morphs.

Since they have no action, I deleted them and saved the new scene. And the load time comes back to normal. I don't know the reason why DAZ decides to add such parasit hidden morphs and I have no solution to prevent that. But simply making them visible and deleting them from the scene solved my problem.

Richard Haseltine

msgclaude-3d_f3a798a45e said:

sean2_7606d08833 said:

Richard Haseltine said:

I would think the whole file would be read in (presumably it just reads in the whole thing and uses the JSON parser on the resullt) but the detas are jettisoned until needed.

I'm fairly certain this is what is going on.

I have a fast computer and all content on an internal SSD, but I also have hundreds of characters. Daz Studio was great when I initially tried it out, and then I spent lots of money buying characters from multiple sites and when I started trying to use them seriously I realized load time made Daz Studio basically unusable for my purposes.

It's definitely the morphs, as I moved them in and out of the data folder to test performance.

I ran a whole bunch of timing tests to see what mattered, e.g. JCMs and pose morphs vs. character morphs, creating new morphs consisting of body & head morphs merged. The main determiner seems to be the size of the morphs; a bunch of small body part morphs load as fast as a single character morph. Replacing one morph for body & head instead of two morphs doesn't help at all. So to a first approximation the size of the file (though compressed vs. uncompressed made no meaningful difference on my machine) is the main issue, so I would bet it's just the cost of loading & parsing the JSON files.

It seems like it could improved straightforwardly if anyone cared; for example, the overhead due to having more morphs available for a scene with 4 G8F characters requires 4 times as long to load as one with a single G8F, so it seems like it's loading and throwing away this data over and over during a scene load. Since the only purpose seems to be to be able to display the dials, it would make a lot more sense to me to cache that data (in memory, or better yet to disk). I realize that each character stores their own copy (since each can have different morphs loaded dynamically), but the issue here is just reading the ones on disk to populate the character--just putting a cache between this 'load the dials' reader and the actual morph files.

I've done a few things to deal with this:

1. I split all my morphs up into dozens of content libraries and only keep a couple loaded at a time

2. I mainly use purchased characters for their skins, and I use dial-spun characters with those skins 95% of the time.

But I'm still not happy. It's really tedious to map and unmap content libraries; it's still slower to load than it should be; and I wasted a lot of money on character morphs I will never use unless this gets fixed.

I noticed a problem like your's with some of my scenes with Victoria4. It seems that the problem comes from certain morphs. Each time I reworked a scene, it takes more and more time to load.

There is an option in the scene pannel that shows the hidden nodes. I try that and discovered thousends of identical morphs. They all were non parented and have absolutely no action ! I discovered one of my scenes containing 20.000 such morphs ! Each time the reworked scene is saved, DAZ seems to add dupicates of those morphs.

Since they have no action, I deleted them and saved the new scene. And the load time comes back to normal. I don't know the reason why DAZ decides to add such parasit hidden morphs and I have no solution to prevent that. But simply making them visible and deleting them from the scene solved my problem.

Those are not morphs, morphs don't appear as nodes in the scene. What you had was some kind of object, probably created by a third-party plug-in that you had installed or that was installed on the system in which some of your content files were created.