Hi fellow monkeys…
So I have finally decided to take the plunge into jME3 over the past weekend. Overall, I think the new API is much cleaner and more intuitive than the old one, my codebase is generally shorter and much more readable. Thanks for the great work!
I am trying to load OBJ file. These files no mtl files associated with it (I map the texture onto them externally). However, the files do have a “usemtl” line in them (probably due to some file export idiosyncrasies) which causes ObjLoader to crash. I have modified the ObjLoader class as follows (the line is question is line 335:
[java]
}else if (cmd.equals(“usemtl”)){
// use material from MTL lib for the following faces
currentMatName = scan.next();
if (matList != null && !matList.containsKey(currentMatName))
throw new IOException(“Cannot locate material " + currentMatName + " in MTL file!”);
[/java]
Basically, I added a “matList != null” test to safeguard against null point exception when matList has not been created.
Just wondering if we could apply this fix to the svn?
Thanks
If I am not mistaken…if you export obj file correctly Or you are using a right exporter, which don’t have any bug, there should be a mtl ‘always’ with the obj tile, whether you have any material specified with it or not.
iamcreasy said:
If I am not mistaken...if you export obj file correctly Or you are using a right exporter, which don't have any bug, there should be a mtl 'always' with the obj tile, whether you have any material specified with it or not.
For sure, if the export is proper, this will not be a problem. However, for my application, I explicitly don't want the MTL file there -- which will cause a problem if the OBJ file itself still have a "usemtl" line. The suggested fix basically allows the removal of the MTL file without crashing.
If there is no mtl file, then the file is you are importing is not an standard obj file.
So, when you want to import an non-standard file using a standard importer…well, I really don’t see much of a room to complain. But, yes the crash sounds like a non-standard consequence for handling this situation. 
When the .material file does not exist for OgreXML models, we do not apply materials. So I suppose to have the same functionality in the OBJLoader would be okay
Could we get this changed committed?
Okay committed
Awesome! Thank you so much.