I will confess my first thought was MSO Reese

But it's vanishingly unlikely a G8F character would be the promo character for a G9 set. So.. possibly V9 with an un-tanned freckled skin and make-up face.

Regards

Richard

Thank you both, I'll see what I can do.

@crosswind: I can use the value of a property on the figure to control the activation of a morph on shoes fitted to her?

About fixing Proportion Height, I'm nowhere near the level needed to create a proper bs to fix it on G9 directly: I'm already sweating bullets while trying to get clothes fitted correctly on various body shapes when the clothes are following a body shope very closely (less when they are more loose).

And I suppose at that point of the life of Genesis 9, it's unlikely to be fixed by Daz if I opened a ticket because it would likely mess with all the shoes already released with CBS for characters like Hanako who are using Proportion Height, especially considering that Victoria 9 does use it too (even if it's only at -4.5%) and she's likely one of the most popular figures for G9.

joanna said:

What I was pointing out is the three tiny black triangle shapes to the right (looking at the picture, to the left anatomically) of where her navel would be. If you're viewing it on a phone, it might not be visible, but on a PC monitor, they're quite clear and standing out, and they look like texture/lighting issue.

Sorry, I watched the picture on my computer but didn't open in a new window and I didn't see the triangles you were speaking about 

Looking at the shadows around Tiana's left breast, they are a bit blocky: maybe raising the SubD render level on the dress could make the triangle shadows a bit less sharp too? At least if the dress responds well to SubD (I don't have it). An example:

'Olympia 9 by night'

While they were walking back to their home after a nice dinner out, once they stepped on the bridge, Olympia thought absently that the buildings on the opposite riverbank would likely provide a nice bokeh.

And she was certain that tonight, as always, wherever they went, a camera went along.

She didn’t say anything but could hear the wheels spinning in the mind of her SO and after a minute or so, she heard, in a whisper, ‘The bokeh will be fabulous.’

‘Yep,’ she thought before saying innocently, ‘We do have some time, but don’t forget we hired a babysitter.’

That render was sitting on my computer for a couple of months but when I saw the recent Artissane set by fabiana, it felt like the missing piece, especially because it has bracelets.

One great thing about the various jewelry products she released is that pendants are easy to use with necklaces from other sets as long as they have a pendant connector. In this render, I simply removed the pendant I used, keeping the necklace already simulated around Olympia's neck, before loading the pendant and seeing it appear exactly where it should (note that Artissane doesn't have any necklace included but everything else is usuable without it).

I forget to mention it on the gallery, but I think I tried to add a bit of noise with Affinity. I'll have to check later because the effect is minor and I'll try to add the raw render later if I did shared the postworked version.

And while I was playing with the Artissane set, I found a couple of minor problems with the Genesis 8 version, so why not make a render with them, worn by a Genesis 8 character to see if there was another problem (I think the answer is no and the two problems is really minor), in this case, Clara 8.1. No story because I simply repurposed a scene I created to have a nice icon for a persona preset loading Clara 8.1 wearing the dress and the shoes shown on the render, which I suppose will be upgraded by a version with the scarf and the jewelry 

'Clara 8.1'

No postwork on this one.

Not counting the scarf which was offered on St Patrick day on Renderosity, only one product from a recent sale was used: https://www.daz3d.com/fk-artissane-jewelry-set

A couple of products I like a lot that I had for a longer time in my library: 

• The bridge is not very visible on Olympia's render, but still more than on my render with MSO Lacey and Victoria 8.1 last month: https://www.daz3d.com/fn-bridge
• The dress worn by Olympia is very nice. I didn't use the jacket so I have no opinion about that part of the outfit, but the dress worked nicely: https://www.daz3d.com/dforce-cb-kiki-clothing-set-for-genesis-9
• The Feisty feather bun hair is superb: https://www.daz3d.com/dforce-feisty-feather-bun-hair-for-genesis-9
• Everyone should have the Secret Garden Shaded Haven used on Clara 8.1 render, and while it's not new, I think the automatted iray converted worked nicely on this one. I thought about changing the floor textures, but it would likely require more work that I was willing to do to create a texture keeping the two tones used here.

Blando Calrissian said:

I already have a Jeep in my collection, but AcharyaPolina's AP Archaeologist 'Truck' is pretty neat, and a nice value at the moment. 

I hesitated to buy when it was released, but I decided against it because I already have enough cars in my library.

I does look good on your nice render though.

Lorraine said:

Study in Cream

It's a nice selections of white or white adjacent colours. Almost the opposite of my render with Clara 8.1, almost because I added a bit of colours with the scarf after trying to use a black and gray motif.

