A:M Props Some info on .OBJ/MTL files

[Rodney]

Okay, I stand corrected.

Robert had mentioned changing a texure from .png to .tga and my response was that I thought those were hard coded into the .OBJ file.

We *can* change the texture format of an .OBJ and we can do a whole lot more too.

The secret sauce is in the .MTL file which can be edited in a text editor.

 

http://en.wikipedia.org/wiki/Wavefront_.obj_file

 

Look down until you get to the Material template library section.

 

To go out on a limb and possibly be wrong yet again I'll say that perhaps it is that material that is assigned to the .OBJ that is interferring with the rendering of the image/texture?

 

Attached is an image I got out of A:M's renderer by adjusting the dissolve (transparency) parameter in the MTL file and here is the text of (my) current MTL file:

 

# File produced by Open Asset Import Library (http://www.assimp.sf.net)

# (assimp v3.1.123720346)

newmtl Trank_bark

kd 1 1 1

ka 1 1 1

ks 0 0 0

ke 0 0 0

d 1

Ns 64

illum 2

map_kd textures/bark_0011.jpg

newmtl branches_d2x2

kd 1 1 1

ka 1 1 1

ks 1 1 1

ke 1 1 1

d .1

Ns 64

illum 2

map_kd textures/DB2X2_001.png

 

 

Initially I thought the ka was for Alpha... but that is ambiance. the d (by itself) is dissolve which is akin to transparency.

 

You may note in the text that a URL with the name assimp is listed.

That program was recently updated/replaced (as of June) and is yet one more of many converters making the rounds.

[Rodney]

Attached is the same .OBJ file rendered with the following change to the MTL file:

 

# File produced by Open Asset Import Library (http://www.assimp.sf.net)

# (assimp v3.1.123720346)

newmtl Trank_bark

kd 1 1 1

ka 1 1 1

ks 0 0 0

ke 0 0 0

d 1

Ns 64

illum 2

map_kd textures/bark_0011.jpg

newmtl branches_d2x2

kd 1 1 1

ka 0 0 0

ks 0 0 0

ke 1 1 1

d .001

Ns 64

illum 1

map_kd textures/DB2X2_001.png

 

 

[robcat2075]

Interesting. I like that they can have comments in their files.

 

Any idea what the other k things stand for?

[Rodney]

Any idea what the other k things stand for?

 

Not only do I have an idea what those do... what else we can add too.

 

It's all (or at least there is a lot of info) in the wikipedia write up.

 

 

(at least in this case) the name of the MTL file is on the first line of the OBJ file.

[Fuchur]

Yes... I have used that for implementing a 3d object viewer based on three.js and making the 3d-object uploadable as OBJ + MTL + Texture-Files there to be easily used by non-programmers in our CMS.

For that, since I change the filenames for security reasons I had to change the MTL-file too to be able to use the textures again and in the end, it is nothing else than a text-file, which gets interpreted and can be changed too.

 

See you

*Fuchur*

[robcat2075]

 

To go out on a limb and possibly be wrong yet again I'll say that perhaps it is that material that is assigned to the .OBJ that is interferring with the rendering of the image/texture?

 

On that matter, I'll venture that since the texture is interpreted correctly in shaded mode and progressive render that the problem is an oversight in A:M's renderer.

[Rodney]

On that matter, I'll venture that since the texture is interpreted correctly in shaded mode and progressive render that the problem is an oversight in A:M's renderer.

 

 

Initially I wasn't leaning that way and I'm not sure now either.

There are too many things I haven't been able to test properly but my gut feel initially was that the MTL was somehow interferring with seeing the textures correctly.

I'm still leaning toward that. (in A:M it'd be like placing a decal over a surface color and wondering why you can't see the surface color)

 

It's interesting to note that two different .OBJ converters created two different MTL files and one's material (a spherical white thing) was transparent with visible leaves in the other... all based on the same image/texture. This would suggest that the problem is with the .OBJ or MTL file but the problem on my end was that regardless... both rendered incorrectly in A:M. (Drat... and here I thought I'd found the solution!)