[solved] Wavefront obj (made by ArchiCAD) materials missing in 2.5b

I’m an architect who wants to render ArchiCAD-made houses in Blender. I have the options to export from ArchiCAD through 3DS (obsolete) or Wavefront.

The ArchiCAD Wavfront exporter is quite tricky, since it puts non-ASCII chars into the obj and mtl files, but I can remove them.

After importing into 2.5b (Debian Linux), there is a correct geometry, but all the materials seem to have the same numbers (intensities, etc), obviously the script didn’t import the mtl file (from the same directory).

The mtl file has no non-ASCII chars in its filename/path or in itself.

How to fix it?

Is it possible to import the mtl directly? Should I try to repair the files manually?

(With the Google Sketchup I can make a collada from the 3DS, but it also isn’t improrted to the Belnder, so I cannot render at all :frowning: )

You could always post a simple example that shows the problem on the bug tracker so it gets fixed.

Also think they may have fixed the non-ascii character problem after the last beta release.

Posting things into bug tracker was always too difficult for me, but I’ll give it a try. At blender.org?

Have you tried importing the same model in Blender 2.49? I don’t have ArchiCAD myself so I cannot test, but I remember that with some export settings ArchiCAD .obj files imported very nicely (including materials) whereas with other settings the materials would get lost. Sorry for not being more specific, but this way you could at least test if this is really a regression or if ArchiCAD’s export settings were not correct.

In the blender 2.5 help menu there is a ‘Report a Bug’ option that takes you directly to the bug tracker.

I’ll give it a try.

Otherwise, is there any 3D formats that blender 3.5 reads smoothly? 3DS odesn’t work, collada didn’t work for me, again, Wavefront also.

My goal is not to fix bugs, but to find a working solution.

The goal of beta software is to detect bugs and get them fixed, I assume that is why you have decided to use some beta software to begin with, otherwise use the stable version with working importers/exporters. If the developers don’t know about a bug they can’t get it fixed. If it’s a bug and it gets fixed you would benefit from that by getting a ‘working solution’ as well as for lots of other users.
As the original beta is now getting on a bit (>1100 revisions since it was released), have you tried a more recent revision that may have any errors fixed ? http://www.graphicall.org/builds/

Yep, your best bet to find a ‘working solution’ would be to use 2.49 as that the last ‘working’ version.

Then, if you must, import your model into 2.5.

I have some python knowledge, and seemingly I found the bug.

The searching for the mtl file is problematic, in the obj it was defined with full path, and the script added the path again. The file was :
And it searched for

I modified just in the obj definition:
mtllib /Test.mtl

Apparently didn’t load any material data, but interestingly, a map (jpg) was loaded. It was the first time a map was loaded, since the 2.4x line didn’t do it. The “only” thing left is to check the material data loading.

I managed to make a perfect, relatively efforless and fast import of a large file. :slight_smile:

It’s a good question if it can be considered a bug, or not. You have to define the mareial file in a very special way ("/filename.mtl") and to remove non-ASCII chars from any name (python hates and can’t handle well these things, I know)

Finally, I didn’t have to modify the code itself, just put some “print” lines to get some variables’ value, to follow back functions, etc :slight_smile:

Thanks for Your help