I never heard from anyone about how well the Kitbash3D sets worked with it in D|S

because it's all out of my budget never worried too much but would still like to know if they import as separate objects and have all their textures 

being articulated (doors opening wheels turning etc) would be a bonus

All of what's said above it fairly true. The trap people fall into every time at the start is thinking "Should be better becasue Blender!!" and that's just not the case. One thing I disagree with is the anology "Blender is more like the Swiss army knife of 3D apps. It does it all - okay-ish.". This is inaccurate. Blender is a tool box and its up to you as the mechanic to learn to use those tools well to yeild good results. Blender, Maya, 3DS Max, doesn't matter they all require the same basic understaning of how to properly build and light a scene, render it, and then process that scene.
I know I say this all the time, but its true. Daz and Blender are compleatly differnet pieces of software. So the materials need to be aproached compelatly different. The same is true for translating Daz assets over to any DCC for that matter, or more importantly translating materials over to different renderers all together. Materials in general are a giant time sink and theres no way around it. There is a reason that in a professional pipeline people get higherd just to deal wiht them, Blender is no exception. I say this becasue trying to make renders in Cycles look like renders in Daz is alwasy going to be an uphill battle. It's like forcing a butter knife to be a flat head screw driver. Sure they have some similarities but are fundamentally different tools. To get good results with Blender you need to learn to use and get good result with Blender. The same goes for Maya, or any other DCC. All of this is why I, and some others, junk the materials in import (i use diffeo) and build them form scratch.
All that said there are things to consider. Card hair in Blender will always be difficult to get looking good without all the apropriate maps. As far as cycles is concerned when you hit render its rendering a plane, not hair. The best results in Blender are alwasy going to be form stand/particle/geonode based hair. Card hair can be done, but again you have to have all the apropriate maps and use them properly.
This brings me to another horse I have to beat to death all the time. Lighting and color managment. Daz takes care of all of this for you, alt least for the most part. Daz is meant to be a kind of one-click solution. Belnder is not. To get good results you have to work for it. That means proper lighting setups, and not just relying on an HDRI. Then theres the color managment side which will greatly effect shadows and highlights. The Default "Standard" View Transform is very, very, very, very, very, flat. Change it to AgX, or even better (in my experience) Khronos for far better results. Also don't forget almost all great renders you see get some sort of post processing. Often in something like Photo Shop.
TL;DR - Daz does a lot of stuff for you while Blender does NOTHING for you, and you have to work for it.

WendyLuvsCatz said:

I said copy and paste and rename not cut and paste and rename

the originals are still in place

and yes, in the content library, the character file and icon, tip

True, though it will mean that if the moved file is sued to load it won't have the proper metadata so it isnssssssss't a neutral option. Links are better, and involve only one file instead of two (or three). 

Richard Haseltine said:

crosswind said:

Richard Haseltine said:

WendyLuvsCatz said:

I guess then just renaming the duf, tip and icon files didn't work

you can move them all to whatever folder you like too or copy them there

renaming files should not be stressful for most people

Moving and renaming the actual files will break the metadata, and of course will have to be redone after an update.

Moving files breaks metadata while renaming files doesn't ~~ 

Moving and renaming both change the path, and so break the metadata, unless done within the appliation (though the changes will be lost if the database has to be reset).

I thought the suggestion was doing so in Content Lib.

WendyLuvsCatz said:

Richard Haseltine said:

WendyLuvsCatz said:

I guess then just renaming the duf, tip and icon files didn't work

you can move them all to whatever folder you like too or copy them there

renaming files should not be stressful for most people

Moving and renaming the actual files will break the metadata, and of course will have to be redone after an update.

he doesn't use smart content and if he did I suggested copying and pasting to the characters folder then renaming 

Smart Content is not the only thing that uses the CMS database

honestly though, everything is too much bother and if just not buying stuff is less stressful for him that might be best

crosswind said:

Richard Haseltine said:

WendyLuvsCatz said:

I guess then just renaming the duf, tip and icon files didn't work

you can move them all to whatever folder you like too or copy them there

renaming files should not be stressful for most people

