There's a lot in such an image to work on.

DAZ Solutions and limitations :

- Find clothes that are already dForce compatible. Or, if the wireframe is properly welded and not messy, add dForce Dynamic Surface to any cloth. Problem : for dForce to compute properly, colthes are usually optimized (wireframe not too dense). So you'll eventually get wrinkles but never as many as in your screenshot. Converting the cloth to SubD won't help as dForce computes the cloth at Base resolution. Subdivision is only visible post soft-body computation.

- You want a hand or any hard object to deform another. For that you can add a Smoothing Modifier to cloth AND to the genesis. And for both, define as collision item the hard object. The more your approach the hard object from your clothed Genesis, the more wireframe will be pushed in. Limitation : push modifier, like most things in DAZ, acts only on the Base resolution.

Blender, 3DS Max, Maya, etc.  solution : you could do that in Blender, subdivide the cloth as much and simulate with the Cloth Modifier to get proper wrinkles. Your Genesis being subdivided, you'll be also able to deform the skin with more accuracy. You can then import back in DAZ the cloth and the Genesis. Copy paste textures from the original versions (as Material IDs will be the same). And render with Iray. Keep in mind that those two imported objects aren't the Genesis anymore (except of course if you decide to export it without subdivision to make a morph of the stomach) and it's not the original cloth anymore. Just 2 imported meshes without bones. But once Surfaces are copy pasted onto them, they'll look identical to the originals, with the extra wrinkles and little details you can add in another 3D app such as Blender.

