margrave said:

IceCrMn said:

How about just loading the sliders with labels for the morphs/expressions/whatever, etc,etc and skip the formulas and whatnot.
Load basic character and/or character preset.
Add a load button to each slider. User wants to load an expression, then user clicks the "load" button to activate that slider and pop up a notice if it needs others activated an offers to add them to the "load it" list.
Basically load/unload them on demand, just in a more user friendly way than asking during character load time to decide from 1000's of options what to choose up front(depending how many morph, expression, etc,etc are installed).
Would something like this work?

Discobob & Zev0 already figured it out with "Fit Control":

1. Select a figure.
2. Click "Load morphs".
3. Fiddle with them.
4. Click "Remove All Morphs but Selected".

We don't need ten million sliders cluttering up the property pane, especially when they're not labelled with the product name. Just load them on a product-by-product basis, please.

Not at all the same. Load Morphs applies the morphs to the base figure, which projects them into the fitted item; remove then removes the unwanted moprhs from the fitted item. Load heer is not the same as loading the morphs into the base figure.

onix said:

thenoobducky said:I wouldn't bet on it. What is fundamentally slow is 1. load json data, 2. create erc formulas. Neither are really related to qt4 and both are not trivial to make it multithreaded. Loading formulas are required for a lot of expressions and poses to work correctly.

Loading data is petty trivial to multithread because nothing prevents processing multiple files in parallel.

and is probably not worth doing as it's not the reading that is slow

Loading formulas can be omitted entirely if that property is not in use.

No it can't, a formula is stored with one of the two morphs so you can't assume that every link is referenced in the file for the morph that is being set and simply load it when it goes non-zero and trace through the links from that. And yes, it does need to have the ability to store the ERC with either controlled morph or controller since the two may be by different people so it isn't possible to have a creator of a downstream morph (say) update the upstream morph's data.

to speed things up even more UI could be made responsive before every morph is loaded and loading could just continue later gradually updating the scene into the final version.

Which would have the potential to haev the user make changes for which the ramifications were not yet established, which would add another round of processing before the load was complete, which would slow tings down further.

In fact, Daz already has that functionality because it can add extra morphs later so there is nothing that would prevent more loading processes to be put into the background.

Yes, fresh links can be established as needed - but any saving on loading would then add more overhead on future operations (see above) so hardly the royal road to improved performance overall.

But there is a strange general Daz policy to lock up UI in all situations when this is even entirely unnecessary. like during the rendering of D-force simulation it would be totally ok to continue working on the scene while other things are happening in the background.

So what, the dForce simulation runs in the background while the user carries on posing so that the completed dForce simulation is for the wrong pose/animation? Or would the UI be only partially frozen, that sounds like a good way to frustrate and confuse users (and a good way to lay booby-traps for conflicting data,especially considering third-party plug-ins).

It appears that you do not fully understand what DS is doing, and this is leading you up the garden path.

IceCrMn said:

How about just loading the sliders with labels for the morphs/expressions/whatever, etc,etc and skip the formulas and whatnot.
Load basic character and/or character preset.
Add a load button to each slider. User wants to load an expression, then user clicks the "load" button to activate that slider and pop up a notice if it needs others activated an offers to add them to the "load it" list.
Basically load/unload them on demand, just in a more user friendly way than asking during character load time to decide from 1000's of options what to choose up front(depending how many morph, expression, etc,etc are installed).
Would something like this work?

Discobob & Zev0 already figured it out with "Fit Control":

1. Select a figure.
2. Click "Load morphs".
3. Fiddle with them.
4. Click "Remove All Morphs but Selected".

We don't need ten million sliders cluttering up the property pane, especially when they're not labelled with the product name. Just load them on a product-by-product basis, please.