She looks a lot like Victoria 9 wearing her makeup:

https://www.daz3d.com/victoria-9-hd

https://www.daz3d.com/victoria-9-hd-makeup

Edit: the discussion's title could be more clear.

zacharymeyer64 said:

Damn thats crazy, you have this pack as well? Or is it a presistent problem known with it? I'd assume if it was presistent the author would have gotten a few tickets for a fix, reguardless when i get the time I will put in a ticket if not for a fix for myself then to at least let the author know its a problem that is occuring. I didn't even notice it at first as all my renders with the model had her farther back, or she had shoes on lol

When using it, my guess is that people are looking at the chest or navel of a character, not their feet, and I suppose when the PA and Daz QA tested it, they were also looking at these areas.

It's also not equally visible on all characters: after you shared the solution, I checked with a couple of characters (Victoria 9, Michael 9, Hanako 9 and Genesis 9 Base). On some of them, it's barely visible while it's the most visible on Victoria 9 among them.

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.

Most long hairs are for G8F, but they should work on G8M if you change the figure's scene ID.

These are varying levels of Legolas-ish:

Arwen Hair for Genesis 8 Females

Anita Hair for Genesis 8 Female(s)

dForce Rose De Mai Hair for Genesis 3 and 8 Females

Briggs Hair for Genesis 8 Male and Females

dForce Duchess Hair for Genesis 8 Female

Adeline Hair and Circlets for Genesis 8 Female(s)

Tasha Hair for Genesis 8 Female(s)

Nerea Hair for Genesis 8 Female(s)

dForce HS Helena Long Hair For Genesis 9

These are for G9, but you could just parent them to the figure's head:

dForce Joanie Hair for Genesis 9 (this one is most like Legolas', imo)

Soft Curls Ponytail for Genesis 9

This is the store link for all long hairs for any figure: https://www.daz3d.com/long

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.

DollyGirl said:

ItsAaron said:

DollyGirl said:

ItsAaron, here is the wiki page for Long Hair Evolution - Poser and Daz Studio Free Resources Wiki. The page has the current link.

Yeah I know, but  long hair evolution Universal and others require Long Hair Evolution for DAZ's Victoria V1-3 

However, it's not archived yet

By the way thanks for information 

Here is the web page for Long hair DownLoad  7th thumb nail down

Your link takes you to digitalbabes.jp on the wayback, problem is most of the zip files are missing from the .jp site, the links are there just not the files.

The digitalbabes2.com link I posted has most of the zip files

ItsAaron said:

DollyGirl said:

ItsAaron, here is the wiki page for Long Hair Evolution - Poser and Daz Studio Free Resources Wiki. The page has the current link.

Yeah I know, but  long hair evolution Universal and others require Long Hair Evolution for DAZ's Victoria V1-3 

However, it's not archived yet

By the way thanks for information 

Here is the web page for Long hair DownLoad  7th thumb nail down

kyoto kid said:

G8.1 uses a different UV map structure than G1 - G8 so you are pretty much limited to using 8.1 skins.

Except what you're saying here is wrong (emphasis mine): you can apply most Genesis 3 and Genesis 8 skins on Genesis 8.1 by default.

Only characters using a special UV maps like Genesis 3 Core Figures won't work without either remapping their textures to the default UV of their base figure or using a product providing their UV maps for Genesis 8, like this one or this one, but if you have them, you can apply a Core figure H.mats (let's say Victoria 7) on a Genesis 8.1 figure:

DollyGirl said:

ItsAaron, here is the wiki page for Long Hair Evolution - Poser and Daz Studio Free Resources Wiki. The page has the current link.

Yeah I know, but  long hair evolution Universal and others require Long Hair Evolution for DAZ's Victoria V1-3 

However, it's not archived yet

By the way thanks for information 

Thank you for the Kozaburo's hairs