Moving and renaming the actual files will break the metadata, and of course will have to be redone after an update.

Moving files breaks metadata while renaming files doesn't ~~ 

Moving and renaming both change the path, and so break the metadata, unless done within the appliation (though the changes will be lost if the database has to be reset).

Richard Haseltine said:

WendyLuvsCatz said:

I guess then just renaming the duf, tip and icon files didn't work

you can move them all to whatever folder you like too or copy them there

renaming files should not be stressful for most people

Moving and renaming the actual files will break the metadata, and of course will have to be redone after an update.

Moving files breaks metadata while renaming files doesn't ~~ 

Richard Haseltine said:

crosswind said:

Richard Haseltine said:

crosswind said:

Richard Haseltine said:

crosswind said:

Different behavior of showing DUF file names in DS 2025 Alpha:

In cms database, a DUF file has two data fields related to its File Name: filename and default_filename . They can be different. The former is the latest modified one which comes from the file name physically saved.

Now in DS 4.x, it always shows filename which is a correct way (screenshot 1). But in DS 2025 Alpha, it shows default_filename which is a wrong way (screenshot 2). Screenshot 3 shows the file names of the DUF file in cms database ~~

Edit: I know why now... because of that new feature of Relabel in Content Library... It changes default_filename rather than the physical file name. However, showing default_filename in Content Library makes no sense at all to me ~ It's really confusing people and making things messy. Frankly speaking, this Relabel feature is totally useless to me. 

Besides, if Copy such a Relabelled file, then Paste it to another folder, the physical file name rather than the relabelled one is back. These behaviors are not consistent ~ BTW, sorting is also wrong...

Instead, if really needed, the better way is to show default_filename in the tip when hovering mouse over the file thumbnail ~  or make this Relabel one of the features of Tagging... That default_filename shouldn't be modified by the user~

The field names are not exposed to the end-user, and the diect editing of the database is not supported. Even knowing the names, filename as the actual filename and default_filename as the one to show in the content pane does not sound wholly unreasonable. Actually changing the column names, let alone modifying the structure, would obviously be a compatibility issue

default_filename was designed to keep the original file name of a product item and DUF file from LOCAL USER. Then filename can be changed by the user without breaking metadata linked to Content Tyep and Category, etc. etc..

How do you know what it was designed for? And even if it was designed for that, it could still be repurposed if that was less drastic than other options.

I know that by experimenting various tests as per my exp. of using large DB as well as checking the routines in cms. Logics in cms are not complex ~ Even if there were any really needed "repurposing", the DB design could've be more rational ~~

You are inferring rather than knowing, and it is about details that are not visible in a way supported by Daz. Going off-piste you can't really complain about the lift service.

Anyway, key finding is the fact. Comitted SQL shows everything ~~

This logic has been reasonably working in DS 4.x.  Relabel feature surely breaks this logic ~~ From a perspective of database architecture, a new filename data field could've been added to support this new feature, and of course, Copy / Paste and sorting behaviors have to be properly enhanced.    

crosswind said:

Richard Haseltine said:

crosswind said:

Richard Haseltine said:

crosswind said:

Different behavior of showing DUF file names in DS 2025 Alpha:

In cms database, a DUF file has two data fields related to its File Name: filename and default_filename . They can be different. The former is the latest modified one which comes from the file name physically saved.

Now in DS 4.x, it always shows filename which is a correct way (screenshot 1). But in DS 2025 Alpha, it shows default_filename which is a wrong way (screenshot 2). Screenshot 3 shows the file names of the DUF file in cms database ~~

Edit: I know why now... because of that new feature of Relabel in Content Library... It changes default_filename rather than the physical file name. However, showing default_filename in Content Library makes no sense at all to me ~ It's really confusing people and making things messy. Frankly speaking, this Relabel feature is totally useless to me. 

Besides, if Copy such a Relabelled file, then Paste it to another folder, the physical file name rather than the relabelled one is back. These behaviors are not consistent ~ BTW, sorting is also wrong...