How about just loading the sliders with labels for the morphs/expressions/whatever, etc,etc and skip the formulas and whatnot.
Load basic character and/or character preset.
Add a load button to each slider. User wants to load an expression, then user clicks the "load" button to activate that slider and pop up a notice if it needs others activated an offers to add them to the "load it" list.
Basically load/unload them on demand, just in a more user friendly way than asking during character load time to decide from 1000's of options what to choose up front(depending how many morph, expression, etc,etc are installed).
Would something like this work?

margrave said:

PerttiA said:

They do have the Cache file that is supposed to speed up the process as the individual morph files don't need to be found and read separately, but the information inside the Cache file is still the same as what can be found inside the morphfiles, except for the morph delta's.

The explanation has been that when the morph data has been read, the dials are created along with any and all dependencies to other morph dials, and this is THE process that takes time.
To me, the obvious solution would be that the Cache file would contain the ready processed information, so it wouldn't need processing every single time you load a figure.

While that sounds like it should be correct, when I consolidated my content directory onto my new external hard drive, I found the loading time for G8 went down. So I'm not convinced the cache file works that way. Or, at least, I'm not convinced it works well.

Judging by the countless posts and discussions on the issue, it doesn't seem to help the process at all, which is logical as the only thing it is supposed to bypass is the reading of individual files in different folders, which is not that much of an issue with modern SSD's - It does nothing to what is said to take the most time in loading a figure.

PerttiA said:

They do have the Cache file that is supposed to speed up the process as the individual morph files don't need to be found and read separately, but the information inside the Cache file is still the same as what can be found inside the morphfiles, except for the morph delta's.

The explanation has been that when the morph data has been read, the dials are created along with any and all dependencies to other morph dials, and this is THE process that takes time.
To me, the obvious solution would be that the Cache file would contain the ready processed information, so it wouldn't need processing every single time you load a figure.

While that sounds like it should be correct, when I consolidated my content directory onto my new external hard drive, I found the loading time for G8 went down. So I'm not convinced the cache file works that way. Or, at least, I'm not convinced it works well.

margrave said:

thenoobducky said:

LenioTG said:

margrave said:

I think (hope?) these problems are caused by the massively outdated framework they're using. Qt4 is over fifteen years old by now, and it reached its end-of-life in 2015. I don't think a File I/O system developed for Windows XP can cope with the strain.

But the release notes say they're moving to a newer Qt version soon, so hopefully we'll see some performance gains.

I definitely think Daz should prioritize this over certain other ventures, mentioned elsewhere.

That's good news, I hope that'll fix the problem and come soon!

I wouldn't bet on it. What is fundamentally slow is 1. load json data, 2. create erc formulas. Neither are really related to qt4 and both are not trivial to make it multithreaded. Loading formulas are required for a lot of expressions and poses to work correctly.

I think it is related. Cross-platform frameworks typically handle file I/O, so app developers don't have to deal with the operating system directly. And a lot of the loading time seems to come from searching through different directories for files. If you split your morphs up between different drives, loading takes much longer. So it is heavily dependent on Daz interfacing with the OS and loading files (presumably) through Qt.

They do have the Cache file that is supposed to speed up the process as the individual morph files don't need to be found and read separately, but the information inside the Cache file is still the same as what can be found inside the morphfiles, except for the morph delta's.

The explanation has been that when the morph data has been read, the dials are created along with any and all dependencies to other morph dials, and this is THE process that takes time.
To me, the obvious solution would be that the Cache file would contain the ready processed information, so it wouldn't need processing every single time you load a figure.

thenoobducky said:I wouldn't bet on it. What is fundamentally slow is 1. load json data, 2. create erc formulas. Neither are really related to qt4 and both are not trivial to make it multithreaded. Loading formulas are required for a lot of expressions and poses to work correctly.

Loading data is petty trivial to multithread because nothing prevents processing multiple files in parallel.

Loading formulas can be omitted entirely if that property is not in use.

to speed things up even more UI could be made responsive before every morph is loaded and loading could just continue later gradually updating the scene into the final version.

