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
© 2026 Daz Productions Inc. All Rights Reserved.
Comments
Neither should it go without a note that those that dissent are the same people that gave us static header files that they can never update in a way that changes the symbols, i.e. just about any change that would make them more useful.
But maybe next time you could ask them to instead of defending themselves, to use the same time to answer some questions in the SDK forum? Just sayin'.
But again, do you have a better alternative that does what Daz needs it to - something along the lines of provide an extensible architecture for content items that can have new shapes, rigging adjustments, mappings etc. added and removed without requiring special actions (running additoonal utilities, invoking special commands to fiininalise the set up) - with less overhead than the current system?
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 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.
Sounds to me like you want to go back to the early days of DAZ Studio, when you had to load each set of morphs manually. Trust me it may have saved on render time, but the workflow was a nightmare.
Richard, I am not on DAZ Studio's design team, so I am not at all sure why you would want to use whether I have a better solution as an argument. I will only say that you probably thinking that you are raising a withering rebuke by pointing out these requirements, when in truth you are just pointing the deficiencies the original design was supposed to account for. It was the responsibility of the original system archtect to resolve the issues you state in a way that gives a suitable user experience, not mine years later and looking in from the outside.
Why do I always debate software architecting with people that are not software architects and think that this time they'll actually understand my points and accept them as the obvious and objectively true statements that they are? How can anyone possibly contest the statement that "if the user experience is bad, it is because of the design"? How can that be controversial in any way?
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 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".
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.
OK, I guess we will just have to let history be the judge.
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.
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.
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.
Personally, I would. And have the designers consider what design tradeoffs would need to be made to provide an adequate user experience even when the user's catalog is huge. I'm sure CS majors had to study Algorithmic Complexity back then, still.
No, it was the responsibility of the design team to design a system that met the requirements. You are asserting that they could have done better, but this needs suport - just saying they shgould have come up with a solution that did not have these drawbacks is not making a real argument if it is an unsupported assumption that such a better system existed. If you cannot propose - at least in outline, no one is expecting a fully-operational application - then you shoudl not assert that they failed to develop something reasonably close to an optimal design. If you are taking issue with the specifications then again, you need to show in outline that there were better specifications.
This is comically wrong. You are thinking of Waterfall development, and this is generally accepted these days as how not to do systems. With respect, Richard, it really seems as if you have no idea what you are talking about but are thinking that the fact that you're a really smart guy is somehow going to compensate for that fact. It isn't. The things you are saying make perfect logical sense, but they are not informed by actual industry experience that one accrues over years or decades.
What makes your statement so wrong is that a design team that doesn't dig a little deeper into the requirements and ask "What could change in the future" should probably not be doing design. If a wrong assumption or change renders a design inefficient, it's a bad design. Yes, this can get complicated. Yes, people like Grace Hopper and others have been searching for the ultimate way to contain complexity and there seems to be another paradigm every few years. But that's the job of the analyst and architect. And it is a tough one.
I am 100% certain that they could have done better. Do not think that DAZ Studio is the only app that exists in a complicated context. I can't talk about my day job, but don't think that DAZ Studio is unique or even close to as bad as it can get in terms of complexity. But in any case, I think these irrational and emotional reactions may be coming from the fact that these are probably people that you work with, and you perceive what I am saying as some sort of slight. It's not. I think I've said it a few times now that this is simply an unfortunate truth of software development: you almost never get to design and implement the system the way you know you should, and the way you want to. That's how I can pretty confidently say that they could have done better because in my entire career, I cannot think of an instance when I thought "Yep, I've really outdone myself... it's a perfect thing of beauty". There are always things that future me is going to look at and throw up in his mouth a little. If you want to just say that that is no insight into the software business and I don't know what I'm talking about, that's up to you.
I'm sorry, I only do free analysis for Open Source projects where I feel like I belong to some sort of community. But again, if you prefer to think that DAZ Studio is somehow unique in the world and I just don't know what I'm talking about, you're certainly free to do so.
And yet you're prepared to spend hours arguing about it. I mean, whenever I think I have an idea for improving Daz Studio, I am happily willing to submit it to the dev team as a feature request, because ultimately it's an improvement I'd benefit from.
In any case, at this point, there is no point in me or anyone else discussing with this with you any further, because whether it's trolling (in which case, yes, clap clap, very good, you got us, now maybe the next thing you should try and get is get a life), smugness, laziness, or just simply no longer being confident enough in your argument as to present it, this statement on its own constitutes your refusal to meaningfully engage in the discussion.