That sounds like a metadata issue, the RSL/MDL tags are not on the thunmbnails but are added by DS according to the database entries.

I just got done reinstalling all my content again. Then I re-imported all my metadata.

Perhaps I should have done that first? Maybe the metadata was outdated because I had installed and uninstalled so much content?

I can find all my content now. So I can go back and redo Categories.

Despite the positive seeming title this is more of a call for help, I recently got into DAZ on the side and holy smokes is it an exercise in patience! :)

This was probably asked and answered multiple times, sorry if this is the wrong place for the topic I don't normally do forum stuff. 

Currently for practice I'm trying to take the genesis 8 female base mesh into Blender so I can remove the ear and replace it with a flat surface, like an alien head or something.

Using diffeomorphic, got mesh into blender. So far so good > Select loop around ear and hide it, press L on the ear itself to select the whole ear, press alt+h to unhide the loop i hid earlier and deselect the loop > Delete ear > Create polygons in new hole to make a flat surface > Smooth the area little by little in sculpt mode so it's flat but still organic > Unwrap uv's > Rescale/Realign/Reposition UV island over ear UV to blend texture > Export/Import to DAZ > Apply PBR Skin shader > Try to apply literally any material > Doesn't work? Mesh stays white > Manually apply textures to face, body, arms, it works > try to apply skin material again > Fail, you suck, terrible artist, go work at mcdonalds. 

So... where did I go wrong?

I attached an image from DAZ to show the skin "working" and also the error message that comes up when I try to apply a skin material and the other image is the UV's in blender. I'm not worried about the visible seam although it lined up and blends kinda nice without playing with the vertices tooooo much. My issue is when I try to apply materials or assets... computa says no. Any help with this, or any general tips for DAZ that will cause less ulcers moving forward would be fan-fricken-tastic!

I too suffer from this (and have for 4 years now...not just with Materials, also with Scenes/SubSets/and Poses) and since DAZ seems to want to pretend it doesn't exist, I had to come up with my own way...

First of all the PROBLEM is with CMS database, and when a NEW SAVE first writes the "/Default/Saved Files/WHATEVERITIS" catagory field....

So one work around for a fast save that read about a couple years ago,is to right clicking ont content Library tab and choosing "Stop CMS/SMART" Do your saving then Right Click Content Library tab Again and Choose "Stop CMS/Immediate" and Right Click Content Library AGAIN... (getting old....) and Choose "Start CMS".  So you will see that when you do this it will save the file in under a Second.... EXCEPT now you have no Meta.... So you're going to have to manually but the meta data in with the Content DB editor....

Now you could also Save it outside of Daz in a TEMP location for a fast save and then copy it into your "Materials" file for the Asset, still won't have metadata and also will the wrong absolute path in file, (though I'm sure you know daz will ignore this and use a relative path for the file..)

Well that gets old too...

So the MAIN way I do this now, when I am Setting up my Character (Subsets),Wearables and Material Presets is to Create ALL the files FIRST as a TEXT file in the Character or ASSETS Folder...

and then change the .txt to .duf 

Once I have that done I go into folder in DAZ for the file I made, hit refresh... and I see the ! (icon) now I right click Content Library Tab and Open the Content DB Editor.... and then select the new "Material files" Up top, then again in the Catagories, and Then Right and choose "Add Custome Categories to Selected File(s)" I then go to a list I made in text file, of ALL the "Default/Saved Files/"  Catagories that Daz uses.... and Copy this:

/Default/Saved Files/Preset/Materials

And then Paste that into the Path(s): field, Hit Accept, Then Accept Again.... and THEN with the Asset selected I hit the (+) sing and save out a Material choosing the file made, and it will save WITH metadata in a second...

So here is a list of ALL the Default/Saved Files that DAZ writes when you are using the (+) sign to save ( there are more that it uses for when saving out as a Figure/Asset, and if you are having LONG saves while doing THAT, I would suggest NOT checking Set Catagory.... Because THAT is the same field that is causing the Slow down for the these Items... With it unchecked the Asset will save in a few seconds, not minutes...):

-----------------------------------------

/Default/Saved Files/Scene

/Default/Saved Files/Set

/Default/Saved Files/Prop

/Default/Saved Files/Preset/Wearables

/Default/Saved Files/Preset/Materials

/Default/Saved Files/Preset/Materials/Hierarchical

/Default/Saved Files/Preset/Layered-Image

/Default/Saved Files/Preset/Shader

/Default/Saved Files/Preset/Simulation-Settings

/Default/Saved Files/Preset/Pose

/Default/Saved Files/Preset/Pose/Hierarchical