Marvelous Designer : (The way I'd do it as I work this way for all my scenes with any kind of soft body deformations, pillows, skin, clothes, etc.)

- Make a custom morph for the stomach deformation.

- Export Genesis without SubD in final position + hard object a bit away from the body as obj.

- Then export Genesis with stomach deformed + hard object this time a bit inside the body : as mdd.  Mdd format is a point cloud that'll enable you to play the animation (without bones) in Marvelous.

- Finally export your cloth as obj with SubD.

- Once in marvelous, import Genesis+hard object obj as Avatar. Import mdd of Genesis with stomach deformtion+hard object inside the body. Import the cloth as garment (it's subdivided and Marvelous triangulates anyway, so it won't be used as a morph anymore).

Now thanks to the .mdd you have an animation from final Pose to final Pose + stomach deformation of the Genesis and the movement of the hard object. You can now simulate the animation in Marvelous Designer and precisely shape the cloth as you want, push and pull it in real time to create those nice wrinkles. Once cloth garment looks good : export it as obj. Import that cloth back into DAZ. As it still have the Material ID information (UVs and surface) from the original, simply copy paste surfaces from original to imported cloth.

You now have in DAZ : the Genesis with your stomach deformation moprh. And a mesh simulated in marvelous Designer for the cloth.

In other words you can't really achieve a detailed image like this without knowing a bit more than the basics of DAZ. Like how to make your own custom morphs at least.The use of a third party app such as Blender, or in this case Marvelous Designer, would certainly raise the quality of the final effect.

@Limun and @sueya

Sueya used 3delight, so what is needed first for Sueya to do is looking if the shadows are activated and check if the girls are connecting with the floor level. I can see shadows on the buildings and light in the face of the right girl so you might need to bring the characters down (and the camera with them)

If you wand to try working with dforce you can safe the clothed charaters do different subscenes, let the dforce to it's magic there and safe again, then import the subscenes into your main scene again. I always do this when I'm expecting troubel with dforce or have a scnee which is already challenging for my computer.

Limun thanks for adding those explanations, that's a good step by step procedure

So, I saved material presets for each of the cigarette packages, and yes, they do work on all of the cigarette package props. Daz set up the metadata so that each of the cigarette package props has a different base compatibility in the database, so I had to set each material preset compatible with all of the individual props.

Rezca said:

Charlie Judge said:

Complaint: After over a week I still have not gotten the 15% discount tor spending over $50 on 31 July and there has been no response to my ticket that I filed on 3 August. I guess I may soon be leaving DAZ as I do not wish to deal with a company with business practices like that. Oh well, think of all the money I will save.

Wait, There are other companies like Rendo and CGTrader; so maybe my money will go there instead and I won't be saving afterall.

I feel that way with the Bridges  xD

Last time I asked support about them I did get a ticket back but it was to tell me they aren't actually supported by DAZ so no support will be given (Then, why advertise them on your site?)  and it feels like the few times a team comes along to work on them they vanish not long later.  Or at least with the C4D Bridge.  I don't recall Morph Export ever really working.  The last team to come in updated it and it became a 30/70 sort of deal where sometimes they'd export *to an extent*  but most of the time they didn't.  It's back to about 10/90 now  - I've exported dozens of figures and exactly two exported with morphs, the rest throw an IMPORT FAILED at me instead. 

Sometimes joints are oriented properly, most of the time they're not. Weighting issues exist in every figure that certainly aren't present in D|S or Poser,  etc.  Now a new problem has been introduced where the models import with the joints in one pose but the mesh zaps into a default pose that's different and the joints don't follow,  resulting in a lot of fussing around to fix it (Or just using a Collada export...)

Regardless,  I hope the current team can make some progress - even if it has been a while since their last message :<

...at lleast they don't cost anything.  Would be a real pain if they did.

Richard Haseltine said:

You could use the Geometry Editor to select all of the mesh save one hand (use the + buttons in the Tool Settings pane), right-click>Geometry Visibility>Hide Selection, right-click>Geometry Editing>Delete Hidden, export as OB, Import (using the same preset) and use the transfer utility to rig - butt hat would be hollow, if you want to cap the wrist you'd need to take the exported OBJ into some kind of modeller.

I'm thinking this may no longer apply in 2022 since what you described isn't available.

I was hoping to take advantage of importing a body part into Procreate (definitely won't open a full G8 obj ; 2019 32gb non pro version). Procreate can now import 3d models. Then I can manipulate the model with one hand and paint on a layer using the apple pencil and then export.

a. With the Geometry Editor pane open then looking at Face Groups

b. Use the Add + to add Abdomen, Chest, Head, etc to make body part selections.

c. Then right click the only options are Assign Selected Face to Group and Remove Selected Group(s)

I must be missing something that isn't readily made visible or somethign drastically changed.

Would it be possible for you to refresh the current steps if you wouldn't mind please?

Charlie Judge said:

Complaint: After over a week I still have not gotten the 15% discount tor spending over $50 on 31 July and there has been no response to my ticket that I filed on 3 August. I guess I may soon be leaving DAZ as I do not wish to deal with a company with business practices like that. Oh well, think of all the money I will save.

Wait, There are other companies like Rendo and CGTrader; so maybe my money will go there instead and I won't be saving afterall.

I feel that way with the Bridges  xD

Last time I asked support about them I did get a ticket back but it was to tell me they aren't actually supported by DAZ so no support will be given (Then, why advertise them on your site?)  and it feels like the few times a team comes along to work on them they vanish not long later.  Or at least with the C4D Bridge.  I don't recall Morph Export ever really working.  The last team to come in updated it and it became a 30/70 sort of deal where sometimes they'd export *to an extent*  but most of the time they didn't.  It's back to about 10/90 now  - I've exported dozens of figures and exactly two exported with morphs, the rest throw an IMPORT FAILED at me instead. 

Sometimes joints are oriented properly, most of the time they're not. Weighting issues exist in every figure that certainly aren't present in D|S or Poser,  etc.  Now a new problem has been introduced where the models import with the joints in one pose but the mesh zaps into a default pose that's different and the joints don't follow,  resulting in a lot of fussing around to fix it (Or just using a Collada export...)

Regardless,  I hope the current team can make some progress - even if it has been a while since their last message :<

After some dialogue based on the ticket, I got a solution.

Uninstall with DIM, close DIM, reinstall with DIM, reimport Metadata.

Apparently the extra step with closing DIM did a difference.

Case closed.

Richard Haseltine said:

By links I meant things like the link between a full body shape adn the ehad and body shapes, or between those and corrective morphs for bends and other morphs.CG

Ah.  Got it.  Connections between bones in a wall that has an attached door, for a non-figure example.  Presumably each one is a separate object that has to be constructed, with a parent-child relationship to the owning object.  But with only 887 total nodes, that's not a lot of work, I wouldn't think.  Same with the morphs.  If they take a fraction of a second to construct from an obj file source, I'd expect them to take a fraction of a second to parse out of the .duf file, too.

And there are only 887 nodes in this project, each of which presumably is backed by a single object in memory, give or take, plus whatever data structures are used for keeping vertices and edges between vertices and polygons in memory.  Daz is using 9.958 gigabytes of RAM after loading the 28-megabyte model.  But of course, there are 719 external model file fragments referenced by this project, with a lot of duplication (multiple parts of the same model).  There are 362 actual files totaling 162,280,256 bytes if you ignore the auto_adapted morphs that don't seem to actually exist as files on disk and one tiny little model that for some reason I can't actually find.  :-/  So in total, it probably pulls in on the order of 190 megabytes of compressed JSON data.

So that gives some idea of how much expansion is involved in model loading.  Subtracting the 360 megabytes that Daz uses without a file open, that means that the in-memory representation is around 50x the on-disk size.  That's some serious memory use.  But it's not the memory use that's a concern.  I mean, I have 64 GB of RAM, so 10 GB... I've forgotten how to count that low.  :-D  The concern is that it must be creating a crazy number of relatively large objects in memory to use that much space, and it is redoing all of that work every time it loads the process.

To be fair, the JSON is compressed, and uncompressed, it balloons by 15x or so, but the 28 megabyte file that balloons to 383,498,244 bytes really contains only 236,003,387 bytes of content and 147,494,857 of strippable whitespace (based on minifying it), so really more like 10x.  But given that the bulk of the data in the JSON file is structure, rather than data, that's misleading, because after all, most of that structure takes up zero space when you load data (unless the in-memory representation is something absurd, like storing the JSON keys in a hash table), because it gets computed in the form of offsets into a struct.  Though to be fair, there's no way to know how many unused properties get skipped during serialization, which can bloat data structures in memory.  Anyway, as a ballpark estimate, stripping the keys brings it to under 100 megabytes of data.  So basically, the compression is really only shrinking the data to maybe a third the size of the actual values, which probably puts the compressed binary right in line with what an in-memory binary representation of most of those values would look like size-wise (with floats instead of ASCII strings, etc.).  So yeah, that's probably a real 50x bloat, give or take.

Anyway, I'm thinking that the performance hit has to have something to do with converting the vertexes or faces into object form to reach the orders of magnitude of effort required to take a minute to read the file.  Here are the stats on the project:

That comes out to 21.5 microseconds per vertex of computation, or almost 67,000 clock cycles per vertex.  That's a *lot* of cycles.

If you figure finding the final position of a vertex is a single fused-multiply-add (is it?), then that's on the order of 9 million operations, at 4 operations per cycle, with 4-cycle latency.  So if you could actually keep the pipeline full, an M1 Max core would crunch through that in about 0.7 milliseconds.

And parsing 9 million floating-point values from a text file... takes four tenths of a second (I timed it), which is also not enough time to matter.  Even if I malloc storage for each value individually ahead of time, it barely crosses the half-second mark.

So where do all those cycles go?  I have no idea.  My guess is that it comes from actually converting meshes to their in-memory representation.  Each vertex is probably an object, which they presumably have to store in a temporary array, and each polygon is probably an object that presumably contains an array of pointers to vertex objects, which they then have to look up in that temporary array while constructing the pointer array.

But even still, everything I just described should be O(n) operations unless they're using something bloated and slow like STL vectors (or worse, some abstraction layer on top of that) for the array construction, adding them one at a time or something.  I mean, based on a quick run in Instruments, the fact that it spends almost 3 seconds of time freeing QString objects (mostly in calls from findClothNodeDataItem) tells me that this is not as unlikely as I'd like to believe, but....

It also spends almost seven seconds doing JPEG decoding for textures that aren't even visible onscreen and could be lazily loaded when it starts to become plausible that they need to be rendered (and which could very easily be done in parallel, too).  And it spends another second or so doing PNG decoding.

And DzFacetVertexSubPath::remapPath is a crazy hot path.  35.86 wallclock seconds were spent in that function, with more than half of that time spent ten or more levels of recursion deep.  DzScopeResolver::initIdentifierReplacement seems to be a good chunk of this, at 5.26 seconds, in part because it is doing additional remapPath calls, and those, in turn, are calling QImage::save.  The total time in those save calls is almost five seconds.  What the heck is Daz doing writing out images while loading a file?  Is this part of some sort of image conversion?  If so, why not cache the resulting representation and not spend those five seconds next time?  If not, what's going on?  Please tell me it isn't updating product thumbnails....  :-D

Here's a fun one.  It spends 4.2 seconds in QApplication::topLevelAt.  I think this is probably an artifact caused by the time while the menu item was stuck down, because they didn't properly defer the start of the loading process until the next run loop cycle.  At least I hope that's the case.  Otherwise, I have no idea what's going on.  :-D

It spends about 2.26 seconds doing QString conversions, and another third of a second converting QString objects to lowercase.  It spends a third of a second doing string equality comparisons.  I'm guessing those three or four seconds represent parser overhead, and there's probably more where that came from.

Anyway, I guess the real point of all of this is that there's a crazy amount of work happening while loading these files, resulting in multiple orders of magnitude penalty compared with the amount of time it takes to just read the data from disk, and if that work could somehow be preserved and reused, it would be a huge win.  And there's a lot of stuff happening, like JPEG and PNG parsing, image conversion (I guess), etc. that could trivially be done on any thread, but isn't.  And all of that adds up to a rather large performance bottleneck once your projects start to get large.

On the subject of serialization, one particularly cool (but terrifying) strategy I saw once involved a piece of audio software in the 90s and early 2000s called BIAS Deck.  They had a bunch of ostensibly C (but actually probably Pascal!) data structures, and they serialized them out to disk by literally writing them byte-for-byte, pointers and all.  Each of the original structs started with a four-byte character code to identify the type of structure, and also contained its own address at a known offset as an identifier.  So they would read the four bytes, figure out what type of structure to allocate, and copy the data into the newly allocated chunk of memory, then add it to a mapping table that mapped the old address (in the file) to the new address (allocated with malloc or whatever).  Then, after they loaded the data, they iterated through the objects and updated all of the pointers.  Note that I'm not recommending this strategy.  :-D

I realize C++ objects make serialization harder, but the boost API has serialization code that I've read is pretty decent.  That plus a little bit of versioning metadata would probably be adequate.  For every Daz model loaded from the library, the first time you load it in a given Daz Studio version, write the data back out to disk with boost serialization so that the final resulting pile of classes and data structures can be quickly reloaded.  And of course do timestamp comparisons to ensure that the model hasn't changed.  Judging by what I'm seeing, I would expect at least an order of magnitude improvement in performance with that strategy, even if they do nothing else, and possibly two.

sunnyjei said:

Fae3D said:

sunnyjei said:

 

Aha!  It was https://www.daz3d.com/mrl-dforce-fantasy-hair-pack!  That was the one I was thinking of.  Now I just need it to go on sale. 

Thank you very much, everyone, several of those mentioned might work as well, I'll have a look at all of them.  I really appreciate it!

Glad we were able to help you :) If you aren't 100% set on just that one or gen 8/8.1 there are some really pretty headdresses over at Renderosity too that could be converted to pearl or have pearls already.

Thank you again!  Do you happen to know the names of any of them on Renderosity?  I searched there, too, also with very little luck.

I don't have the best of luck with searches there either so just here are some I've wishlisted but there are probably more :)

