Importing Obj Files with Materials
neverstoplearning
Posts: 69
In Daz Studio 4.10 I created a plane primitive, applied an image to it using the surfaces tab, and then exported the result as a Wavefront Obj file.
I then imported it:
- Back into Daz Studio. I checked the boxes "Read Surfaces" and "Read Material Library". The plane was imported but I did not see the image.
- Into 3DS Max 2018. I saw both the plane and the image .
- Into Blender. I saw the plane but not the image.
What am I missing about importing objects with textures?
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Use the 'Original Maps' option when exporting from DS, otherwise DS won't write a reference to the image in the .mtl file. This will write an absolute path to the image. The reference is a relative path if you use 'Collect Maps', so other programs may not be able to find the image, but DS can.
Note that Wavefront .obj is pretty much the great-grand-daddy of all commonly used 3D file formats. It's been around for so long, there are many slightly different ways to export and import .obj data, and particularly, different ways to create and interpret the texture data in the matching .mtl file. Not every program capable of importing an .obj file can do so in exactly the same way as the program that originally exported it. As you've just found out, this can include D|S having problems importing a file it's just exported. Materials settings are especially prone to glitching; the only solution is to experiment with different export and import settings until you find a combination that works.
I actually had the 'Original Maps' option checked, although I did not explicitly do it myself. I looked at the two files and the linkage looks correct, ie the obj file refers to a .mtl file, and the .mtl file contains a reference to a file with absolute path i.e. c:\users\myname\daz3d\import\xyz.jpg.
I have actually read the formal definition document on Wavefront OBJ files, and have a reference to it in my bookmarks, so I think I understand that part fairly well.
I am thinking there is something on the import side that I have missed.
I wasn't very clear.
DS seems unable to find the image map on re-import if you export using 'Original Maps'; this writes an absolute path in the .mtl file, and apparently DS can't or won't navigate an absolute path. Other applications (I've tried Blender) can find the image map in this scenario with no issue.
DS seems able to find the image map on re-import if you export using 'Collect Maps'; this writes a relative path, and DS seems to like this better but other applications may not understand for obvious reasons.
I have no idea why this is, it's just an empirical observation.
That worked. Now I understand what you meant, but I read it the opposite way.
This question was a precursor to my actual current problem.
I recently purchased from "another site" a model of a brick warehouse, a good site for my scenario, I thought. It was advertized in various export formats, including OBJ. and said it included textures. I discovered the only version available that had the texttures wired up was for 3DS Max with the Corona Renderer, an expensive addon I do not have. 3DS Max 2018 would not fully import this model.
The OBJ model had the textures but the obj file had no mtl references to the texture files. Bizarre? The textures look very good -- there are nine Materials in the model and each of them has Diffuse, Glossiness, Height, ior, Normal and Reflection files, a total of 54 png files. But they are not wired up.
What is the best way to do this? Can I do it in Daz Studio?
If not, I'd prefer to try it in Blender as I am working to make Blender my modeling tool of choice, even though I know 3DS Max better. I am not an expert, but I like to think I learn quickly.
I know I can go into 3DS Max or Blender and use the Materials Editor and connect them up, but is there another way, bearing in mind everything is there waiting to be herded into the corral, so to speak.
Unusual, certainly. The .mtl ought to be a separate file, with the same name as the .obj — the .obj file defines the different material names (and which bits of the model have which material applied), and the .mtl file cross-references these names with the relevant texture file paths. In hindsight, not the way I would have done it, but design priorities were very different 30+ years ago when the program suite that originally used it was written.
Note that this is another point where things can go wrong — the first line of the .obj file ought to give the path and file name for the .mtl file, but some programs create the .mtl with absolute folder path references, and some use relative folder path references starting from wherever the .obj was saved. It gets confusing.
UV mapping and material zones are defined in the wavefront object format, you do not need the .mtl file.
If you want to import an OBJ and have the materials set up properly e.g. have image maps assigned, I believe you need the .mtl file. However, I am open to being corrected if you can explain how to achieve this result without an .mtl file, which contains the material definitions - they are not in the .obj file, only a reference to the .mtl.
This time the ambiguous wording came from me!
Here is the complete mtl file:
# 3ds Max Wavefront OBJ Exporter v0.97b - (c)2007 guruware
# File Created: 20.03.2018 13:19:32
newmtl wire_086086086
Ns 32
d 1
Tr 0
Tf 1 1 1
illum 2
Ka 0.3373 0.3373 0.3373
Kd 0.3373 0.3373 0.3373
Ks 0.3500 0.3500 0.3500
That is all.
In the obj file, there are exactly 10 usemtl lines which all refer to the single newmtl above. Example:
g Floor
usemtl wire_086086086
s off
f 16510/20507/427 16511/20508/427 16512/20509/427 16513/20510/427
# 1 polygons
#
# object Wall04
#
v 1996.1932 439.3176 2028.1775
v 1996.1932 437.0424 2028.1775
v 1996.1985 437.0424 2029.8895
...
Nothing else. Meanwhile in the same folder there are these 54 png files all sitting there waiting to be used.
It seems to me that even if the materials were properly linked up in the obj/mtl files, the default Daz shader would probably not make full use of all those maps, which is a shame as they'd all be useful in Iray.
So, assuming you can work out which set of images should apply to which surface(s), I guess you just have to spend some time in the surfaces tab manually applying the different images to the relevant places. A bit of a pain, but probably quicker than trying to conjure up an mtl file from nowhere.
Have you raised this as an issue with wherever you got the model from?
The Wavefront material system is ancient and pretty basic, and as such can't handle "elaborate" shader systems, a wavefront exporter needs to recognise some of the "channels" being used in the shader, if it can't then what you get is an .MTL exactly like the one you have.
Most DS1 to 3 vets will have experienced something similar to this at some point, as we have a similar issue with some Poser content, DS can only read the P4 material system, so if all of the textures are plugged in through the alt diffuse channel then all we get is a "white" mesh.
Remedy is the same in both cases, rebuilt the surface yourself using the supplied textures and what ever shader you feel like using.
I was afraid that would be the ultimate answer. Being a complete beginner at 3D art, but with a software design and development career behind me, I was wondering if I could write some code to "wing it". Evidently not.
Are you therefore saying that the rebuild must be done in Daz? Because if I do it in, say Blender, it will have the same problem exporting from Blender and and importing back to Daz. Or am I missing something?
If Daz Studio is your intented rendering tool, then you will definitely have the best luck just loading the OBJ and setting the surfaces by hand using Studio's tools. Once it's done, you can save it off as a Scene Subset or such and you can just use that for renders in the future.
Any other approach, I'm afraid, is going to be subject to the "Your Mileage May Vary" caveat to any advice we may offer.
I tried another experiment, in the "wing it" spirit.
Editing the obj file directly, I changed all of the usemtl statements that were originally identical, so each was unique and appropriate, wall, floor, celing, window, etc. The obj file had # comments in it that made this reasonably easy.
Editing the mtl file drectly, I duplicated the single minimal newmtl section several times, and gave each section the unique name of one of the usemtl statements I had modified.
Then I hacked different Kd values for r g and b into each of the resulting newmtl sections, red, green, blue, cyan, magenta etc.
When I import the result into Daz, I get an apparently empty space, but everything is at zero opacity, so when I fix that, the different colors come through, and there are surfaces defined. Real progress.
There is still only one object.