Instead, if really needed, the better way is to show default_filename in the tip when hovering mouse over the file thumbnail ~  or make this Relabel one of the features of Tagging... That default_filename shouldn't be modified by the user~

The field names are not exposed to the end-user, and the diect editing of the database is not supported. Even knowing the names, filename as the actual filename and default_filename as the one to show in the content pane does not sound wholly unreasonable. Actually changing the column names, let alone modifying the structure, would obviously be a compatibility issue

default_filename was designed to keep the original file name of a product item and DUF file from LOCAL USER. Then filename can be changed by the user without breaking metadata linked to Content Tyep and Category, etc. etc..

How do you know what it was designed for? And even if it was designed for that, it could still be repurposed if that was less drastic than other options.

I know that by experimenting various tests as per my exp. of using large DB as well as checking the routines in cms. Logics in cms are not complex ~ Even if there were any really needed "repurposing", the DB design could've be more rational ~~

You are inferring rather than knowing, and it is about details that are not visible in a way supported by Daz. Going off-piste you can't really complain about the lift service.

This logic has been reasonably working in DS 4.x.  Relabel feature surely breaks this logic ~~ From a perspective of database architecture, a new filename data field could've been added to support this new feature, and of course, Copy / Paste and sorting behaviors have to be properly enhanced.    

Richard Haseltine said:

WendyLuvsCatz said:

I guess then just renaming the duf, tip and icon files didn't work

you can move them all to whatever folder you like too or copy them there

renaming files should not be stressful for most people

Moving and renaming the actual files will break the metadata, and of course will have to be redone after an update.

he doesn't use smart content and if he did I suggested copying and pasting to the characters folder then renaming 

honestly though, everything is too much bother and if just not buying stuff is less stressful for him that might be best

WendyLuvsCatz said:

I guess then just renaming the duf, tip and icon files didn't work

you can move them all to whatever folder you like too or copy them there

renaming files should not be stressful for most people

Moving and renaming the actual files will break the metadata, and of course will have to be redone after an update.

Ron Knights said:

I continue to have problems with this issue. I just want to use DAZ Studio to Make Art. I don't want to work to make that happen.

I want to look at the provided content and put it together to make a creation of my own.

I can see why DAZ provides DIM, etc. But those tools should serve us. We shouldn't need to provide our own effort to make them work.

I know we can use tools or methods like "Categories" to help find things. But we're talking hours of extra effort.

My "DAZ Studio" computer sits on a 6 ft computer desk. I don't want to spend hours sitting at that desk, working on organization. In the past, I suffered from "edema," or fluid retention. I was much heavier, and my body was bloated.

The way things are now, I sit at the computer desk for a few minutes, put things together, render and enjoy my work.

Daz content, except for the bulk transfers from other stors, is already categorised. So is some third-party content, though you will need to import the metadata in most cases. Categorising, or even settings up products, for items as you install them does not take that long - I wouldn't advise doing massive stacks in a sitting - and no pre-made organisiation, using metadata or folder trees, is going to satisfy everyone.

bastiangarrido888 said:

When I import this object together with the .mtl file, the textures do not load correctly. I think this problem is due to my lack of experience with the program. I would appreciate your help.

 

I have this problem only with most freebies, I normally have to texture the object from the images included in the file, just like Bunyip02 showed.

Richard Haseltine said:

crosswind said:

Richard Haseltine said:

crosswind said:

Different behavior of showing DUF file names in DS 2025 Alpha:

In cms database, a DUF file has two data fields related to its File Name: filename and default_filename . They can be different. The former is the latest modified one which comes from the file name physically saved.

Now in DS 4.x, it always shows filename which is a correct way (screenshot 1). But in DS 2025 Alpha, it shows default_filename which is a wrong way (screenshot 2). Screenshot 3 shows the file names of the DUF file in cms database ~~

Edit: I know why now... because of that new feature of Relabel in Content Library... It changes default_filename rather than the physical file name. However, showing default_filename in Content Library makes no sense at all to me ~ It's really confusing people and making things messy. Frankly speaking, this Relabel feature is totally useless to me. 