In fact, Daz already has that functionality because it can add extra morphs later so there is nothing that would prevent more loading processes to be put into the background.

But there is a strange general Daz policy to lock up UI in all situations when this is even entirely unnecessary. like during the rendering of D-force simulation it would be totally ok to continue working on the scene while other things are happening in the background.

You need the Victoria 4 morph for Genesis not the actual Victoria 4.

Well, ytou can see which are different if you select both and scroll through the morph list - any that have different values between the two will show <?> as their value. Proeprties thata re on both figues will have (2) after their label, so if there isn't a (2) it's a proeprty that is one only one of them

Daventaki said:

So after saving the morph in MG then saving the morph asset with the same name, I load a new scene with G8F and the morph is available.

oh good-o, thanks for doing that. i did do that too but i didn't use exactly the same name (my saved asset had a MG_ prefix that the morphs did not)

i will try again. either way, it sounds like it *will* do what i want after all. that's good news to me. thanks again!

ProPose said:

Can't seen to get Lyra Hair to work in Carrara.  I converted the Hair figure to blended and saved as a subset.  It loads in carrara just fine, except the shaping dials don't work, and it loads in the zero shape.  What other options do I have to get the hair function like in Studio?

I'm afraid you can't use pose controls for this item in Carrara. You can only pose it manually. Or you can export the hair with Knot slider turned on in base resolution as obj, then import your obj in Daz Studio, fit it to figure using transfer utility, convert it to blended weights and then save it as prop/figure somewhere on your computer. Then you will have it looking as a hair knot/bun in Carrara.

Hello everyone.

I don't know if I'm posting this in the right place.
I need your help. Indeed, I will need an insectoid character.
Can you tell me where I can find this kind of insectoid / mantis like in this picture?
Can I do this myself with a specific morph?

Thanks in advance to all.
Have a great day.

I have been working on a character and over several versions I have adjusted a lot of morphs ( some bought, some I made myself ). It would be useful to compare the morphs used and their settings between particular versions, so what I need to do is list only the differences, and ignore the settings that are the same in each. Does anyone know of a way to do this?

It's fine, it was a little personal haha but we can move on :)

I definitely do want to do figures, it's really something I've been saying I'll do for ages.

what I'm working on right now is some more fashions that utilise the strand based hair system to look really cool, but that might not be for everyone.

 In the future I really want to create some figures where the bodies are certain real word sizes, in England we would say a size 8 or size 12. As a few of you know I work mostly in fashion these would be aimed at designers, who want very specific measurements from their avatars.

Of course these figures would come with a great face and skin :) however, everything I've created is all from Daz assets readily available on the store. Obviously I can't say exactly what as I want to keep some of my characters to myself, but I will say some of the Daz original characters skins/base mesh are amazing! And I love BlueJuante skins ;) plus some of zev0 morph packs. 
 

Hopefully I can push out some things that this community really do enjoy!

Faeryl Womyn said:

One of these days I'm going to end up on a black list...didn't spend enough time editing before hitting the post button this time...my bad.

Cameron I appoligize for what I said about you. I never should have said something so personal, especially when neither of us knows the other. And you're right, all I know about you is from a couple of youtube video's.

In keeping with this particular thread...some of you think 3D modelling might be just a flash in the pan. Don't count on that. I have been talking with someone about using Daz models in Unreal to be presented to companies who have online shops, since so many are now buying online thanks to the pandemic. If this flies like they think it will, Cameron's concept is actually on par with how things are progressing in 3D. Consider how many people spend time on their phones, tablets and computers. We are constantly being told the world is changing and things will most likely not go back to the normal we once knew thanks to the pandemic. Realistically, you are all discussing the beginnings of what might be our new future.

I wouldn't mind these models as characters to buy here at Daz, though I don't restrict myself to just G8 or it's newest counter part, I also use G3 and G2 quite regularly.