A dangling one from head and other parts: https://www.renderosity.com/rr/mod/bcs/dangling-d-force-accessories-for-g3-g8-daz-studio/135244/

**One you would have to import as obj but so pretty: https://www.renderosity.com/rr/mod/bcs/crystals-and-pearls-1/153266/

Kinda flapper style and for older gen: https://www.renderosity.com/rr/mod/bcs/gcd-jewelry---daisy-collection-for-v4/102417/

Prev gen diamonds that could be changed to pearls via shaders I think: https://www.renderosity.com/rr/mod/bcs/gcd-jewelry---ophelia-collection-for-v4/106230/

Pearls with jewels like a floral crown: https://www.renderosity.com/rr/mod/bcs/gcd-bohemia-for-g8f/128512/

Pearls like a head necklace for gen 3 but I've gotten this one to work for gen 8 : https://www.renderosity.com/rr/mod/bcs/svs-adorned-in-pearls-genesis-3-female/122114/

Pearls in the hair -comb like : https://www.renderosity.com/rr/mod/bcs/prae-pearl-hair-g3-g8-daz/125538/

Pearls on a headdress that looks like Malicifient's (sp?) https://www.renderosity.com/rr/mod/bcs/gcd-noire-for-g8f/128729/

Pearls mixed in with small flowers like a floral crown: https://www.renderosity.com/rr/mod/bcs/magie-florale-2-for-g8-and-g8-1-females/155750/

