You might look at the Seasectoid Creature, which is a little different from the sample image you posted, but could work. That's a standalone figure, though, rather than part of the Genesis family.

Gordig's suggestion of Cthonic Arkouda is good. You might also look at Geonosect or Fly Girl. Fly Girl is Genesis 2, so if you wanted a current-generation figure, you might have to transfer the morphs to a newer figure using something like Riversoft's Character Converter. (There are also manual processes for moving morphs from generation to generation, but Riversoft's scripts make the process easier and quicker).

The body shapes of the insectoids in your sample picture are a little like the Big Grey or Greylien characters. 

LunarTaleGames said:

Ok, but how am I distributing it? It is in the game as part of a mechanic.

If the original mesh and texture data (or any mesh or texture data derived from them) are in the game files, you are distributing the files as part of the package - even if it is not separately available (and believe me, with the ripping tools out there, a lot of game data *is* extractable).

Also again with this item why no licence offer if they mention it can be bridged to Unreal?

Because aside from the fact it technically *can* be bridged to Unreal, game creation is not the only thing game engines can be used for.

A lot of people prefer to create animations or movies in game engines, as it can be rendered back in real-time rather than taking minutes or hours to render each frame.

The Daz EULA makes no stipulation that the assets have to be rendered in Daz Studio, and someone could entirely reasonably transfer them to Unreal. (Indeed, back when I was using Source Filmmaker more often, I ported Daz assets over - for my own personal use, I add).

You could probably get reasonably close, at least on the body morph, with HFS Ultimate Shapes. You might also try dialing in a little bit of Chthonic Arkouda. 

Richard Haseltine said:

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.

Sure, on a technical level, they're different. But I was referring to my desired user experience.

 If I want to use, say, Zev0's aging morphs, I'd much rather prefer to just select it like I do any product and have them loaded onto the figure on demand.

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