Some Hairs (all back hair, Long Hair Evolution for DAZ's Victoria V1-3, and others) are not archived yet, We are hoping someone will be archived someday, for refit for newer Genesis 8 and Genesis 9

You create a figure from scratch, you get the basic morphs. You want to use a morph you purchased called "heads vol 2", you go to the library and "attach" the morphs within it to the figure. Now the figure is "base morphs" plus "heads vol 2" (and whatever else heads v2 loads). Later you save and reload this figure. When it reloads, it load "Heads vol 2" automatically because the scene/character file tells it to. 

 Which is, to an extent, what the ExP system used with Victoria/Michael 4 did - it added its own data files to /Runtime/Libraries/!DAZ/Figurename and in order to use them we had to run a script that added those files to the master list of files to load that the figure read in. People hated this, hence the Genesis system.

TheMysteryIsThePoint said:

A design that creates "very important practical reasons" why it must be inefficient is not a very good design. There is no degree of rationalization or explanation that is more important than the user experience, which is the reason  why the design exists in the first place. Knowing why it is inefficient is no consolation while I'm twiddling my thumbs while waiting for the scene to load; I'd vastly prefer to simply be ignorant and not know why it can load a scene so quickly rather than knowing all the exact design decisions, as you've carefully explained, that make it painfully slow.

Hating the experience of the current system doesn't mean that an alternative system's experience would be better. There are always trade-offs, as I noted in reference to ExP above, and Daz chose what they thought would be the lesser evil. It is possible that history has shown a different approach would have been a lesser evil, but it can't be assumed that that is the case. It is possible that DS 6 will try to adjust the system, but there will probably be downsides to that too.

Matt_Castle said:

TheMysteryIsThePoint said:

Why force the user to wait for dials that the user has expressed no interest in, instead of initializing them into some kind of inactive state and only loading them if/when they are actually used?

Because, for very important practical reasons, control links have to be able to be defined in either direction.

That is to say that if you have a Controller A, with child morphs B, C & D, then the code can be in A to say "when A is dialled in, dial in B, C & D". Or the code can be in each of B, C & D to say "Go and look at A. If it's dialled in, dial me in too, thanks". Or various combinations.

Being able to link in either direction is very important, both practically and legally.

Let's say someone creates some new expressions, but *also* wants to have correctives for those expressions to make them look their absolute best on Victoria 9. So, they need to link the correctives to Victoria 9's morph so those correctives only activate on her shape. But they cannot update Victoria 9's morph because a) if everyone who needed to link to Victoria 9's morph had to alter it, then only one person could ever link to it, b) it would stupidly bloat everything if you needed to send around updated morphs for everything you wanted to link to, and c) they do not have the copyright to alter and redistribute Victoria 9's morph. So the link to Victoria 9's morph needs to be saved in the expression corrective file, not Victoria 9's.

As such, an on-demand top-down indexing of the morph library of "only look in the files once you know you need them" is impossible, because a lot of morph links are defined bottom-up and thus you don't know for sure whether you do or don't need a file until you've looked in it.

Now, possibly there are better ways to handle this infrastructure. Maybe the links could exist as files themselves, and their file names are encoded such that DS can tell for sure "Hey, that link file has a name that matches this morph file's name, so I know that it tells me about a link I will need to use if I ever dial this morph in, but I don't need to look in it right now", but it would not be possible to migrate an existing figure base to a new system like that.

For now, Daz Studio is forced to work the way it does, opening and checking every morph file it can find in the library folders for that base figure to find all possible links before proceeding.

One way to handle that is each file has a header with all of the metadata about dependences. That can be read without having to process the entire file. The rest can be posponed untill the file is required or as a background task. Wating until a dial is used can trigger 50 or more dependences being loaded, which can cause the app to freeze while that's being processed.

That of course can be sped up if loading and decoding files was done in paralellel. For example, which file can be processed by a separate thread. The best way to do that depends on where the bottlenecks in the pipeline are. 

Tag:Fae3D#1

Pull : 

4038 Millennium Puppy,    

1794 The Alchemist Workshop Props - Cook Set       

2329  Edwardian Hair for Genesis 3 Female    

1859 Urban Battle Outfit Shirts for Genesis 8.1 Females

Unexpected Surprises

When Marcy and Zach had seen the abandoned dog wandering aimlessly around the park, it had seemed like a great idea to take her home.  She needed somewhere to live, and they had always wanted a dog, but didn’t want to deal with a rambunctious puppy.  So this calm, sweet adult dog was perfect!  However, it turned out that she had a little surprise for them.  Or actually, six little surprises!  Well, there went their peace and quiet…

Rendered in Daz Studio Iray.

Postwork in Pixelmator Pro.

No AI used.

Other Items Used:

Autumnal Outfit for Genesis 8 Females

Bounty Huntress Outfit for Genesis 8 Females

Zelara 8

Arch Details Vol 1

Hog and Barrel Pub Interior

Z Luxury Morphing Office Chair and Poses for Genesis 8 and 8.1

Treescapes Backdrops

Marius HD for Genesis 9

Bristol Ridge Outfit for Genesis 9

Federico Hair for Genesis 9

Easter Egg Hunt Poses for Genesis 9 Base

Texture Booster and Shader Converter

Margot for Victoria 8

Look At Me II Pose Control

Daz Dog 8

Beagle for Daz Dog 8

Iray Rain

SY Invisilights Iray

PS Bachelor Living