Besides, if Copy such a Relabelled file, then Paste it to another folder, the physical file name rather than the relabelled one is back. These behaviors are not consistent ~ BTW, sorting is also wrong...

Instead, if really needed, the better way is to show default_filename in the tip when hovering mouse over the file thumbnail ~  or make this Relabel one of the features of Tagging... That default_filename shouldn't be modified by the user~

The field names are not exposed to the end-user, and the diect editing of the database is not supported. Even knowing the names, filename as the actual filename and default_filename as the one to show in the content pane does not sound wholly unreasonable. Actually changing the column names, let alone modifying the structure, would obviously be a compatibility issue

default_filename was designed to keep the original file name of a product item and DUF file from LOCAL USER. Then filename can be changed by the user without breaking metadata linked to Content Tyep and Category, etc. etc..

How do you know what it was designed for? And even if it was designed for that, it could still be repurposed if that was less drastic than other options.

I know that by experimenting various tests as per my exp. of using large DB as well as checking the routines in cms. Logics in cms are not complex ~ Even if there were any really needed "repurposing", the DB design could've be more rational ~~

This logic has been reasonably working in DS 4.x.  Relabel feature surely breaks this logic ~~ From a perspective of database architecture, a new filename data field could've been added to support this new feature, and of course, Copy / Paste and sorting behaviors have to be properly enhanced.    

crosswind said:

Richard Haseltine said:

crosswind said:

Different behavior of showing DUF file names in DS 2025 Alpha:

In cms database, a DUF file has two data fields related to its File Name: filename and default_filename . They can be different. The former is the latest modified one which comes from the file name physically saved.

Now in DS 4.x, it always shows filename which is a correct way (screenshot 1). But in DS 2025 Alpha, it shows default_filename which is a wrong way (screenshot 2). Screenshot 3 shows the file names of the DUF file in cms database ~~

Edit: I know why now... because of that new feature of Relabel in Content Library... It changes default_filename rather than the physical file name. However, showing default_filename in Content Library makes no sense at all to me ~ It's really confusing people and making things messy. Frankly speaking, this Relabel feature is totally useless to me. 

Besides, if Copy such a Relabelled file, then Paste it to another folder, the physical file name rather than the relabelled one is back. These behaviors are not consistent ~ BTW, sorting is also wrong...

Instead, if really needed, the better way is to show default_filename in the tip when hovering mouse over the file thumbnail ~  or make this Relabel one of the features of Tagging... That default_filename shouldn't be modified by the user~

The field names are not exposed to the end-user, and the diect editing of the database is not supported. Even knowing the names, filename as the actual filename and default_filename as the one to show in the content pane does not sound wholly unreasonable. Actually changing the column names, let alone modifying the structure, would obviously be a compatibility issue

default_filename was designed to keep the original file name of a product item and DUF file from LOCAL USER. Then filename can be changed by the user without breaking metadata linked to Content Tyep and Category, etc. etc..

How do you know what it was designed for? And even if it was designed for that, it could still be repurposed if that was less drastic than other options.

This logic has been reasonably working in DS 4.x.  Relabel feature surely breaks this logic ~~ From a perspective of database architecture, a new filename data field could've been added to support this new feature, and of course, Copy / Paste and sorting behaviors have to be properly enhanced.    

Richard Haseltine said:

crosswind said:

Different behavior of showing DUF file names in DS 2025 Alpha:

In cms database, a DUF file has two data fields related to its File Name: filename and default_filename . They can be different. The former is the latest modified one which comes from the file name physically saved.

Now in DS 4.x, it always shows filename which is a correct way (screenshot 1). But in DS 2025 Alpha, it shows default_filename which is a wrong way (screenshot 2). Screenshot 3 shows the file names of the DUF file in cms database ~~

Edit: I know why now... because of that new feature of Relabel in Content Library... It changes default_filename rather than the physical file name. However, showing default_filename in Content Library makes no sense at all to me ~ It's really confusing people and making things messy. Frankly speaking, this Relabel feature is totally useless to me. 

Besides, if Copy such a Relabelled file, then Paste it to another folder, the physical file name rather than the relabelled one is back. These behaviors are not consistent ~ BTW, sorting is also wrong...

