Loading textures with obj files

I have obj mesh data loading fine, other than the meshes not being textured. I’m able to render them textured by manually loading the texture (was converted to png), creating a Material with it, and setting the Material on the Spatial. But these obj files being loaded do have a “usemtl” line, and it’d be nice to have this be automatic. The original textures are dds.



What’s the best way of loading these obj files with their textures? Do I need to convert the dds to another format? Where do I place the texture files? Do I need to take any extra steps for jme to find the texture assets?

The texture files have to be in the same location of the .obj model. If your exported material doesn’t have references of the textures you are missing to set up something before exporting.

I’m not exporting anything, these are already-created models, which use dds textures. (Dropping the dds files in the same directory doesn’t work.) But I’m pretty sure they’re already referencing a texture because they have a usemtl line, and a freeware viewer I’m using shows them w/textures.

See if there is a missing somewhat in the log. For me mtl loader works as wanted.

All I can see in the log are complaints about some statements that I don’t think are essential.



Unknown statement in OBJ! newmtl

Unknown statement in OBJ! Ka

Unknown statement in OBJ! Kd



There’s a “usemtl” line, and it seems to be accepting that fine. My problem is really just that I don’t know what to place in the assets/Models directory. Do I need to use some program to convert ddl textures to “mtl”? It’d be easiest if I could just use pngs (already confirmed that I can do this but I have the manually create and set the Material).



Is there any documentation on obj support?

This is how the obj files begin:



s map_castle_a

newmtl fake_houses

Ka 0.8 0.8 0.8

Kd 0.2 0.2 0.2

usemtl fake_houses

v 1.04909 -0.322457 -1.00357





I have a “fake_houses.ddl” texture file which (when converted to png) works fine if I load it into a Material; but I’m under the impression that this step shouldn’t be required loading an obj file.

Your obj shoudld have a .mtl with the same name, jme automatically looks into this and tries to resolve any materials it finds in the obj with the mtl. the dds should just be in the same file as the obj and the mtl and it should work. (and since dds can be loaded by jme there should be no problem with that)



could you post the full mtl? Cause it seems that the mtl loader is easily confused by a invalid mtl (like for example a // comment at the start screws everything up)



The .obj should include this line:

mtllib Teapot.mtl //but for your mtl of course

(it might be that it also accepts similar meaning tags for this, there are some multiple defined keywords in obj/mtl exitant)

Why is your MTL file in your OBJ? This is not following the spec

That’s the problem - I don’t have any mtl files, just obj and dds. The obj doesn’t have any other relevant lines (and doesn’t have any mtllib command), the rest of the obj is just vertex data and so on.



I don’t have control over, and didn’t create the content being loaded. It’s from an already developed game, and my tool is for a modding utility which utilizes the game’s resources. As far as I can tell the game assets just don’t contain mtl files at all; it appears to be loading it’s models using different means.



It’s starting to seem like I’ll just have to create and set Materials manually, like I’ve already done once successfully. I was hoping this could be automatic to save some effort, but I guess not.



This isn’t anything to do with jME specifically, and is entirely to do with the odd nature of the assets being loaded, so I guess I’ll just have to deal with it.

Momoko_Fan said:
Why is your MTL file in your OBJ? This is not following the spec


We'd probably have to speak with the developers of the game the assets came from to find out. :)

Edit - Actually this could also be a result of how openBrf extracts the obj files from the .brf they're stored within. In either case, I dunno why.