BUG REPORT: obj importer doesn't read textures (and workaround)

Padone

I'm going to file a bug report with the tech support about this, but meanwhile here it is to help.

I met so many discussions on this forum of users claiming that the obj importer doesn't read textures. And it seems nobody knows why. Well that's why. The obj importer can't read a path containing spaces. You need either to edit the mtl file to get the path within quotation marks, or place your textures in a path name with no spaces.

For example if you export the G2F the mtl file will be as below. Where <username> is your user name. You see that the default name for the content directory contains "DAZ 3D" that includes spaces. So if you try to import back the obj file then DAZ Studio will fail to read the textures.

newmtl Legs
d 1
Kd 1 1 1
map_Kd C:/Users/<username>/Documents/DAZ 3D/Studio/Content/Runtime/textures/DAZ/Characters/Genesis2/BaseFemale/V5BreeLimbsM.jpg

If you edit the mtl file to get the path within quotation marks then the textures will load just fine.

newmtl Legs
d 1
Kd 1 1 1
map_Kd "C:/Users/<username>/Documents/DAZ 3D/Studio/Content/Runtime/textures/DAZ/Characters/Genesis2/BaseFemale/V5BreeLimbsM.jpg"

 

EDIT: please note that inserting quotation marks is a workaround for DAZ Studio only. The other apps I tested can read spaces just fine, while they may have troubles with quotation marks in the mtl file.

SpottedKitty

There's also the problem that most programs capable of exporting an .obj form of an object (as seen in your example) explicitly state a full folder path to each texture file. DAZ|Studio native files use the same convention as Poser, where texture folder paths are all relative to the location of the base content folder — this is OK if you're re-importing the object into another program on the same computer, but if you try it on another computer, it must have the texture files in the same folder location or the texture load will fail.

Don't forget, there's an even worse problem importing an .obj created on another program — if you place these .obj and texture files into the "right" places for a D|S content folder, then none of the texture file pointers in the .mtl file will ever point to the actual texture files. After muddling through for years, I finally discovered a while back that I have to either put the texture files in the "wrong" place so the .mtl pointers can actually find them, or manually edit all the texture pointers so that the files are found properly. It's a bit of a mess, but I've got used to it, so a complete fix doesn't (mostly) take too long any more.

Padone

UPDATE: The bug report has been accepted and reported to the bug tracker.

algovincian

Sorry for the necro, but I'm running 4.12.0.85 and this still appears to be an issue today. Can anybody confirm this? Is it just seen as not a problem that the OBJ files DS exports aren't even read back in properly by DS itself?

- Greg