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
MS,
Tried the .off idea because I thought it might really be powerful. Like 'commenting out' a bunch of content. I tried it with an expression and I am not sure I understand the result. In this case anyways, if you add the off suffex to both the alias_head_eCTRL3duDaytonExpressionAfraid.dsf and the eCTRL3duDaytonExpressionAfraid.dsf the affraid expression dial disappears and I might assume the morph is not loaded into RAM. If you add the off suffex to only eCTRL3duDaytonExpressionAfraid.dsf only, the expression dial dissappears. If you add the off suffex to only alias_head_eCTRL3duDaytonExpressionAfraid.dsf the expression dial remains and the expression works. I am not sure it is a safe assumption but I think you have to apply the .off to both and if you do it will not read the expression into RAM. I was really hoping that one combination would have left the dial but it not work - that way I could have applied the off to a bunch of content that I didn't want loaded into RAM but I would still know it was there if I wanted to turn it on.
eCTRL would be a controller for multiple other properties.
alias_head would create an alias for the named proeprty on the head - the main property would usually be on the figure, though that isn't necessarily true for controller properties.
interesting - from your info, I would gather that the '.OFF' technique that D3D uses with his checkboxes in GenX2 probably coordinates related and dependent morphs as a group, where as my manual attempts would probably miss these dependencies, without identifying the file-dependencies manually.
Like you, I like to 'comment things out' to help minimize interactions when I'm debugging black-boxes.
I could see that even moving folders might also trigger this effect if dependencies exist across the folders (e.g. when a PA uses the core DAZ dials for part of an expression, etc.). I'll still hack at things like this, but I may pick my battles more carefully knowing this.
Thanks for the update.
--ms
TheKD,
Through my extraodinarily painful search and stare. . . . . I have discovered (although this is not what I set out to do; but, like Rex Murphy, I am at the point of making tools. . . . ) that G8F base when zeroed looks quite different than when initially loaded. Though nothing shows in currently used (yes I have 4.12.1), I believe I have ACDesiree morphs being loaded onto every G8F character when it loads (including the base female). I recently reinstalled G8F and the Starter Essentials when I thought I had somehow corrupted my base G8F and this has had no impact. When I do a filter search in the Patrameters Tab> and find them they are default 1.0. This may not be the place for this question: can I fix this easily. Or is it best to delete them when I find them. How do you find non-zero default morphs?
If it doesn't show in Currently Used when G8F is loaded, does it show in Currently Used when you zero G8F?
Mike,
Yes. It shows as zero.
So if you zero G8F anything that isn't zeroed when you load g8f should show in Currently Used.
Right. Got it. Thanks. There is a small list (10) that is confirmed by the Log File most of which I think I can live with and are mostly harmless. Some I cannot move even though they are not locked, some appear to be linked to the 'Kitten' geograft product, some are left and right leg adjustments (these dials move but don't appear to do anything), and then there are the two ACDesiree (head and body) morphs (that I would like to resolve because they are being applied to all G8F when loaded) .
The time reported in the Log File is not really the time it takes to load, but I am not experiencing the time in loading problem, I don't think, that is being discussed elsewhere. My issue is the amount of RAM being consumed when the characters are loaded.
Load G8F and go to the Parameters or Shaping pane, find the dial for the morph that is active when you load G8F, click the gear icon above the dial at the far right, choose "Parameter Settings", and set the Default to 0.
Tried that. A couple of times. Including restarting. There must be something about saving it as I am trying to permanently change the default value and this does not save it.
Edit: Two down; eight to go. I couldn't get the changes by editing the default values in parameters tab to 'stick'. In the case of ACDesiree head and body morphs I edited the .dsf in Notepad++ changing the 'value' from 1 to 0. All seems to have worked. The others are proving to be a little more difficult. There are three related to 'Kitten', two of which are hidden, that cross reference. They have values of 0 but 'install' at 100% so there is something else going on with these. The other five I have not gotten to the bottom of yet - some at least are linked to chungdan products?
Dangerous though it may have been, I tried moving a FBM and FHM about my runtime:
I tried to make DAZ Studio think it was a clothing item pose/shape; I tried to make DAZ think it was a pose; I tried to make DAZ think it was a shape. Nope. Admittedly I didn't do a restart each time but if that had made them work it would have meant they were loaded into RAM which is what I am trying to avoid. It still makes me wounder why clothing morphs only load when the clothes are loaded? Or if Shapes are loaded into RAM or not and if not wouldn't that be a awsome/better? way to package characters.
lol...
living on the edge, are we? :) I love it.
I've found that when I muck with these folders, that using the content browser right-click->'refresh' and then loading a new character are enough to reflect my changes. I have no idea if the content manager database syncs with any of this, as I disable it entirely on my systems (not recommending to others, one of my own special 'edge's :)
One something's in RAM and in the scene (e.g. a loaded figure), I'm not sure anything but a restart will really reflect the kinds of changes we're making in the RAM status... Most contemporary systems seldom free RAM once they grab it... :^o (who would ever need more than 640k of RAM, anyway ? :)
interesting progress,
--ms
Some poorly packaged morphs come enabled by default, to get rid of their unwanted effect on all of the related characters (genesis xxx), you have to zero the character, memorize it and save the changes into the default character (Save as... Shaping... Changed..., Someone having Studio open, could put the correct path here.)
Distributing morphs as enabled by default can result in for example all your genesis 8 characters to open with a huge horn on their forehead, all of them, the old ones included.
All the morphs include the information/mesh related to the morph, the more morphs you have installed, the more time (and memory) it takes to load that character. As opposed to the gen 4 and older characters, Genesis-characters load all the (generation-related) morphs together with the character, even though they are not used.
MS,
I'm older, so you might not appreciate how uncomfortable this can be. I watch my son on a PC and admire the ease with which things are intuitive and unconstrained...Anyways .... As part of my process, of trying to free up RAM, I have done a couple of things: one was a fresh install of the most recent DAZ Studio versio: 4.12.1. This included a reinstall of G8F and Starter Essentials. Whether necessary or not, DAZ has decided it needs a newer CUDA version than my video driver had; so, although MS thought I was up to date, apparently I was not. That took a while to figure out why my renders were only being done by my CPU. I also still had a small number of non-zero default morphs likely because of things I have done, perhaps how the items are packaged in some cases, or perhaps because they need to be that way. Who knows. I also reinstalled V8 and Elizabeth because I had Elizabeth loading with every G8F. That solved that, but I still had 10 morphs to resolve. The head and body morphs of ACDesiree were 2 of these. I corrected that by changing the 'value' in the .duf/.dsf? in Notepad++ from 1 to zero. That left three groupings: three related to the Kitten product, three related to chungdan it seems, and two that look to be linked somehow to G3F leg poses but they don't seem to do anything. I exchanged emails with the developer of Kitten and was unable to learn whether I might attempt something like what PerttiA has suggested (Not sure if this would need to be done for every character. Seems back to front to me. I might misunderstand.) What is interesting in this case thougfh is that the morph file appears to show the value as zero even though they are loading as 100%.
TheKD,
I also began the process of trying to evaluate my G8 content to see what could be retired or loaded as required. During the AM exchange, the developer of Kitten had suggested some issues with Auto Face Enhancer and, as I too had had issues with warnings and missing files, I elected to set it aside. (I put it in its own runtime) I have both the stand alone and bundle which combined are about 1.6GB. When not loaded it reduced the RAM consumption on loading a G8F by >100MB. The lesson learnt here could be that some of the geograft products, expression or morph sets I have could provide a much more significant reduction in RAM consumption than does a character..
I had thought I would start with my +/- 150 G8F characters. I spent a day'ish trying to figure out what to do. {In the past when I loaded Sharah HD I had 100% of Sharah's head and body morph, 100% of Elizabeth's head and body morph, 60% of Olympia's head and body morph and 50% of V8s head and 65% of her body. I has litterally taken years to figure out it was not as it should be, and then correct the problem permanently. When I load a chacacter now it even looks like the promo.} This has helped me understand though that I have some simple characters that have two morphs and some skins; others that are for G3 and G8; others that are reasonably stand alone; some HD, some not, some both; some packages that are heads only , bodies only aor both; and some, mostly as part of bundles that have dependencies. After spending and spending time and money developing my collection, it is going to be hard to retire/hibernate some portion of it. I am still imagining some group of complete retention, some group of complete retirement, and then keeping the heads and skins, and keeping only skins as perhaps four runtimes. After a day I got through about a dozen and didn't definatively decide on anythig. . . . Not great.
I also have a variety of graft products and morph products. I may start looking there in parallel - if only I could. When I bought it, there was some reason that it was justified that I may now not recall. It is also likely true that I don't know what I routinely use or I may not even be consitent. (To help a certain pose I may search for 'gravity' or 'hang' or in another case I might look for 'squish' or 'flatten'. Years on in some cases, I have no recollection of which package something might be from; or most importantly, what is my optimal set of morphs or morph packages. Similarly for expressions some of which may be stand alone and some part of pose packs. And unfortunately similarly for the grafts. For example I have NGV8, which I most often use, and Golden Palace, that I occasionally use.) And sometimes there is content that is unclear as to whether it is a replacement version or a supplement causing me confusion as to what/if something can be deleted. What's more, as I look at Golden Palce, as an example, there is clearly difference in my runtime between the content of Golden Palace and Golden Palace v2. And in some cases/products I am sure, custom characters will need the versioning to match.
All that to say I am interested in how you are progressing and what criteria you are using as part of your selection process.
Ok, back home and here's the process... If dealing with Gen8, load the developer version (the base figure will also do) into an empty scene, then "Zero Figure", "Memorize Figure" and "Save As -> Support Asset -> Save Modified Assets"
This will return the Gen8 base figure to default values by changing the non-zero default values in any and all ill-behaving morphs to zero.
No need to do this on any other figure, except for those in saved scenes and/or modded figures that have already been saved with the ill-behaving morph with the non-zero default value in place.
The Gen8 figures that are loaded from the library, are using the default base figure and making their own adjustments and changes on top of it => When your default base figure along with all the installed morphs for that figure are zeroed, you will get the results you were expecting to, instead of a figure with a huge horn on their forehead.
PerttiA,
Sounds so easy. Tried it and the conclusion I come to is that I have already tracked down the non-zero defaults. Nothing changed. I am surprised though that I have three Kitten related morphs loaded at 100% when I have none of the Kitten grafts applied. Maybe I need to try reinstalling. Thanks again.
The kitten morphs appear to just be placeholders, they don't do anything unless the graft is attached. They are used to control morphs on the graft only, if it is attached.
So I removed Kitten. Saved ~100MB of RAM consumption when G8F was loaded. The three 'placeholder' dials disappeared. When I remapped the Kitten runtime the dials are back and the RAM consumption is back up. (And my Kitten based characters load fine.) All I think unsurprising, with perhaps the exception of the size of the RAM difference. I am sensing that I am going to be giving some serious thought to the number of 'anatomy' extras that I have. In the very limited testing I have conducted they would appear to disproportionately impact RAM consumption.
Oh dear. I wonder why empty dials would use that much RAM. Or maybe it preloads all geografts too, just in case? That would seem strange behavior. I should test all my geografts at some point before I start my great reinstall of 2020 lol. Good info to have I guess. Another person called about a job, so it seems my great install will not start next week either lol.
Not sure I would conclude a link between the dials and the RAM consumption directly. When I look at the properties of the data folder for kitten it's about 76MB. So perhaps the more appropriate conclusion is that there is a link between anatomy extras and their morphs and the RAM consumption. (Just not sure I understand the magnitude here as compared to the character morphs. My speculation is that these products have many more vertices and so the morph files are larger. And/or they load by default at a higher SubD? A G8F I think has 17K vertices at base resolution. Kitten Genitalia graft: 1.3K, Kitten Lashes: 31.5K; Kitten Torso graft: 4.5K; Kitten Legs graft: 2.2K; Kitten Head graft: 2.1K; Kitten Breast graft: 2.0K; and Kitten Arms graft at 3.4K. These are all base values and I think they load at high resolution ie 4 times these values. But if the graft's morphs work on the base resolution that's still a pile of deltas. And the lashes value is very interesting. One wouldn't want to be carrying too many redundant lashes morphs??) Good luck with earning money. i'll let you know how I progress.
The size difference comes from the morph-mesh loaded with the dial, and the way the morph has originally been made.
If I were to make a morph that raised the eyebrows, I have a choice of making the morph with just with the bare mesh of the head (skin) or with the complete mesh of the figure, eyes, teeth... all included. If I did the latter, the morph would use so much more ram than doing it with just the skin of the head.
Gen 4 and older figures load these meshes as you "inject" them into you figure, but Genesis figures load everything you have installed at the time you bring your figure into the scene or when you open a previously saved scene = If you see the dial, the mesh was read into your figure, increasing the memory consumption and making it a little slower to open.
If this is true (no reason to doubt), it'd be a great for someone to write a utility that analyzes and minimizes these morph-based meshes to *only* the vertices w deltas - kind of like a morph decimator. Would certainly help w the apparent problem.
Similarly, puppeteer presets save *all* morphs in a loaded character - whether they are used in the puppeteer session or not, which can make them quite huge, and when most of the saved data is irrelevant - as usually 95% of the relevant morph-settings are unchanged in a given session. Worse, these saved unused morph-settings actually override all existing figure morphs when applied to differently morphed figures in later sessions.
Interesting design defaults, these.
I wonder if such a utility could be written, per your description of what's going on.
--ms
So I decided to start the great pick and choose install of 2020 lol. I have noticed in troubleshooting threads, that people say errors about control dials not being able to find other control dials are harmless and don't affect load times. I am not sure what product caused it, but there was 5 error lines like that which appeared in my log during a load test, something was trying to find the baby morphs, before I installed any of the baby stuff. My load time shot up to ten minutes, then I installed the baby stuff to see if the log errors cleared, and the load time went back to under two minutes right after.
I too am on this journey and it has not started well. I finished blending my data folders and successfully eliminated duplication. In my personal log I came across a reference to DB maintenance (Context specific RMB while in Smart Contemt.) Related or not, I managed to fry my hard drive - or at least the partition with my recently improved DAZ content folders. Since this was the step prior to backing up, I am having to go back a few months as a do over. Not really great. But there is a point. As I reinstall content I am testing the default versions and, where available, my creations. Obviously (maybe), I am encountering my versions of characters that are missing content. For instance, as i load my version of MegaM, created while I had Kitten and AutoFaceEnhancer installed, I now get a series of missing file messages because I do not have them currently mapped to my DAZ content directory. That might be what you are encountering.
As I reinstall I am trying to assess what to partially include and what to not include as a way to manage RAM consumption. The first thing, might be obvious, to share is that when some characters say for instance Gabi HD for Leisa 8, the 'for' has varying degrees of significance. In the sited case, Gabi does not look at all good without Leisa. In other cases it is not as dramatic but you need to consider that as part of your strategy. Don't be reomving something that is required for something you want. I am also encountering a few characters that only have head morphs and skins. The real punch line might be that there is more to be saved looking at expressions and geografts; or if you might have an entire pro bundle where you are thinking about removing all of the characters.
I am still wrestling as well with the character specific shapes, expressions, or pose/expression combinations vs general sets that apply to the family. More on that when I sort the current catastrophy. . .
On the wondering list, DTG Studios produces Sara which has a Head but no Body morph. It uses 'default' morphs mostly to obtain the Head and Body shape. I wonder at this as a strategy overal, and I wonder if there is a way to approximate custom expression sets with default morphs so as to eliminate the RAM load.
I think doing something like that would end up being really complex - as it sounds like we'd be sort of re-creating one morph state with a limited collection of existing 'standard' morphs, which would be hard to get right to start with, but probably impossible to match any refined custom (zbrush) morphs with the more coarse default morph set(s). I like the concept though.
I once felt brilliant for thinking I could create a new custom figure with my various character sliders, export it as an OBJ, then reload and burn in that new result into a new independent slider - and then get rid of the RAM eating dependencies that were used to create it to start with - easy! (not)
It's still kind of a viable idea, but because there are many related morphs (e.g. Hitomi's eyes and jaw change radically when her facial morph is dialed), my single-slider idea can't really work if it doesn't also coordinate with those various related (ERC and related corrective morphs) sliders that are designed into a well-configured character...
Experts may know a better trick, but it kind of makes sense that a figure *usually* isn't just some vertex edits attached to a slider. The good ones kind of warp everything in concert to really establish the desired (and correct) look.
--ms
ms,
Yes indeed. Not sure it would ever reach the level of some of the high end head morphs but it might be an option for expressions. A better option might be a set of expressions or two that satisfied 95% and the rest you left for special characters or purposes.
TheKD
Related to the above, I have encountered another consideration in my rebuild process. I am having to reinstall some of my characters because of the hard drive failure. In many cases I have created my own variation(s) saved as a scene subset to the same folder as the original character (just with some extras and hair etc.) We may have been saying this all along, but reloading my own characters is listing a long list of missing files. It would seem that many (all?) morphs that are present when the character is saved are leaving a slot/channel/footprint/memory/space in the saved character file and they come up as missing during loading if they are not present. While this will not impact RAM consumption it might impact loading times. It makes me wonder at the utility of a strategy I am considering of compartmentalizing collections into specific runtimes.
per this effect, it's hard to describe, but let me try:
- DS obviously uses the real/original geometry and resources from the original mapped content libs when you load and make a scene.
- but, it also caches some of this data, in the ....../data/auto_adapted/... directory of one (or more?) of the mapped content folders - probably for efficiency.
- when you reload a scene, if the original mapped content isn't there, I *think* it looks in the cached folders, in case the equiv data is there
- if not, those errors occur, and aren't as obvious as the simple 'missing items' messages you'd expect.
My take-away, and anyone who knows better, please chime in, is when building a scene, DS generates cached files in the background, placing them in one of the .../data/auto_adapted/... folders in your content library. I would guess it's the first one in your list, but I really do not know how it decides.
Upon content library mapping, ordering, or other adjustments we might make, the original data and/or the cached files may or may not be able to regenerate your scene at a later time.
To be sure, if you have all of your scene dependencies available, no matter where they were mapped originally, if they are there at all DS should find them and use them. It's when we 'unmap' our data out from under DS that the seemingly odd message occur, when the real items *and* the cached items cannot be found and DS has to surrender to the truly unfindable data and generate the error.
Two things I do, that I *think* help here, is I try to never mix my saved data with my original content libraries - so I map my own DS project lib, and then I map my program and content libraries (which I keep separate too). This means that I have people/figure libraries that are 'sacred' all original, and my own 'space' - project oriented, that I save too. It's a bit of a pain to have multiple people/figure folders (orig and mine), but at least I know my work is separated from the original content and won't be lost by accident. YMMV.
I also always try to keep a sense of those .../data/auto_adapted/... folders that appear and I consolidate them by periodically shutting tdown DS and moving all of the content folders in these various auto_adapted directories into one central .../data/auto_adapted folder (I pick one) then restart DS, knowing my caches are consolidated and not strewn about my various mapped libraries.
I do *not* know if this is OK in the DS program operating scheme! I just made this up to solve my own issues! e.g. Multiple instances of DS seemed to work, but was never actually OK, so this may suffer the same risks. All I know is by doing this, the cache relics strewn about my libraries are at least somewhat managed and not as apt to become a problem w side-effects.
Lastly, given that these are cache files that DS generates, I believe you can simply remove them (I don't know for sure though), and if your scene dependencies are missing, you will get errors on loading, and if they are available to your scene when you load it, you won't - and all will load fine...
I would like to know which mapped library is used for this caching (how it is decided), as I would always put that library with the active .../data/auto_adapted/... folder on a (stub) content library and put in on an SSD if I knew I could count on DS to behave in that specific way. Anyone know? First one found?, first one in the mapping list?, registry setting?, folder that contains certain data elements or content? I dunno.
cheers,
--ms
auto_adpated is for converted Poser content, DS does cache things but not like that (see Edit>Preferences>DSON Cache)
Vice-versa, for Poser content (it looks in the converted fiels first, then tries to find the original)
It's standard to have your personal content folder (default "My Library") first and the DIM-installed content (default "My Daz 3D Library") second, so that your files aren't saved to the same place.