Ornate feathers and pearls by The Row House: https://www.renderosity.com/rr/mod/bcs/minnie-1920s-dancer-headdress-g8/135549/

 

Hope these help!

Thank you very much!  I added several of these to my wishlist, I had never seen them.  I really appreciate the help!

So I have previously downloaded & installed my entire ridiculously-large library via DIM.  Everything is where installed as 'intended' which is to say it's an enormous mess with files that are not remotely where you'd think they belong, but more to the point, I haven't broken any installed files.  I even do all my own work in a separate content library.  (IE, I install to "My Library" and then there's a folder at the same level called "My Work" and anything I create goes in there, which is a separate content library in Daz.  That's primarily so I can backup my work without backing up all the terabytes of stuff I can theoretically download again, but it also means that my library is *exactly* as Daz intended, or at least as the PAs did.

I even put freebies and content obtained from other sites than Daz in a third library called, helpfully "Other Sites".  That's largely so I can be more sure that things that might not have the same license terms are clear.

Never (previously) logged in to Studio because I hated the mess it makes of the library.

Purchased Turbo Loader, and thus logged into Daz so it could theoretically update metadata and grab the product names in a manner that Turbo Loader can find them.

Now I'm seeing random uninstalled products.  Huh, I say, are those connect only products?  I didn't think those were connect only products.