/Default/Saved Files/Preset/Morph/Apply

/Default/Saved Files/Preset/Properties

/Default/Saved Files/Preset/Camera

/Default/Saved Files/Preset/Render-Settings

/Default/Saved Files/Preset/Light

-----------------------------------------------------------------------

It is Ridiculous to have to do it this way but it is MUCH faster then waiting 5 or 10 minutes PER first save of each item.... also if you later wanted to add a new preset to that file, you can "COPY" that catagory for the Item

from a similar one to a New MANUALLY created txt file turned into a duf with the method mentioned above (so it is visible in your folder in daz as an ! (icon), then in Content DB Editor with THAT and similar preset type (ie Material) that has Already been saved, open the triangle of the previously saved one under catagories and Right click on the"/Default/Saved Files/Preset/Materials" that it already has and choose Copy Selected Catagories to Listed Files...

Either way listed above requires alot of MANUAL work.... and while It will Save you time on the Saves, you are SPENDING time doing it Manually, So I too would love it if DAZ would fix this, The simplest way would be for them to create a Box that could be ticked to Save Metadata or NOT save Metadata.  The Code line already exists as it IS an option you can toggle for Metadata in one of Riversofts Converter Scripts... (don't recall which one)

Last but not least there is Yet ANOTHER option... And that would be to create a new BAREBONES Content Library all together using the Content Directory Manager... Of course doing this requires ALOT of switching Back and forth between the new LOW ASSET BAREBONES Library, and your Main Library which you will THEN also note that everything you quickly saved in your new BAREBONES Library, shows up with NO metadata in your MAIN content Library.....So if you want them to have Metadata in your MAIN you will have to add that manually.... 

Which is why I eventually settled on the Method of just Manually creating the files myself and then manually adding the Metadata to them before I make my first real save in my MAIN Library.

Hello, 

I am trying to rig a Genesis 9. I tried Rigigy, MHX and Auto-Rig, everything failed. I don't know what i did wrong and/or what I didn't do. I wish someone could point me toward a tutorial or give me a hint I could work on. Here is what I did until now :

1. I create a generic Genesis 9 model. I only give him a face, then export it with diffeomorphic in base resolution and View and Render Subd at 0. I tried to export it both in A pose and T pose, with the same end result.

2. I import it in Blender with only the base Genesis 9 settings.

3. Once in Blender, I merge by distance and do an All Transform te be sure everything is at the same scale.

4.I try to rig, as written above I tried the diffeomorphic rigify and MHX. I tried importing with the Daz bridge and using the blender rigify and also tried with auto-rig pro, nothing worked.

8. I also tried to scale my character by 100 before binding the rig. But it did not work neither.

Every time I end up with a unusable monster who can't even move his legs or arms because some widget are missing or don't work.

Thanks in advance for your wise informations.

Fred

MrRogerSmith said:

jmucchiello said:

barbult said:

Copied and pasted from a post I made in April 2025: 

With Geometry Editor tool active, you can export the "curves" hair, move the vertices in a modeler, and with the Geometry Editor still active, import your modified OBJ to DS to create a morph. You do not have to be a PA to do that. I have made several morphs for PA dForce (strand-based) hair products that way.  I have posted this in the forums a couple of times at least. You can even simulate in DS and export that and reimport it as a morph. The key is to have the Geometry Editor tool active during export and import. There can be millions of vertices in some of these hairs, so the morph creation can take some time.

How does someone who doesn't even understand "export the curves hair" step and has never run a modeler even begin to do this? Asking for a friend. :) I posted elsewhere looking for help with upside down hair and this seems like the right solution, if only I knew anything about Blender.

 

You hide everything in the scene except the hair, put it at base resolution, activate the geometry tool, and export the hair as an .obj via the File menu.  WP Guru has some good videos like this one showing how to export/reimport to make morphs in Blender.

The OBJ export options now include one to export only seelcted geometry, so the hiding step is no longer required.

To be honest though I wouldn't start my journey in Blender with these strand-based hairs.  They are quite dense and trying to make the morph in Blender's edit mode isn't nearly as easy as sculpting it.  Working with so many vertices is probably a bit too advanced for someone brand new to Blender.

jmucchiello said:

barbult said:

Copied and pasted from a post I made in April 2025: 

With Geometry Editor tool active, you can export the "curves" hair, move the vertices in a modeler, and with the Geometry Editor still active, import your modified OBJ to DS to create a morph. You do not have to be a PA to do that. I have made several morphs for PA dForce (strand-based) hair products that way.  I have posted this in the forums a couple of times at least. You can even simulate in DS and export that and reimport it as a morph. The key is to have the Geometry Editor tool active during export and import. There can be millions of vertices in some of these hairs, so the morph creation can take some time.

How does someone who doesn't even understand "export the curves hair" step and has never run a modeler even begin to do this? Asking for a friend. :) I posted elsewhere looking for help with upside down hair and this seems like the right solution, if only I knew anything about Blender.

 

You hide everything in the scene except the hair, put it at base resolution, activate the geometry tool, and export the hair as an .obj via the File menu.  WP Guru has some good videos like this one showing how to export/reimport to make morphs in Blender.

To be honest though I wouldn't start my journey in Blender with these strand-based hairs.  They are quite dense and trying to make the morph in Blender's edit mode isn't nearly as easy as sculpting it.  Working with so many vertices is probably a bit too advanced for someone brand new to Blender.

New bi-weekly batch of “Limited-Time Free” from Fab (until April 7 at 9:59 AM ET).

• Stone Golem. A rigged monster character. Unity and Unreal formats.
• Scrapopolis - Steampunk village. A mostly exterior (one small interior) environment, with a few props. Unreal format.
• Not useful for Daz: Advanced Universal Spawner. Unreal code.

With Fab freebies, you can choose a Personal or Professional license. I always switch to the Professional license (since it’s free and gives you more).

Note that these are usually in Unreal or sometimes Unity, Godot, Blender, or generic 3D formats, so will require some work to convert for use in Daz.

I’m not aware of any tool for straight conversion from Unreal to Daz. so it takes a couple steps. First, convert from Unreal Engine to Blender format, then export/import between Blender and Daz. This article covers some ways of doing the conversion from Unreal to Blender: “Exporting from Unreal Engine to Godot, Unity or Blender”. Then from Blender to Daz, you can use one of the various tools, such as Diffeomorphic.

Please take replies and discussion to the discussion thread. Let’s keep this thread “Announcements Only”, as it was intended.

In general, if a partial body morph (PBM) is purely made with vertex position change (e.g. by sculpting) rather than simple Transforms of other bones, it doesn't need ERC Freeze.

Not sure how you made the morphs, but if you ever did Adjust Rigging to Shape as well as ERC Freezed that whole belly morph property, ERC Bake it firstly with Edit Mode, then check if it works well when posing hip bone... 

Surely you can remake the morph by export / import its OBJ with MLP but firstly delete the DSF file of the old one... and do it with a Base figure with default zeroed A-Pose or T-Pose. 

Matt_Castle said:

TheMysteryIsThePoint said:

No one will ever convinve me that when there was ultimate freedom to determine how the framework would work, that the only way to make an extensible framework was to load all the morphs.

This is fundamentally flawed.

You are completely missing my point. Completely. You bring up, in fine detail, the problem space that a design is supposed to navigate and provide a satisfactory user experience. It doesn't. It is irrelevant if the problem space is convoluted or not; that is what the design was supposed to account for. If it does, it is a good design. If it does not, it is a bad design. Ful stop. No ammount of hand waving or creating empathy for the complexity of the problem can mutate this fact: the design was supposed to account for that. That is why architects make as much money as they do: the buck stops with their design. There is nothing else to blame.

Let's look at how the Genesis 9 figure works.

Let's not. If it is complicated, and I'm sure that it is, it was the design that determined literally everything that you wrote. There is no other place to lay the details of the current state of affairs but at the feet of the original design. Saying "But it is a hard problem" does not mean that an inefficient design is some how excusable. Engineers get paid to make the proper space/time tradeoffs until the user experience is satisfactory. I know of no principle that says that that is the engineer's responsibility "unless the problem is hard, in which case you can go with O(n^2) and expect no one to call you on it".

Genesis 9 is a mesh that is weighted to follow the bones of a virtual armature. This is strictly inaccurate to how people actually move, but as a technique it's been used for decades because the full physical modelling and simulation of a skeleton, how muscles fit to it, how those muscles fit against each other, where the internal organs go, where fat layers sit and how the skin is attached and stretches over all of that would be ludicrously intensive, and a weighted mesh is generally an acceptable compromise.

Even more so if you are prepared to go in and create corrective morph shapes to improve the weighted shape to something closer to physically accurate.

And G9 does quite a lot of those. Here's a list of the primary Corrective Blend Shapes of Genesis 9:

body_cbs_shoulder_x30n_l; body_cbs_shoulder_x30p_l; body_cbs_shoulder_z55p_l; body_cbs_shoulder_x30n_r; body_cbs_shoulder_x30p_r; body_cbs_shoulder_z55n_r; body_cbs_upperarm_x95n_l; body_cbs_upperarm_y110n_l; body_cbs_upperarm_z40n_l; body_cbs_upperarm_z90p_l; body_cbs_upperarm_y110n_z40n_l; body_cbs_upperarm_y110n_z90p_l; body_cbs_upperarm_x95n_r; body_cbs_upperarm_y110p_r; body_cbs_upperarm_z40p_r; body_cbs_upperarm_z90n_r; body_cbs_upperarm_y110p_z40p_r; body_cbs_upperarm_y110p_z90n_r; body_cbs_forearm_y75n_l; body_cbs_forearm_y135n_l; body_cbs_forearm_y75p_r; body_cbs_forearm_y135p_r; body_cbs_hand_y28n_l; body_cbs_hand_z70n_l; body_cbs_hand_z80p_l; body_cbs_hand_y28p_r; body_cbs_hand_z70p_r; body_cbs_hand_z80n_r; body_cbs_head_x25p; body_cbs_head_x30n; body_cbs_neck1_x25n; body_cbs_neck1_x40p; body_cbs_neck1_y22p_l; body_cbs_neck1_y22n_r; body_cbs_neck1_z40n_l; body_cbs_neck1_z40p_r; body_cbs_spine3_x35p; body_cbs_spine3_z20n_l; body_cbs_spine3_z20p_r; body_cbs_spine2_x40p; body_cbs_spine2_z24n_l; body_cbs_spine2_z24p_r; body_cbs_spine1_x35p; body_cbs_spine1_z15n_l; body_cbs_spine1_z15p_r; body_cbs_pelvis_x25n; body_cbs_pelvis_x25n; body_cbs_thigh_x35p_l; body_cbs_thigh_x90n_l; body_cbs_thigh_x115n_l; body_cbs_thigh_z90p_l; body_cbs_thigh_x115n_z90p_l; body_cbs_thigh_x35p_r; body_cbs_thigh_x90n_r; body_cbs_thigh_x115n_r; body_cbs_thigh_z90n_r; body_cbs_thigh_x115n_z90n_r; body_cbs_shin_x90p_l; body_cbs_shin_x155p_l; body_cbs_shin_x90p_r; body_cbs_shin_x155p_r; body_cbs_foot_x45n_l; body_cbs_foot_x65p_l; body_cbs_foot_z45n_l; body_cbs_foot_x65p_r; body_cbs_foot_x45n_r; body_cbs_foot_z45p_r; body_cbs_toes_x40p_l; body_cbs_toes_x60n_l; body_cbs_toes_x40p_r; body_cbs_toes_x60n_r

And this is a list that omits things like all the ones on the fingers or toes. This is just the larger joints.

Now, if we look at the first on the list, body_cbs_shoulder_x30n_l, this is a shape which is intended to be active when the left shoulder's X rotation is negative 30 (shoulder for shoulder, x30n for negative 30 x, and _l for left).

We immediately have our first case for wanting bottom-up links. We do not want to have the primary bend parameters of a joint to need to be changed every time someone wants to hitch a new control to them. So, in this case, another file, not the primary rigging, will have to tell Daz Studio that body_cbs_shoulder_x30n_l is something that should be linked to the shoulder's X rotation. And, fundamentally, why have an entirely separate file to do that? Why not have it in the header section of body_cbs_shoulder_x30n_l? DS can look in the top of the file.

Okay, now let's suppose we want to install another character on to G9. Victoria 9's morph changes the shape enough that the original CBS shapes are no longer quite right, so she's going to need her own CBSs.

Even looking past how you drive her CBSs (it's much more practical to just hitch them onto the base ones rather than have to set up all the rotation multipliers separately), her CBSs however need to only activate when her shape does. So you want all those new shapes to have a link to her main morph. Now, Daz *could* put all those links in her shape, but that would mean that if Daz decided she needed an extra CBS they'd missed before, then that means adding a new CBS, and also adding links to it into her main morph file, and generally causing havoc with versioning. If those links could only be saved into her file, it would also be a nuisance any end user deciding that she needed an extra CBS, because then they would have to edit her file, and re-edit it every time a product update came through.

As such, it is better for the links for character specific CBSs to be bottom-up links exist in those CBS files themselves.

~~~~~

Now, even if we for some reason assume that it was even viable to have only top-down links, Daz Studio still needs to know more about each DSF file attached to the figure it has than just what its file name is.

Firstly, DS needs to know what the morph should actually be called on the user side. It's all very useful to have a behind the scenes convention for file names, but they're ugly and unfriendly on the user side. "Victoria9_figure_ctrl_Character.dsf" is informative for technical purposes, and avoiding spaces in the file name makes certain things easier (although admittedly Daz have been inconsistent about enforcing that as a standard), but "Victoria 9" is what end users want to see.

DS also needs to know what the limits of that morph are. Is this something like a height slider which can go from -100% to 100% to make the character taller or shorter, or is this a character morph that would be an eldritch horror if it were dialled in backwards?

They need to know whether the morph should be shown to the user at all. Imagine if all the CBS files across every character were permanently visible.

They need to know "hey, this slider has a picture to help the user see what it does".

They need to know "this slider is tinted light blue to help differentiate it as a morph from the G9 Body Morphs set, where as this shade of yellow implies that it's a core character."

To be functional, DS needs at least this "metadata" about every morph, even if it does not attempt to load any of the actual shape information about the morph. This is not feasible to encode into a filename. Even if you tried, you'd end up with a colossal problem every time you had to update something, because now that old scene file where everyone's Daz Studio is expecting that a character should have 50% of some morph file with an outrageous file name dialled in now can't find that filename any more.

So, Daz Studio needs this information before it can display the figure controls correctly, and thus it has to load this information about every DSF file.

Now, at present, this is all deliberately stored at the top of the morph files. Daz Studio can look in the top of the file and read that information. And, indeed, it actually stops when it gets to the end of that, and does not load the morph shape itself until the morph is actually activated on the figure. You can see this in the log file if you activate a morph you haven't yet; it will tell you that the morph deltas for that morph have just been loaded.

~~~~~

The only even marginally feasible workaround I could see to this that doesn't force the user to manually specify what morphs they want loaded is permanently maintaining a database for every last figure (be it Genesis, a clothing item, a car, etc) and prop which collates all of this stuff and just that stuff. But that would itself need to be rebuilt every time the figure's morph library changed. And this would necessitate a large increase in the amount of drive space used by morphs, because not only do the morphs themselves still need to contain the information in order for such a database to know what to do with them, the database would itself end up duplicating all of that. 

But if you have a suggestion for how Daz Studio could genuinely work by just being able to skim read file names and not know anything about what's inside them, then by all means, let us know. We would all love Daz Studio to be faster.

And you've proven my point better than I ever could. You've pointed out in much greater detail that I knew how to, that the design has serious inefficiencies where some tradeoff should have been sough, but wasn't.

Otherwise, your claim that you're unconvinced by the solution they've implemented is empty.

OK, I guess we will just have to let history be the judge.

That's probably the best argument for Open Source-ing DAZ Studio that I've ever heard.

That I think would be a bad idea, because ultimately the entire Daz infrastructure relies on having a concrete framework upon which others can build and work. Making that kind of thing work requires oversight and direction.

What you've accomplished is to clarify your opinion that DAZ would not be capable of providing oversight and direction. Open Source has worked out exceedingly well for so many projects that I'm not going to bother to name any of them.

That said, except for a couple of their more proprietary techs, Daz Studio formats are mostly well documented.

If I am wrong, then pease excuse me, but you have never actually tried to write a non-trivial plugin, have you? The problem with what you wrote above is that, yes, DSON is better documented than the SDK, and JSON is to some degree self documenting, but the problem is that DAZ Studio is not a purely data-driven application, i.e. the DSON does not tell you the whole story. As you say, I suppose I can forgive DAZ for not documenting their secret sauce for HD and autofitting since it is a rare far-seeing company that realizes that holding on to their IP, no matter how trivial it is probably retards the growth of their product, but there are things that you simply cannot divine how DAZ Studio goes from DSON to finished geometry from looking at it. And there are important things that a programmer needs to know that have nothing to do the data format.

If someone else was of a mind to, they could absolutely make another program read Daz Studio format directly (maybe even as a direct Blender plug-in, for example), and handle things that way.

This is the same falsity that I keep hearing over and over, by people who I'd wager have never written a non-trivial plugin. Knowing the DSON like the back of one's hand is not sufficient to duplicate everything DAZ Studio does. There is a lot of functionality in DAZ code, as opposed to the DSON. Again, it is not a purely data-driven app. There's logic in the code. I know this for a fact because I've been figuring things out for Sagan for 7 years now. Like memory ownership rules. In C++, when a function accepts a pointer, does it take ownership of that memory? Do I still have to free it up? Does it deep copy it, or just copy the pointer? Can I pass a local object or does it have to be on the heap? There's very little const correctness in the SDK, so will the function modify my object or not? It's very, very difficult to correctly guess all of these things, and even the shortest, simplest, yes-or-no questions go ignored in the SDK forum, if only a dev can answer it.

barbult said:

Copied and pasted from a post I made in April 2025: 

With Geometry Editor tool active, you can export the "curves" hair, move the vertices in a modeler, and with the Geometry Editor still active, import your modified OBJ to DS to create a morph. You do not have to be a PA to do that. I have made several morphs for PA dForce (strand-based) hair products that way.  I have posted this in the forums a couple of times at least. You can even simulate in DS and export that and reimport it as a morph. The key is to have the Geometry Editor tool active during export and import. There can be millions of vertices in some of these hairs, so the morph creation can take some time.

How does someone who doesn't even understand "export the curves hair" step and has never run a modeler even begin to do this? Asking for a friend. :) I posted elsewhere looking for help with upside down hair and this seems like the right solution, if only I knew anything about Blender.

TheMysteryIsThePoint said:

No one will ever convinve me that when there was ultimate freedom to determine how the framework would work, that the only way to make an extensible framework was to load all the morphs.

This is fundamentally flawed.

Let's look at how the Genesis 9 figure works.

Genesis 9 is a mesh that is weighted to follow the bones of a virtual armature. This is strictly inaccurate to how people actually move, but as a technique it's been used for decades because the full physical modelling and simulation of a skeleton, how muscles fit to it, how those muscles fit against each other, where the internal organs go, where fat layers sit and how the skin is attached and stretches over all of that would be ludicrously intensive, and a weighted mesh is generally an acceptable compromise.

Even more so if you are prepared to go in and create corrective morph shapes to improve the weighted shape to something closer to physically accurate.

And G9 does quite a lot of those. Here's a list of the primary Corrective Blend Shapes of Genesis 9:

body_cbs_shoulder_x30n_l; body_cbs_shoulder_x30p_l; body_cbs_shoulder_z55p_l; body_cbs_shoulder_x30n_r; body_cbs_shoulder_x30p_r; body_cbs_shoulder_z55n_r; body_cbs_upperarm_x95n_l; body_cbs_upperarm_y110n_l; body_cbs_upperarm_z40n_l; body_cbs_upperarm_z90p_l; body_cbs_upperarm_y110n_z40n_l; body_cbs_upperarm_y110n_z90p_l; body_cbs_upperarm_x95n_r; body_cbs_upperarm_y110p_r; body_cbs_upperarm_z40p_r; body_cbs_upperarm_z90n_r; body_cbs_upperarm_y110p_z40p_r; body_cbs_upperarm_y110p_z90n_r; body_cbs_forearm_y75n_l; body_cbs_forearm_y135n_l; body_cbs_forearm_y75p_r; body_cbs_forearm_y135p_r; body_cbs_hand_y28n_l; body_cbs_hand_z70n_l; body_cbs_hand_z80p_l; body_cbs_hand_y28p_r; body_cbs_hand_z70p_r; body_cbs_hand_z80n_r; body_cbs_head_x25p; body_cbs_head_x30n; body_cbs_neck1_x25n; body_cbs_neck1_x40p; body_cbs_neck1_y22p_l; body_cbs_neck1_y22n_r; body_cbs_neck1_z40n_l; body_cbs_neck1_z40p_r; body_cbs_spine3_x35p; body_cbs_spine3_z20n_l; body_cbs_spine3_z20p_r; body_cbs_spine2_x40p; body_cbs_spine2_z24n_l; body_cbs_spine2_z24p_r; body_cbs_spine1_x35p; body_cbs_spine1_z15n_l; body_cbs_spine1_z15p_r; body_cbs_pelvis_x25n; body_cbs_pelvis_x25n; body_cbs_thigh_x35p_l; body_cbs_thigh_x90n_l; body_cbs_thigh_x115n_l; body_cbs_thigh_z90p_l; body_cbs_thigh_x115n_z90p_l; body_cbs_thigh_x35p_r; body_cbs_thigh_x90n_r; body_cbs_thigh_x115n_r; body_cbs_thigh_z90n_r; body_cbs_thigh_x115n_z90n_r; body_cbs_shin_x90p_l; body_cbs_shin_x155p_l; body_cbs_shin_x90p_r; body_cbs_shin_x155p_r; body_cbs_foot_x45n_l; body_cbs_foot_x65p_l; body_cbs_foot_z45n_l; body_cbs_foot_x65p_r; body_cbs_foot_x45n_r; body_cbs_foot_z45p_r; body_cbs_toes_x40p_l; body_cbs_toes_x60n_l; body_cbs_toes_x40p_r; body_cbs_toes_x60n_r

And this is a list that omits things like all the ones on the fingers or toes. This is just the larger joints.

Now, if we look at the first on the list, body_cbs_shoulder_x30n_l, this is a shape which is intended to be active when the left shoulder's X rotation is negative 30 (shoulder for shoulder, x30n for negative 30 x, and _l for left).

We immediately have our first case for wanting bottom-up links. We do not want to have the primary bend parameters of a joint to need to be changed every time someone wants to hitch a new control to them. So, in this case, another file, not the primary rigging, will have to tell Daz Studio that body_cbs_shoulder_x30n_l is something that should be linked to the shoulder's X rotation. And, fundamentally, why have an entirely separate file to do that? Why not have it in the header section of body_cbs_shoulder_x30n_l? DS can look in the top of the file.

Okay, now let's suppose we want to install another character on to G9. Victoria 9's morph changes the shape enough that the original CBS shapes are no longer quite right, so she's going to need her own CBSs.

Even looking past how you drive her CBSs (it's much more practical to just hitch them onto the base ones rather than have to set up all the rotation multipliers separately), her CBSs however need to only activate when her shape does. So you want all those new shapes to have a link to her main morph. Now, Daz *could* put all those links in her shape, but that would mean that if Daz decided she needed an extra CBS they'd missed before, then that means adding a new CBS, and also adding links to it into her main morph file, and generally causing havoc with versioning. If those links could only be saved into her file, it would also be a nuisance any end user deciding that she needed an extra CBS, because then they would have to edit her file, and re-edit it every time a product update came through.

As such, it is better for the links for character specific CBSs to be bottom-up links exist in those CBS files themselves.

~~~~~

Now, even if we for some reason assume that it was even viable to have only top-down links, Daz Studio still needs to know more about each DSF file attached to the figure it has than just what its file name is.

Firstly, DS needs to know what the morph should actually be called on the user side. It's all very useful to have a behind the scenes convention for file names, but they're ugly and unfriendly on the user side. "Victoria9_figure_ctrl_Character.dsf" is informative for technical purposes, and avoiding spaces in the file name makes certain things easier (although admittedly Daz have been inconsistent about enforcing that as a standard), but "Victoria 9" is what end users want to see.

DS also needs to know what the limits of that morph are. Is this something like a height slider which can go from -100% to 100% to make the character taller or shorter, or is this a character morph that would be an eldritch horror if it were dialled in backwards?

They need to know whether the morph should be shown to the user at all. Imagine if all the CBS files across every character were permanently visible.

They need to know "hey, this slider has a picture to help the user see what it does".

They need to know "this slider is tinted light blue to help differentiate it as a morph from the G9 Body Morphs set, where as this shade of yellow implies that it's a core character."

To be functional, DS needs at least this "metadata" about every morph, even if it does not attempt to load any of the actual shape information about the morph. This is not feasible to encode into a filename. Even if you tried, you'd end up with a colossal problem every time you had to update something, because now that old scene file where everyone's Daz Studio is expecting that a character should have 50% of some morph file with an outrageous file name dialled in now can't find that filename any more.

So, Daz Studio needs this information before it can display the figure controls correctly, and thus it has to load this information about every DSF file.

Now, at present, this is all deliberately stored at the top of the morph files. Daz Studio can look in the top of the file and read that information. And, indeed, it actually stops when it gets to the end of that, and does not load the morph shape itself until the morph is actually activated on the figure. You can see this in the log file if you activate a morph you haven't yet; it will tell you that the morph deltas for that morph have just been loaded.

~~~~~

The only even marginally feasible workaround I could see to this that doesn't force the user to manually specify what morphs they want loaded is permanently maintaining a database for every last figure (be it Genesis, a clothing item, a car, etc) and prop which collates all of this stuff and just that stuff. But that would itself need to be rebuilt every time the figure's morph library changed. And this would necessitate a large increase in the amount of drive space used by morphs, because not only do the morphs themselves still need to contain the information in order for such a database to know what to do with them, the database would itself end up duplicating all of that. 

But if you have a suggestion for how Daz Studio could genuinely work by just being able to skim read file names and not know anything about what's inside them, then by all means, let us know. We would all love Daz Studio to be faster.

Otherwise, your claim that you're unconvinced by the solution they've implemented is empty.

That's probably the best argument for Open Source-ing DAZ Studio that I've ever heard.

That I think would be a bad idea, because ultimately the entire Daz infrastructure relies on having a concrete framework upon which others can build and work. Making that kind of thing work requires oversight and direction.

That said, except for a couple of their more proprietary techs, Daz Studio formats are mostly well documented. If someone else was of a mind to, they could absolutely make another program read Daz Studio format directly (maybe even as a direct Blender plug-in, for example), and handle things that way.

Andrew_C said:

So obviously the latest update, DS 4.24.0.4, was mostly about removing 3Delight, but I noticed today that there are update to the default resources & tutorials. What is that update for? couldnt find any info on it.

Metadata update for Scene Builder scripts for the resources and templates; I don't have the lessons installed so not sure if is the same.

memcneil70 said:

@manekiNeko, by any chance do you have your shopping carts or download documents and if not, can you use your Order History?

I have recently gone through this on my MacMini M4 and then a Windows 11 and did clean new installs of my products, including freebies and other site purchases. I started with the Default Resources that DIM has you do, and made sure they were in the correct paths and after that I had DIM sorted by Order Date and my online Product Library also by Order Date. I had to be careful not to exceed a certain amount during the month, so I had to be careful. After the essential stuff, I went for my plug-ins, scripts, Genesis Core characters, and then it was selecting by type of product an assortment (environments, hairs, poses, wardrobe, ...) so I would have some stuff to play with. But I avoided items I knew I hadn't used EVER, or had caused me issues, it took me around five months for half of my Runtime. And that is cleaning up missing metadata, thumbnails and stuff. I still have others to install. 

I do agree with you it would be so much easier to be able to match DIM and the Product Library's sorts up. The closest I got was selecting a PA's store and pulling up everything I own. Or using key words in DIM for specific items. The hardest is texture sets that are bought separate from the main item and don't have a clean name connection. I am still tracking those down.

Mary

i'm sorry to hear you had to go through this too.. and well, if i use DIM i can sort differently/more efficiently, like by SKU. thank you for having mentioned the textures tho, i might have overlooked that. i have probably most of my zips on a usb or two, like emergency rescues, but i'd prefer a clean install through DIM, even if that means redownload - those i have can stay as backup. 

it's not for tomorrow anyway. i knew i wouldn't reinstall on this old acer again because it never was optimal, and now i'm on linux so it's twice as complicated so even if i had reinstalled it would be a pain... but i just learned today that my old nvidia won't even work any more on the newest linux, no drivers supported. so we'll see this summer or later, if/when i can afford a "new" old laptop :/

@manekiNeko, by any chance do you have your shopping carts or download documents and if not, can you use your Order History?

I have recently gone through this on my MacMini M4 and then a Windows 11 and did clean new installs of my products, including freebies and other site purchases. I started with the Default Resources that DIM has you do, and made sure they were in the correct paths and after that I had DIM sorted by Order Date and my online Product Library also by Order Date. I had to be careful not to exceed a certain amount during the month, so I had to be careful. After the essential stuff, I went for my plug-ins, scripts, Genesis Core characters, and then it was selecting by type of product an assortment (environments, hairs, poses, wardrobe, ...) so I would have some stuff to play with. But I avoided items I knew I hadn't used EVER, or had caused me issues, it took me around five months for half of my Runtime. And that is cleaning up missing metadata, thumbnails and stuff. I still have others to install. 

I do agree with you it would be so much easier to be able to match DIM and the Product Library's sorts up. The closest I got was selecting a PA's store and pulling up everything I own. Or using key words in DIM for specific items. The hardest is texture sets that are bought separate from the main item and don't have a clean name connection. I am still tracking those down.

Mary

barbult said:

Copied and pasted from a post I made in April 2025: 

With Geometry Editor tool active, you can export the "curves" hair, move the vertices in a modeler, and with the Geometry Editor still active, import your modified OBJ to DS to create a morph. You do not have to be a PA to do that. I have made several morphs for PA dForce (strand-based) hair products that way.  I have posted this in the forums a couple of times at least. You can even simulate in DS and export that and reimport it as a morph. The key is to have the Geometry Editor tool active during export and import. There can be millions of vertices in some of these hairs, so the morph creation can take some time. 

OH MY GOD IT WORKED, IT ACTUALLY WORKED!

BARBULT I LOVE, YOU YOU HAVE NO IDEA.

Seriously, thank you!  That is amazing!  All of a sudden I own dozens of hairs that seem viable again. 

Copied and pasted from a post I made in April 2025: 

With Geometry Editor tool active, you can export the "curves" hair, move the vertices in a modeler, and with the Geometry Editor still active, import your modified OBJ to DS to create a morph. You do not have to be a PA to do that. I have made several morphs for PA dForce (strand-based) hair products that way.  I have posted this in the forums a couple of times at least. You can even simulate in DS and export that and reimport it as a morph. The key is to have the Geometry Editor tool active during export and import. There can be millions of vertices in some of these hairs, so the morph creation can take some time.

If the files don't have metadata (which is likely the case) it might not be recognized as hair by the script, but you can use force conversion to convert it anyway.

Metadata update for Scene Builder scripts for the first two, not sure on the third.