Instead, if really needed, the better way is to show default_filename in the tip when hovering mouse over the file thumbnail ~  or make this Relabel one of the features of Tagging... That default_filename shouldn't be modified by the user~

The field names are not exposed to the end-user, and the diect editing of the database is not supported. Even knowing the names, filename as the actual filename and default_filename as the one to show in the content pane does not sound wholly unreasonable. Actually changing the column names, let alone modifying the structure, would obviously be a compatibility issue

default_filename was designed to keep the original file name of a product item and DUF file from LOCAL USER. Then filename can be changed by the user without breaking metadata linked to Content Tyep and Category, etc. etc..

This logic has been reasonably working in DS 4.x.  Relabel feature surely breaks this logic ~~ From a perspective of database architecture, a new filename data field could've been added to support this new feature, and of course, Copy / Paste and sorting behaviors have to be properly enhanced.    

I've found it! And it seems to be to do with bone chains in the same way?
The set was GeeSee3D "Professors Office", and the props in question were the blinds, the power strip and the power cord... all of these have either the cords or the pull-strings on the blinds be made up of a million bones so you can pose them like a snake.

These were the logs from the sections where the prop is being loaded to when it crashed: 

Blinds:
2025-08-18 20:06:22.336 [INFO] :: Prepare asset load (merge): /Props/GeeSee3D/Professors Office/Props/PO Blinds.duf
2025-08-18 20:06:22.336 [INFO] :: Locking viewport redraw...
2025-08-18 20:06:22.336 [INFO] :: Viewport redraw locked.
2025-08-18 20:06:22.360 [VERBOSE] :: Native format content directories: 3

Power Strip:
2025-08-18 20:07:46.761 [INFO] :: Prepare asset load (merge): /Props/GeeSee3D/Professors Office/Props/General Props/PO Power Strip.duf
2025-08-18 20:07:46.761 [INFO] :: Locking viewport redraw...
2025-08-18 20:07:46.761 [INFO] :: Viewport redraw locked.
2025-08-18 20:07:46.794 [VERBOSE] :: Native format content directories: 3
2025-08-18 20:07:46.794 [VERBOSE] :: Poser format content directories: 3
2025-08-18 20:07:46.794 [VERBOSE] :: Other import format content directories: 0
2025-08-18 20:07:46.794 [INFO] :: Begin asset load (merge): /Props/GeeSee3D/Professors Office/Props/General Props/PO Power Strip.duf
2025-08-18 20:07:46.797 [INFO] :: Determining missing assets...

Power Cord:
2025-08-18 20:11:16.565 [INFO] :: Prepare asset load (open): /Props/GeeSee3D/Professors Office/Props/General Props/PO Power Cord.duf
2025-08-18 20:11:16.565 [INFO] :: Locking viewport redraw...
2025-08-18 20:11:16.565 [INFO] :: Viewport redraw locked.
2025-08-18 20:11:16.602 [VERBOSE] :: Native format content directories: 3
2025-08-18 20:11:16.602 [VERBOSE] :: Poser format content directories: 3
2025-08-18 20:11:16.602 [VERBOSE] :: Other import format content directories: 0
2025-08-18 20:11:16.602 [INFO] :: Begin asset load (open): /Props/GeeSee3D/Professors Office/Props/General Props/PO Power Cord.duf

The computer wasn't reading anything obsurd in terms of CPU, GPU or memory useage, it just stopped responding and that was it.
If theres any other info that I can get that is more useful, let me know! 

Artini said:

I have also found some informations in the Blender manual.

https://docs.blender.org/manual/en/latest/addons/import_export/scene_fbx.html

They also mention some problems with import of FBX to Blender.

I am trying to import FBX with Humanoid animations from Unity.

 

 

For importing FBX into Blender, the add-on Better FBX Importer & Exporter is a good alternative ~

I have also found some informations in the Blender manual.

https://docs.blender.org/manual/en/latest/addons/import_export/scene_fbx.html

They also mention some problems with import of FBX to Blender.

I am trying to import FBX with Humanoid animations from Unity.