So I investigate a couple.  No.  They are not connect only products. They say they install via DIM.  Go search DIM for it.  I have saved (at this point) all my installer files.

Product is installed, according to DIM.  So search specifically for that SKU inside Studio.  Sure enough, there's the product, twice, once installed from DIM, once not installed.

Uninstall and reinstall via DIM.  No change, still two versions.

Curiouser and curioser: If I open up the manifest, it shows a global ID the same as the uninstalled version, not the same as the installed version, which was installed, theoretically, from DIM, recorded via that manifest.

How can I clean up my library and get rid of these phantom duplicates that will put Daz Connect garbage on my computer if I accidentally click one (and give me duplicate files and god only knows what weirdass side effects)?

Glad you got it sorted :)

The missing thumbnails is a bit of a pain. If you want to fix them manually you can save an image (jpg or png) in the Runtime/Support folder with the same basename as the corresponding dsa & dsx files.

One way to do this is to right-click on the product in Smart Content/Products an click "Edit Metadata" - don't change anything in there but this gives you the basename in the "Support" field. Note this down and then click Cancel. So for example if I clicked on the "Level 19" product it would list the support file as "/Runtime/Support/DAZ_3D_2789_Level_19.dsx". Then I would go to my Product Library on this website, type Level 19 in the filter and click on the link when it popped up, then right click on the thumbnail image and save it to the correct /Runtime/Support folder as DAZ_3D_2789_Level_19.jpg. The thumbnail will then show up if you trigger a refresh of the displayed items - either click on a different category and click back or change the text in the search bar.

There might be an easier way to do it I suppose but the above will work. Obviously if you need thumbnails for non-DazStore items then you'l have to source the thumbnails elsewhere but the rest is the same.

Fae3D said:

sunnyjei said:

 

Aha!  It was https://www.daz3d.com/mrl-dforce-fantasy-hair-pack!  That was the one I was thinking of.  Now I just need it to go on sale. 

Thank you very much, everyone, several of those mentioned might work as well, I'll have a look at all of them.  I really appreciate it!

Glad we were able to help you :) If you aren't 100% set on just that one or gen 8/8.1 there are some really pretty headdresses over at Renderosity too that could be converted to pearl or have pearls already.

