Page MenuHome

Blender 2.8 drops textures and materials when exporting to OBJ (and others)
Closed, ArchivedPublic


I have a particular blend file with a single mesh.

When I export to obj fbx or dae, blender drops the textures and materials.

This seems to be specific to this file/mesh, so it is a good example that isolates the problem.

I have attached a zip file containing the blend file with mesh and texture maps.

Event Timeline

Ion (RenderHub) renamed this task from 2.8 drops textures and materials when exporting to obj (or any other format) to 2.8 drops textures and materials when exporting to OBJ .Aug 8 2019, 6:51 AM
Ion (RenderHub) renamed this task from 2.8 drops textures and materials when exporting to OBJ to Blender 2.8 drops textures and materials when exporting to OBJ (and others).
Ion (RenderHub) updated the task description. (Show Details)
Philipp Oeser (lichtwerk) changed the task status from Unknown Status to Unknown Status.Aug 8 2019, 11:33 AM
Philipp Oeser (lichtwerk) claimed this task.

Atm. node_shader_utils (see only has pretty basic support for exporting/finding ImageTextures connected to a socket.
This is used by OBJ and FBX export.

Meaning it only takes textures into account that are directly plugged into the socket [for normalmaps it considers the Normalmap node in between].
It can then also take TextureMapping into account that feeds the ImageTexture node.

But it does not do operations in between the socket and the texture (like in your case: you are doing color operations on them RGB to BW, Power, Invert even mixing two textures to feed one socket)
On the one hand it makes sense to not consider these "valid" branches in the nodetree [OBJ at least doesnt have a concept of a shadertree], because even if the exporter would find a texture somewhere in the branch and exports this, the result would be different from what you see in blender (the color operations etc. cannot be represented and would need to be dropped).
On the other hand, one could argue it would still be good to export a texture down the branch (even if it would only come back on import as directly connected to the corresponding socket), so that you would still have the texture and then manually recreated the color operations afterwards...

My vote would be to support this once in the future [pick a texture it finds in the branch], but at this point in time I assume this would not be considered a bug...
@Ion (RenderHub): out of pure curiosity: do you know of other software that would support such a case on export for OBJ (FBX)?

I'm afraid we have to close this [unless @Bastien Montagne (mont29) has objections?]...
@Bastien Montagne (mont29): still would be good to know if we put this as TODO somewhere?

Hey guys.

Thanks so much for taking this.

So. I understand the limitations of OBJ and FBX, but consider a model with many surfaces, it would definitely be a good idea to carry the base color (an any other supported maps) to the final export file.

BTW: this does work as expected in blender 2.7x. If I take this same file and export using 2.7x, the textures do come over. Kind of a step backwards here :(

Blender 2.7x still had the (very old-fashioned) texture-assigned-to-face thing (directly defined in mesh data itself, outside of any material consideration). That has been removed in 2.8 (essentially because having to take care of an ID pointer in every face of every meshes was a huge performance issue).

OBJ and FBX can perfectly export as many materials and textures as you want, as long as you respect the expected limitations (i.e. use only a basic node set-up with the Principled BSDF, and some textures directly linked to it (optionally with some transform node in-between). those formats cannot really support anything else anyway.

Ok, did a little experiment....

Attached are the mtl files created by Blender 2.79 and 2.8 on the same model

You will notice the 2.79 one retains the texture info.

Not sure about everyone else, but for me this would basically force me to go back to 2.79

Ion (RenderHub) added a comment.EditedAug 8 2019, 5:44 PM

Hey Bastien

So, I get what you are saying. But consider the situation where I receive a blender file from someone (say a client), and they need back an OBJ. Before it was quite simple to just export it and the textures would stay put.

Now the person receiving the OBJ would have to go through and reassign all the textures to each material.

From a real world perspective, this just created a HUGE amount of work for us (and for others I bet)

If there is a performance issue, dont strip functionality, figure out how to make it more efficient! <- 2 cents :)

I know it is only 1 aspect, but texture mapping is so fundamental.

Imagine having a model with 300+ materials which may be poorly named. It would take hours to reassign the textures.

We gotta get this put back in, until then our entire organization is going back to 2.7x
I worry that I may not be alone in this, and we really want to move forward using 2.8

I do not understand you, surely you are not using 300 different textures images in your model? Also, texture mapping exists for a reason, so that you can put several images in a single one, and map each part to the relevant face... All this is supported in 2.80 shading nodes handling by importers/exporters (as long as you do not add any fancy things and stick to the basic bare minimum in your node system, as already said).

In your model, remove all the 'invert', 'multiply' etc. nodes, and you'll get your textures in your MTL.

Please someone help me with this same problem......when i export file....the texture attached to principle BDSF doesn't go with it.I need to sell my 3D-Models and I can't fix this problem.....I have been searching for the solution for this problem and can't find it....I am not a pro but a normal blender user or even lower.....Please reply in easy words or please give me your ID of Fb so that we can chat and find the solution through teamviewer

@Hamza (HamzaZero) : if the documentation is not clear enough:

  • your textures must be directly linked to the sockets of a Principled BSDF node
  • no other nodes are allowed between the Image texture node and the socket (since these would alter the way the image looks)
  • if you are following these rules and textures are still not exporting, please open a new report and make sure to provide an example .blend file including textures, thx

It could be improved, yes (also see feedback in T68704: Documentation: explain that Blender 2.80 Exporting a textured OBJ with any shader other than Principled BSDF will result in an MTL without map_Kd pointing to texture file), but this is choice for now...

Philipp Oeser (lichtwerk) My friend....I can give u the example.Can you just give me your FB ID or something so that I can send u my whole project I made so no one else can take it and sell it because I made it with quite an effort and I need to sell it for myself.


Closed and invalid? I'm sorry but this is not invalid. In Blender 2.79, I was able to export an obj and have the mtl file carry over the material values including color. As of Blender 2.8, exporting a mesh with a red material drops the color and imports as white. This is not acceptable in my opinion.

Hello, I am experiencing a similar problem between the export results in 2.79 and 2.83. In my case, the issue appears to be that 2.83's fbx exporter is dropping my second UV layer. I work on an openscencegraph base project for which we use the osgconv utility to convert fbx format files to ive format. One of the features of osgconv is its ability to convert to a "readable" osg format. For proof of my theory, I exported a very simple fbx file out in both versions of Blender. I then used osgconv to convert each from fbx to osg. Upon comparing the two files I could see that the 2.83 osg file was missing the last block of code which I summarized to be the second UV layer. I copied this block from the 2.79 osg file into the 2.83 file and tested it in our OSG project. Sure enough, the test now demonstrated the presents of the missing second layer which is used by our shader for normal map information. Look for the "TexCoordArray 0 Vec2Array " entry and then look for "TexCoordArray 1 Vec2Array" entry. You should see a difference. I realize this is probably not a big problem for the user community since most have moved on, no one talks about OSG or ive files anymore but it's important to our project and it would be fantastic to be able to leave 279 for good. If this gives you any clues to help Mary, that's win-win, right? Thanks for the great work. Attached are my test files.

I'm experiencing the same problem in Blender 2.9. I tried many formats fbx. obj and so on. I attached the textures, and blender and final exportied files aswell. Anyone could please tell me what did I wrong? I tried PBR materials to export and it wasn't success. After that I baked the materials into one texture and added it to the mesh in the shortest way and it doesnt works aswell... My test person is the simplest cube in Blender so I dont know now what is wrong. I want to do the procedure on a multiply complex mesh and it's crap on a simple one...? HEEELP! :))