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
I'm only the messenger, another user found the issue (via editing the layout file to clear the Aux Viewport) and Daz then figured out exactly why the solution worked (and fixed the underlying problem in the current beta).
Clean up what? Why should I let Daz spent 3 minutes releasing memory when I can simply Get-Process DazStudio | Stop-Process and re-open it? I've already saved the scene to disk, there shouldn't be any disk activity that Daz needs to do.
It is cleanly releasing memory - which with a morph-laden figutr can take a while - saving the layout, closing out the database, gettign plug-ins to shut down properly, and so on. Some of those operations should definitely not be left hanging.
Of every program I've ever run, Daz takes the longest to close by far. It is baffling.
I would suspect that most applications have less complex structures - in my experience the time is longest with figures that have lots of morphs with many links between them, it isn't a function of raw size as such. I would imagine that the application framework used, if any, has at least some bearing too.
In my experience, it does not matter, you can also load a plain Genesis 8 Female/Male figure, close DAZ Studio, and it takes forever to be cleared.
The problem is in the coding of the software. The more content you own and have installed, the more unnecessary morphs are loaded. There is already a myriad of morph injections loaded with a freshly loaded Genesis 8 figure. It would have been a better approach to have a clear separation of morphs from the figure, something like a morph loader that you have first to activate to see the available morphs before you can apply them.
Yes, you can add every morph right on the spot, but to be honest, why needs every figure in your scene those readily available? For example, let's mention the morphs to change your runway model into a freakish monster with hooves, fangs, and whatever.
Well, those would be examples of figures with lots of morphs and links between them. A counter example would be a static scene with a lot of geometry but no or few morphs that also took a long time to clear.
Coding is not the same as design - it's the latter you are criticising. As for better, people were hardly blissfully happy with the morph injection system in third generation Daz figures (where big morph sets needed their own CR2 file, and mixing morphs required file-surgery) or the ExP system used by the fourth generation (where an updater had to be run to add new morph channels, or in DS Power Loader could be used to select products or individual morphs at load time). While the current system certainly has its drawbacks, the time taken to close DS is not - for my taste - the worst of them and whatever system is used there are likely to be drawbacks. By all means suggest alternative approaches, but do think about their drawbacks, about how they will impact less experienced users in particular, and about where in the workflow the benefits and drawbacks will have impact.
The drawback lies not only in the closing of DAZ but also in loading a figure, resetting a figure (pose/morphs), and clearing a scene. Everything takes long enough to leave your workplace for an extended walk.
One problem is that you (the whole staff) are regularly belittling the problems users with an extended content library have while blowing smoke at the same time.
I am not a native English speaker — as are many other DAZ Studio users —, so I could be wrong. Still, with wordings like "with figures that have lots of morphs with many links between them," you imply that the actual figure loaded into the viewport needs to have many morphs "manually" added. But in fact, you do not need to create a figure with many morphs to get trapped in the hell of bad design, which essentially is the result of bad code implementation.
Redacted
That's why I added an apposition in brackets, to make clear that I do not mean Richard with that "you" but the whole staff.
There wasn't any implication that this was the users fault, the morphs come from characters and morph sets and while it's certainly true that being selective about what is isntalled is an option, it's not one I've yet managed to take (and I get the same slow load/close and lags in posing as the rest of you). It would of course be great to resolve these - but managing a large, extensible pool of morphs (and other properties) is a hard problem and i wanted to stress that Daz has actively explored different approaches over the generations and so far has not found a snag-free solution.
I have taken up the rather superstitious practice of clearing the scene before exiting. This flushes the memory and so far, Studio has always terminated properly when I do this.
How about making character presets such that only the used morphs would be saved/loaded instead of everything installed for that base figure.
If one then wanted to have all the morphs, one could start with the base figure and when happy with the character, one could save it as a character preset and DS would ask "Do you want to save all the shaping morphs or just the used ones?". The selection would be saved inside the preset and when loading the presert, DS would check whether to load everything or just the ones used.
This.
A design that does not scale well as the number of morphs increases, regardless of whether those morphs are actually used, is not a good design. A design that requires so much processing just to remove itself from memory is not a good design.
Computer scientists call it Algorithmic Complexity. It describes how the performance of a program changes as its input grows. What is a sufficient design for a small number of features can be totally insufficient for a large number. An algorithm whose performance doesn't depend on the size of the input is called O(1) and that's great. One that scales with the logarithm of the size is still very good. One that scales linearly is O(n) and is still acceptable in most cases, but you'll notice things getting sluggish as your ambition grows. Anything beyond that ( O(n log n) or god forbid O(n^2) ) is when you need to get a sandwich or go for a walk, as some have written. I, of course, cannot begin to know what is going on, but it really seems like Daz Studio has some O(n^2) algorithms in it that were fine when the number of morphs was small.
But far above the low level details of the design of algorithms, an even bigger impact on system performance comes from its architectural design. A good design would not require processing of morphs that are not even used in the scene.
It's not an attack to point out a bad user experience any more than someone trying to justify or explain it away... helps.
What happens when you want to use expressions, or load clothing which includes morphs to deform the flesh (such as the Real Fit sets)?
That is why I was talking about shaping morphs, expressions are poses or at least they should be. Maybe make that cache to do something usefull.
If a clothing includes morphs, those could be loaded with the clothing, or if you wanted to add a shape morph to the figure, you could load it from the library, should not be impossible as you can import morphs "on the fly" with OBJ's
FWIW, I have noticed that G3 figures don't hold up the shutdown process nearly as much as my G8 figures. Maybe that's because I have more morphs for G8F but I can load a scene with three G3M males and it shuts down quicker than one G8F. One of the reasons I follow the posts here regularly is because I switch to this browser while I'm waiting for DAZ Studio to shut down.
Anyhow, I think Richard deserves a break. He has been here to advise for years and years and I'm sure we all appreciate his help. Mod decisions ... different matter though ;)
I noticed that the shut-down time increased with Genesis 8.1.
I made the mistake of updating the Starter Essentials and now have the base figures in my DAZ Studio 4.14. Since then, everything closes and clears much slower, although I had never loaded a Genesis 8.1 figure into the viewport. However, it was slow before that — but since then, it's really slow.
Redacted
Question related to this:
While we know that DAZ Studio takes its own sweet time to shut down, what is the effect of just clicking on "New" for a new scene?
It has been my habit for a long time to close DAZ Studio before starting a new scene. I seem to remember talk of a memory leak which gets worse if you don't shut down before starting a new scene. Is this true and, if so, was it ever fixed?
Getting back to
I really appreciate Richard's seemingly endless energy helping DAZ users with their problems and at the same time (though being aware there are a ton of problems) defending the software.
Regarding this specific argument: As a Maya, Substance Suite, and ZBrush (!) user (or iClone, and many more, to name a few), in my user's perception, these applications are equally complex. But they close w/in seconds and not taking care of "cleaning memory".
I'd love to understand the "cleaning memory" argument better - from a developer's perspective.
Does DAZ uses it's own memory management framework or the - assumed - C++ built-in way? Was using a garbage collection (e.g. https://www.hboehm.info/gc/) no option?
Or is at least shared_ptr (since CPP 11) used?
PS: I'd even more love to look at DAZ Studio's code, alas - it's not Open Source. Maybe that could be an option for DAZ management as the business model isn't selling the software, but the content.
They still could have full control over the software by provding support only for the official DAZ releases and not any possible forks. This is an OSS approach that works very well for thousands of businesses in the world.
The "Cleaning up" sounds like washing up the communal trash can, disinfecting and polishing it every time it's emptied, or writing a harddrive full of one's before formating...
As I understand it:
What I don't understand is, why this takes so much time. To me it seems, there's quite old code that handles memory management in a very ...ehm... special way (good read on this topic which I love to share w/ newbies: https://gamefromscratch.com/c-memory-management-isnt-the-boogie-man-you-may-think-it-is/ ).
What I - in a naive way, probably not being able to understand the main and critical underlying problem (as long it's not organizational), would consider was creating something like a "meta control block" that surrounds the entire object hierarchy and uses an algorithm like e.g. Boost's rbtree_best_fit https://www.boost.org/doc/libs/1_77_0/doc/html/interprocess/memory_algorithms.html
Alas, I suggested more if I could read the code.
ZBrush doesn't have the complex interrelations that DS does. Maya has similar features - I've forgotten the name since starting to write, but it dos have something similar to the ERC links that DS uses and of course a Maya file can have links to proxy objects which are like the way Daz Studo refers to external assets. However, when people in making-of films boasted about the complexity of their rigs the number of links involved was vastly smaller than the number of links in a well loaded Daz human, so I don't think that aspect of their asset management often gets tested. Daz Studio is in a unique situation as it is building an extensible base that everyone can expand to taste - from what I can gather people working in Maya will rarely use assets pre-loaded with a vast array of options that they may not use, but try to keep things down to what they currently need; that is a very different approach.
Thanks for your reply!
I think you hit the nail pointing to pre-loaded assets not used: I't be great if there was a mode where I - as a user - could decide wich morphs could be loaded *afterwards*. E.g. instead of having DAZ loading all the assets and inter-asset links at bootstrap, they should only be loaded when I as user decide to loadthem. So the workflow would roughly be:
That's basically some sort of "lazy loading" where only metadata gets loaded (what is done anyway AFAIU every time when DAZ Studio starts).
But as said, w/o access to the source code (or detailed pseudo code), I assume, I don't grasp the complexity of what is going on at all.
B.t.w. - Turbosquid lists 160K+ models available (https://www.turbosquid.com/maya-models), so I guess there are people out there hoarding a lot of assets...
...I clear the scene I've been working on after saving it by clicking "new" before shutting the programme down and it drops from memory rather quickly. If I'm changing between scenes during a session, I do the same before loading a new scene as well.
Clicking NEW to create a new scene without any elements is a neat trick to get Daz to reduce its memory usage. I wonder if anyone has compared this to using the Purge Memory script to see which works quicker to drop the memory.
Hi all - I don't use third-party plugins in Daz, I only use Daz plugins.
Good tip, ty.