Thank you again!  Do you happen to know the names of any of them on Renderosity?  I searched there, too, also with very little luck.

I don't have the best of luck with searches there either so just here are some I've wishlisted but there are probably more :)

A dangling one from head and other parts: https://www.renderosity.com/rr/mod/bcs/dangling-d-force-accessories-for-g3-g8-daz-studio/135244/

**One you would have to import as obj but so pretty: https://www.renderosity.com/rr/mod/bcs/crystals-and-pearls-1/153266/

Kinda flapper style and for older gen: https://www.renderosity.com/rr/mod/bcs/gcd-jewelry---daisy-collection-for-v4/102417/

Prev gen diamonds that could be changed to pearls via shaders I think: https://www.renderosity.com/rr/mod/bcs/gcd-jewelry---ophelia-collection-for-v4/106230/

Pearls with jewels like a floral crown: https://www.renderosity.com/rr/mod/bcs/gcd-bohemia-for-g8f/128512/

Pearls like a head necklace for gen 3 but I've gotten this one to work for gen 8 : https://www.renderosity.com/rr/mod/bcs/svs-adorned-in-pearls-genesis-3-female/122114/

Pearls in the hair -comb like : https://www.renderosity.com/rr/mod/bcs/prae-pearl-hair-g3-g8-daz/125538/

Pearls on a headdress that looks like Malicifient's (sp?) https://www.renderosity.com/rr/mod/bcs/gcd-noire-for-g8f/128729/

Pearls mixed in with small flowers like a floral crown: https://www.renderosity.com/rr/mod/bcs/magie-florale-2-for-g8-and-g8-1-females/155750/

Ornate feathers and pearls by The Row House: https://www.renderosity.com/rr/mod/bcs/minnie-1920s-dancer-headdress-g8/135549/

Hope these help!

Thank you to each and every one of you who took the time to respond to my initial post.  The amount of information and history you've provided is VERY helpful and answered a lot of questions that I didn't even know I had.