Mexican Girl Expressions for Genesis 8.1 Female and Rosa Maria 8.1

TheMysteryIsThePoint said:

Why force the user to wait for dials that the user has expressed no interest in, instead of initializing them into some kind of inactive state and only loading them if/when they are actually used?

Because, for very important practical reasons, control links have to be able to be defined in either direction.

That is to say that if you have a Controller A, with child morphs B, C & D, then the code can be in A to say "when A is dialled in, dial in B, C & D". Or the code can be in each of B, C & D to say "Go and look at A. If it's dialled in, dial me in too, thanks". Or various combinations.

Being able to link in either direction is very important, both practically and legally.

Let's say someone creates some new expressions, but *also* wants to have correctives for those expressions to make them look their absolute best on Victoria 9. So, they need to link the correctives to Victoria 9's morph so those correctives only activate on her shape. But they cannot update Victoria 9's morph because a) if everyone who needed to link to Victoria 9's morph had to alter it, then only one person could ever link to it, b) it would stupidly bloat everything if you needed to send around updated morphs for everything you wanted to link to, and c) they do not have the copyright to alter and redistribute Victoria 9's morph. So the link to Victoria 9's morph needs to be saved in the expression corrective file, not Victoria 9's.

As such, an on-demand top-down indexing of the morph library of "only look in the files once you know you need them" is impossible, because a lot of morph links are defined bottom-up and thus you don't know for sure whether you do or don't need a file until you've looked in it.

Now, possibly there are better ways to handle this infrastructure. Maybe the links could exist as files themselves, and their file names are encoded such that DS can tell for sure "Hey, that link file has a name that matches this morph file's name, so I know that it tells me about a link I will need to use if I ever dial this morph in, but I don't need to look in it right now", but it would not be possible to migrate an existing figure base to a new system like that.

For now, Daz Studio is forced to work the way it does, opening and checking every morph file it can find in the library folders for that base figure to find all possible links before proceeding.

Richard Haseltine said:

I'm still not sure what it is that is broken, which makes it hard to report. It isn't a Daz Deals feature?

They're talking about the "Product Add-Ons" at the bottom of the page, below "you may also be interested in..." Sigrid 9, for example, has them. Victoria 8 does not.

MelanieL said:

paulawp (marahzen) said:

Togire said:

Elor said:

mding said:

In case this hasn't been reported yet: Several core figures lost their "Product Add-ons" sections: 

Victoria 4.2 Base, Michael 4 Base, Stephanie 4 Elite Base, Aiko 4 Base, Hiro 4 Base

Genesis: Michael 5, Victoria 5, 

Genesis 2: Victoria 6, Michael 6, Josie 6, Stephanie 6, Gianni 6, Mei Lin 6, Aiko 6, Lilith 6

Genesis 3: Michael 7, Aiko 7, Victoria 7

Genesis 8: Here I only checked and found: Victoria 8, Michael 8, didn't look any further.

Could that be please reported, please,  as I find these sections are very helpful?

Daz Dog 8 also lost the product add-ons section:

https://www.daz3d.com/daz-dog-8

If it's mainly for figures with a lot of add-ons, maybe it's a performance saving change? But I hope they'll revert back to the previous situation or offer a way to browse add-on for a figure.

Actually, they also suppressed the add-on section of Genesis 9 Starter Essentials, but this is a *very very very good* thing.

Making any G9 figure/outfit an addon of Genesis 9 Starter Essentials was extremely stupid. First, loading the G9 starter essential page with its addon section composed of 20k+ elements was (how can I say) ... an interesting experience... If you have tried recently, you know what I mean. But, this is now fixed

But, if any G9 item is already an addon, it completely breaks the search of real dependencies. For instance, with "daz deals" you can find in a big list of assets which ones are addons of items that you already own.  Very useful, indeed. But if all G9 items are already addons of G9 essentials, this is a useless information that masks real addon dependencies as all G9 assets will appear in the list. And this problem is not fixed...

This prompted me to look and confirm that this feature is also lost for Daz Horse 2 and 3, the original Ultrascenery, and likely many other comparable products. That, IMHO, is a bad thing that needs to be fixed. I own pretty much all of the add-ons for items like these, but when I was building my Daz collection, I made a lot of use of picking up add-ons when on sale. As a newbie, I wouldn't even have known about all the cool add-ons that were available for some things without this feature.  

Oh I really hope this is some kind of temporary glitch or a reversible mistake. I've used the feature several times to pick up extras for a base figure like the horse or the dog.

Please Daz change your mind!  

I'm still not sure what it is that is broken, which makes it hard to report. It isn't a Daz Deals feature?