Ruris said:

I got it. I rerun the test with a combined mesh.

The morph pro dont concern with the vert , only polygon count i believe. 

Only the vert count matters has verts are the ones which dictate polygons. You can't have a polygon with no verts. Triangulating a mesh will cause the polygon count to double but the vertex count will remain the same. Triangulating a mesh won't prohibit you to import it as a morph.

When importing a morph the vertex count needs to be the same and the vertex order also needs to be the same. In a modelling program each time you modify the geometry like delete, copy, etc the vertex count will get automatically recalculated which will ruin your morph. For the vertex order to remain the same you should only just move polygons and vertices around, never add or subtract anything.

I'm not familiar with 3dsmax but I know some programs have a tough time importing obj's because the developers thought it wise to add a bunch of unwanted features that literally nobody uses.

Here's how you can troubleshoot the situation:

- add Genesis figure to the scene -> Parameters tab -> General -> switch to Base resolution -> export obj

- you'll get a bunch of options which might be relevant to what it is you're trying to do. To just export the geometry as is, use the options in image attached. Note: the scale in exporting and importing have to be consistent.

- test out the exported obj by importing it back as a morph using Morph Loader Pro. Don't modify any of the options, just load the obj and hit Accept. You should get an error saying something like "No deltas found, skipping morph". This is fine, it means the morph is identical to base figure which means it won't do anything which is why Daz Studio skips it.

- import the obj in your 3dsmax -> export the obj -> load the obj back into Daz as a morph to see if importing and exporting it from 3dsmax did some unwanted changes -> throught trial and error figure out what import/export functions you need to set in 3dsmax so it doesn't modify the obj at all

Ok, got it working, thank you everyone!  What did the trick was uninstalling and then reinstalling the Genesis 8 Male Starter Essentials.

I must say, he doesn't look to me quite like he does in the promos, but he has an interesting head morph, so I'll hang on to him for mixing.

Thank you all for your help!

I just installed him through DIM and it broke my smart content as well. But reinstalling G8M starter essentials fixed that. 

Also, if you're thinking of buying it, I want to point out that his face is significantly lighter than his body. Just noticed that now in the viewport. It's a shame because I really like the details of the skin otherwise. Oh well. I guess I will keep him for the morph. His face is pretty unique. 

Does  this product also detect custom ZBrush morphs and combines them into one full character morph?

Karuki said:

Aside from straight up telling them 'No! Don't do it!', do you think there are anyways of doing this responsible right now? Is this a straight up case of everyone should be actively avoiding this?

My advice to any companies that are going to do it is "wait".

Ethereum will be moving over to proof-of-stake in a few months, which will massively reduce the power consumption requirements (the claimed figure is a 99.98% reduction in power consumption) and will mean the network no longer relies on massive amounts of computing hardware, which addresses three of the issues I mentioned.

Waiting until that point also gives more time to assess whether the market is going to be ethical and stable.

In the first point, if NFTs build up a bad reputation for being used as scams or money laundering, it could be a very bad thing to have been associated with the concept. In the second respect, NFTs only really took off recently, and cryptocurrency markets crash pretty hard every now and again. Broader take up of the NFT idea is pretty new, and we don't yet know whether it has long-term stability. It could be the case that in three months we're looking back at NFTs as a "remember those? I pity all those people who bought those and suddenly had them all turn out worthless" - which might be good from a financial point of view for the sellers, but could result in stoking a lot of resentment in some of your most enthusiastic customers. And if I've learned something over the years, if you tick off a dedicated customer, jeebus can they be vindictive.

I know there's the drive to be in right at the start for the biggest returns, but if it's only going to have short term viability, you don't really want to have bought into it, and if it has long-term viability, you'll still make profits in the long run.

I imagine the "gas" for NFTs may also get cheaper after the transfer to proof-of-stake, so less capital will be put on the line and it'll be less of a risk to get involved with.