Clearly, this is one of those "yeah, it's complicated - but it's also flexible so as to allow you to structure your content in whatever way you see fit"-kinds of situations.  Unfortunately, as I am new to DS it's all still extremely confusing - primarily because I'm finding myself having difficulty understanding what kind of content is used in what ways and with what compatibility considerations.  (Not to mention I still learning DAZ's rather complicated and - to me at least - non-intuitive UI.)  That puts me at a disadvantage in terms of being able to come up with my own categorization scheme.  So until I clear those hurdles I may have to just punt and go with Content Wizard to get me going and make adjustments from there over time should it become useful.

The information on Poser files and where they go was also of great interest - and I assume that it's probably worth some additional research time to figure out just how interchangeable content is between the two apps.  I used Poser a long, long (long) time ago but went with DAZ this time as it's free and I'm not sure how deeply I want to wade into back into these waters.  If DAZ's learning curve turns out to be too steep then I may just jump ship and go back to Poser at some point.  But for now, DAZ is the one I'm going to dance with.

To that end, I've done some reading and watched some videos for Content Wizard and I like how it helps manage metadata - whichI presume would help overcome my limited ability to define a good folder hierarchy for the browser.  I figure that even if I can't drill down to an outfit that will work with a selected model (for instance) then at least the context-aware tools and search functionality can help show me what the available options are.

So as to help me organize my thoughts, are there any examples out there of what kind of content structures people use for their own files?  I'm sure that seeing how other people organize things would help me understand the conceptual differences and similarities between (for instance) Genesis models, Poser models, morphs of each, clothing and accessories designed for specific models, etc.

Thanks again to everybody!  All of your assistance had been extremely enlightening and helpful!

Best,

Aaron

RFB532 said:

In Maya 2023 when I click "Daz Import" on the Maya shelf I get this error. How do I fix it? Thanks

In Script Editor it says:

DazToMaya.run()
# Error: ModuleNotFoundError: file C:\Users\X9Main\Documents\maya\modules\DazToMaya\scripts\d2m.py line 31: No module named 'pymel'

You are almost there.  Please look at the last step (step 9) in the installation instructions found here: https://www.daz3d.com/forums/discussion/574846/official-daztomaya-bridge-2022-july-update-what-s-new-and-how-to-use-it/p1

Or watch the video here: https://youtu.be/y1yizEPQvh0?t=136 (around 2:16 time mark)

PerttiA said:

Richard Haseltine said:

Renaming the folders will also break metadata and anything that depends on it.

Haven't noticed, unless you are talking about 'Smart' Content. 

Anything that uses the database

I had a hard-time importing a Genesis 3 Male character into Unreal Engine 5 (UE5); I managed to solve the issues I found and made a video showing how you I did it.

This video could be helpful to other developers trying to import their characters into UE5.

Things to keep in mind:

-Adjust bones; remove troublesome bones. Control rigs can take care of twisting motions.

-Change the skeleton's root position; you don't want your character's feet digging into the ground.

-Pose your character before exporting it; high-heeled shoes will conform to the feet pose. Pose the feet so the shoes look how they are supposed to look.

-Export adjustment morphs; clothing, hair, props, many of them come with adjustment morphs; export adjustment morphs.

-Export the "Mouth Realism HD" morph; you will find it under shape/mouth. The character teeth will look bad in UE5; you will need the Mouth Realism HD morph.

-Export every morph you think you will need. A single missing morph will force you to re-import the character, I missed morphs or discovered I needed more and that forced me to repeat the export/import process over and over again.

-Stay away from fibermesh hairstyles; you can use them if you want but be aware that it will take hours to import a fibermesh hairstyle into UE5. Fibermesh will have a heavy performance impact.

Also keep in mind that you will need interactive licenses for every component that forms your custom character.

Richard Haseltine said:

Renaming the folders will also break metadata and anything that depends on it.

Haven't noticed, unless you are talking about 'Smart' Content. 

Renaming the folders will also break metadata and anything that depends on it.

I use Windows but I expect the basic layout is the same.

Poser stuff that appears in the library - .cr2 files go in libraries\character, .pz2 files go in libraries\pose, .cm2 files go in libraries\camera, .fc2 files go in libraries\face, .hr2 files go on libraries\hair, .hd2 files go in libraries\hand, .lt2 files go in libraries\light, .pp2 files go in libraries\props, .mc5 and .mc6 files go in libraries\materials.

Poser support files - .obj files go in geometries and texture files (usually .jpg) go in textures

The directories under libraries can have sub-directories, most stuff is put in sub-directories. You can put stuff in whatever sub-directory layout you want as long as it's in the correct directory under libraries (in fact Poser doesn't care if you put stuff with the wrong extension in the wrong directory as long as it is one of the standard directories under libraries, I don't know if this is true for Studio).

Files in geometries and texures need to go in the correct sub-directory that the content expects them to be in. 

For Daz Studio most recent content uses .dsf for support files and I think they have to be in the correct sub-directory under the data directory. Some older stuff has .dsf files for content that appears in the library.

Daz Studio .duf and .dsa files are content files which can go anywhere in the library as long as it isn't in runtime or data. As far as I know there is no way to tell what sort of content it is from the extension. There is a sort of convention over what content goes where but it isn't enforced by the software. Not all content follows the conventions and it seems to me that stuff sold by sites other than Daz is less likely to conform.

I don't think the smart content system uses the directory layout, it's all based on the metadata (but I don't use smart contentv so I wouldn't know if it was broken).

Hmmm ... well I can only go on my experience and what it looks like it is doing to me. I believe that the two options I listed above will dig through all the linked base directories and find all the "dsx" files inside the Runtime/Support folder of each of them. These items are then presented to you in a window where you can scroll through the list and uncheck any that you don't want - although I just hit the button to (re)import them all each time.

Brining in stuff you have never installed sounds a bit odd and I am not sure why it would do that as AFAIK this would be an "offline" process - i.e. it is not grabbing data from the internet, only files that are on your HD (or other linked storage).

I will say that I have also, used the "Reset Database" option to completely nuke the Smart Content and then used the above two options again to re-add it back. As far as I can see this has not caused anything to be "lost" - other than custom categorisations which can be saved before hand by exporting that first.

However, if the weird glitches you were seeing before were caused by damaged/corrupted dsx files stored in your Runtime/Support folders then I suppose there is a chance these will come back.