This Blender Wiki link states that textures are supported in OBJ file export (look at the bottom of the page), but in my tests textures are not mentioned neither in *.obj or *.mtl files.
http://wiki.blender.org/index.php/Extensions:2.6/Py/Scripts/Import-Export/Wavefront_OBJ
Is there a solution to this?
Do you export a model from Blender Internal or Cycles? I don’t think Cycles materials are fully supportet. Also BI nodes should be dificult too.
I only tested Blender Internal obj export with the default non node material and that worked for me but I had to edit mtl file so the textures paths where relative to the file. For some reason that never worked for me.
I have to try it again some day.
I was exporting from Cycles, so I tried from Blender Internal ant it worked!
No path was included, but I’m OK with this. Thanks!
*Of course, exporting textures from cycles should be fixed as it requires a lot of work to convert the project to Blender Internal.
I would report it as a bug.
… Done!
Well it’s not really a bug, its a limitation of the obj material format, it doesn’t support nodes.
What it does support is a basic ubershader that contains: Diffuse, Spec (not raytraced) and Transparency (not raytraced refraction eg glass).
Also its supports multiple materials per object and UV’s.
I think for Cycles to support material export to obj and similar formats we need the ubershader for Cycles so the exporter can read the first ubershader node and convert it to a. mlt file.
Edit:
As it seems the mlt format does support definitions for raytraced reflections and refractions but I don’t know if blender exports them. Also it supports bump maps but couldn’t find anything about normal maps.
http://paulbourke.net/dataformats/mtl/
I think that since Blender has an OBJ exporter it should be consistent and adapt to the format. Like when you plug a stereo headset on your 7.1 amp it will downsample all the channels to just stereo for headphones. It won’t be the headphone’s format fault if you hear only the two front channels.
I also noticed that Blender Internal (and Cycles) doesn’t export the embedded textures at all and it just includes the original path -which is another bug IMO.
Well it’s not really a bug, its a limitation of the obj material format, it doesn’t support nodes.
But you don`t export the nodes, you export the whole object. And the material and texture information is part of the object when you export to Obj. Exporting just the mesh would be a bit pointless.
Let`s see what the devs say 
The obj file does not store any material definition, these are in the mlt file.
The obj file stores where on the mesh the materials are applied to (similar to a vertex group) and to which material they refere to (similar to a vertex group name). It also stores UV data, smothing and face normals (and probably more).
The defined material zones and names can be exported from Cycles to obj, but converting a Cycles node setup to mlt is difficult or even near impossible.
E.g. Let’s say you have a node setup with two textures nodes mixed and conected to a diffuse node and the diffuse is mixed to two glossy shader. The exporter would have to evaluate the nodetree and convert it to a mlt file but the first problem is mlt does only support one shader at the time so the two glossy shader have to be converted to one shader. The second problem is we have two diffuse textures that are mixed together but mlt does only support one texture per shader type and does not support any pixelmath operation, so you have to mix them in the exporter to generate one texture. That was a simple example.
The exporter have to be able to evaluate every type of nodetree and coding that could be really big project. I would no do it.
.OBJ/.MTL is an antique file format that stores only very basic information about shading and materials. Think of it as the lowest common denominator concerning import/export options between different 3D applications.
However, switching from one 3D app to another means having to recreate the materials from the ground up anyway according to the respective render engine and its settings. So where is the big deal with .OBJ not supporting texture data? As long as material tags/groups and UVs transfer cleanly. So it is indeed the mesh that is important during the export to .OBJ and hardly anything else… I tell you what: That .MTL file is most of the time the first thing for me to delete, as the information stored in it is largely useless anyway.
What OscarM just said. “Understanding” complex node setups is beyond anything an automated .OBJ parser is capable of.
Given how limited the information a .MTL file can hold is compared to the complexity of Cycles materials, your headphone analogy isn’t quite apt. This would be more like converting a BluRay quality video to play on one of those little portable TVs from the 1970s. It’s pointless. You’re better off packing up some UV image textures and assembling the appropriate material in the destination program. For that matter, if your destination program can’t handle materials more complicated than what a .MTL file can hold, Cycles is overkill to start with.
Not everything you dislike or misunderstand is a bug.
Not every bug is a feature.
Obj may be an antique format. It may be limited. But then it should be even easier to grab the available settings. And it works for FBX. Means it should work for obj too.
Blender offers Obj export. This means it should export Obj in a proper way. No matter what renderer or material system you use. Everything else is a bug. And this includes textures / normalmaps and the four available shader settings.
Now you’re arguing for the sake of it…
But I’m curious. What exactly would be a relevant use case for .OBJ with textures? You’re asking to reroute development ressources to fix the export to a mostly obsolete file format (that is hardly used for anything else but transfer of raw mesh data anyway), so:
Into which other 3D app do you want to import the .OBJ?
Why would I want to export “the four available shader settings” (whatever that is supposed to mean): The target app will most likely not use Cycles (as Blender is the only one out there and no one in their right mind would export/import .OBJ from Blender to Blender) and will therefore not be able to make use of that data?
If I have to rebuild the materials in the target app anyway, is reassigning a texture map such a big deal at all? Also be aware that you can only export a single UV set with any OBJ file, so complex texturing will already require fine tuning in the target app.
Doesn’t the target app import more modern file formats? You said yourself that FBX export works fine, so why insist on using .OBJ?
You`re a funny guy. The one who is arguing for just the sake of arguing is you.
Obj is supported by Blender. Then it should be fully supported. And not just half. And this means all issues with it should be fixed.
Like it or not. Obj is everything but obsolete. Its one of the easiest file formats available, you can modifiy it with a text editor without loosing yourself in the code. The structure is super simple. It is still one of the most used file formats too. And you can share an Obj across lots of apps where FBX fails because of all the versions and derivates. That makes it so sexy. I use it everyday in my pipeline. Blender cannot import FBX properly yet for example. So i have to rely at Obj here. And there are still several apps out there that doesnt support FBX or uses a FBX version that is not compatible with Blender. Means without Obj there is no pipeline from and to Blender then.
The target app will most likely not use Cycles
facepalm
But the target app will use the obj file. What you don`t want to get here is that it is NOT about cycles.
It is about a bug in Obj export. An Obj export includes things like the texture and normalmap, the diffuse colour, the vertex colour and a simple phong shading. All the settings that can be transfered by the Obj File specifications. And the Obj export from BI material settings works. So should the Obj export from Cycles material settings. Because i export from Blender, not from Cycles. And the one obj export works, while the other obj export is incomplete. That`s the bug.
If I have to rebuild the materials in the target app anyway, is reassigning a texture map such a big deal at all?
Following this argumentation you could drop all material relevant export for all file formats. You have to redo it in the target app anyways … . I wish you good luck to explain the other users why Blender doesn`t include textures anymore
Yes, it is a big deal when you would have to reassign the texture and tweak the material settings like diffuse colour again and again. Now guess why file formats transfers material settings and texture paths too.
@OscarM, IkariShinji, K Horseman
Your points are all valid, IF the complexity of the given model in Cycles is far greater than the mtl format, e.g if you download a 45MB blend file from BlendSwap with tens of nodes and multiple layers of textures and then you decide to export it in OBJ format (for the old TVs of '70s as Horseman said).
But there is another case: You are making models for your real-time 3D engine (for games, websites etc), you are accustomed to work in Cycles, and you deliberately create a simple setup from the beginning, OR you simplify your model’s setup in Blender before you export it in OBJ format.
You also prefer to work in Cycles as you can first achieve the best look and overall sensation for your model as a demo/inspiration/goal, then you can manually downgrade it inside Blender, graciously and efficiently in order to export it as a basis, a place to start building and adjusting your real-time shaders, towards that ideal look, as close as possible.
To make the fix easier, the exporter could export only compatible setups (eg no multiple textures for diffusion).
The OBJ format might be the lower denominator but at least in my special case, it’s one of the cleanest and easiest to write a parser for. I had also thought of including a code word at the end of the name of each material (optionally) in order to include transparency, difraction, etc that the parser would recognize.
Anyway, I won’t argue more about this subject as you’ve already made your decision (in the bug tracker).
I’m curious about what format you’d suggest for exporting from Cycles for the above case that would include more info.
Obj is supported by Blender. Then it should be fully supported. And not just half. And this means all issues with it should be fixed.
…
And the one obj export works, while the other obj export is incomplete. That`s the bug.
And Tiles’s point is valid too. It might be difficult to implement, yes. It might be of low priority yes, but is it a feature? NO!
Again, I’ll appreciate any suggestions about an export format from Cycles.
Cycles is a physically based raytracer. It is not a good place to build and adjust real-time shaders. You have one consistent problem in almost every thread you start: you don’t know how to pick the right tool for the job. You just pick the tool you feel like picking, then complain that it doesn’t happen to be the right tool for the job. Once again, here you are, trying to return a screwdriver to the store because it’s not very good at driving nails.
I wouldn’t. Blender Internal is more appropriate for creating game assets. Both for the reasons I and others have already listed, and for the fact that baking is not yet possible in Cycles. If you’re not baking normals maps and other textures for your game materials, you’re probably missing out on some pretty useful features just because you’ve decided that you must use Cycles.
Horseman, oversimplification and generalization, and judgement based mostly on statistics, is rarely a wise thing to do, too often.
You should put the exception in your equation. We evolve because we do something different than expected, we escape the norm, think out of the box, break the rules. Because we find new ways to use our existing tools and new applications. Or because we seek to improve those tools. And sometimes we might be wrong, but that’s part of the game.
First, not everyone needs to bake textures and normal maps.
Second, if reality is the goal, then using Cycles which is closer to reality to give your model the best possible look for inspiration just before you start compromising, is not necessarily a bad thing.
Third, there is reality and perception. Since we deal most of the time with the virtual world, mimicking reality at best, with some inventive thinking and effort we might trick the eye that the real-time version looks like it is being rendered in cycles. That’s the goal. But you have to see it in cycles first.
And that’s not nothing new, as you know, real-time engines most of the time target perception, not the real thing. A pseudo-Cycles-look is more than possible like everything else in the virtual world.
At this point I don’t even know what you’re talking about. This went from a discussion of the technical limitations of .obj and .mtl files to some weird three-beers philosophy about reality and evolution. Look, the bottom line is this: you’re welcome to use Cycles for “inspiration” or whatever, but it is currently not the best tool for creating game assets. If you want to create game asset textures that will play well with .mtl files, don’t use Cycles. Blender Internal is more than capable of creating the look you want in a form that your game engine will understand. Game asset creation is not the target of Cycles. It’s not being developed for that goal. But if you want it to have that goal, you’re welcome to donate enough money to get a particular game toolset coded, or code it yourself. Otherwise, quit complaining and just learn to use the tools that are available to you.
You should know, I just replied to your tool philosophy. :evilgrin: