Trying to import a OBJ model + mtl and nothing happens when trying to view it?

Hi, I’m trying to import this OBJ model + mtl and nothing happens when I try to convert it to the .j3o format and if I try to “View model” it simply displays this /very/ generic message and spits nothing to the console or the error log on the bottom right corner of the SDK. Any idea why?

Here are the model + mtl files:

Not getting it… I succesfully loaded OBJ files before, but I’m not sure why this simply does /nothing/ at all without any specific error.

Thx :smiley:

Try to import it in blender and then resave it.

Obj is a really unclean format, with many unofficial extensions.

1 Like

Hi, thanks for your reply. ORLY? I thought it was readable and thus a very clean and supported format.

OK so I tried to import it in Blender, well, even Blender does nothing, but in the console I see out of bounds exceptions for UV mapping in the material file, OH WELL… so this model seems unsupported! I’ll try and get this under another format.

Thanks :smiley: (+1’ed)

Exactly this is the problem,
since everyone can open and read them,some think, hey this is easy, lets write a exporter for it, half of them is partly faulty for edge cases.

‘However, not all software supports the latter approach, and conversely some software inherently writes only the latter form (due to the convenience of appending elements without needing to recalculate vertex offsets, etc.), leading to occasional incompatibilities.’

“# some implementations use ‘map_bump’ instead of ‘bump’ below”

ect. There are quite some stupid stuff there (Sadly all formats that are understandable by more than one program, are always somewhere unclean implemented)

Anyway if blender can’t load it, it’s probably the model itself that is broken in this case.

Well. Thanks for explaining this. At least I know OBJ+MTL is not as supported as I thought. I picked this up where I left it last time.

I could FINALLY import my OBJ+MTL tree model by recreating the material definition by hand… must have been something like you said in the file that was poorly written or poorly supported. So what I did is I programmatically instanciated a lighting.j3md material, bound the texture map manually, the repeat attribute, set the alpha flag, cutoff, etc… and this for all 3 model parts that each have 1 texture (yes, I will need to make a texture atlas at some point I know!) like the leaves is one mesh, the trunk another mesh, etc…

Please bare with my n00bness here please lol…

So now everything seems to work perfectly, except for one very annoying (but maybe not that hard to fix?) thing: NORMALS all seem to point in the same direction for 1 of the 3 model submeshes, careless of the faces orientation, and I’m talking about hundreds of faces (the tree’s leaves). The trunk’s normals are PERFECT and reflect light in all direction, self-shadow on it works, I mean it’s perfect, so why are the leaves part from the very same exact model do not behave? Hard to say as JME3 gives absolutely no error, I mean /no/ error at all in the console or anywhere else. It doesn’t say “there are no normals” or anything relevant that I have read on other JME3 forum posts. I have searched the forums yesterday and came upon /some/ things that may be related, but I just don’t know how to go about with this…

I tried to list the submesh normals, but I picked up code from an older post here and I’m not sure if it’s the index is in the correct stride… to tell the truth, I didn’t find very trivial documentation to follow for this problem.

Please look at these screenshots; Here is my tree at night (same problem with the sun, but it’s easier to see what I’m talking about at night because of the contrast)…

///// #1: Here’s the tree in a direction where all the leaves are unlight, because their normals point in the same direction as the camera… you can see that the trunk is perfectly lit tough.

///// #2: Here, we can see that all the leaves are lit, because the camera faces their normals. The trunk is still perfectly lit.

OK, so from what I understand, for the leaves submesh, the normals are all pointing in the same direction or are zero’ed because the OBJ importer could not understand them or whatever… not sure why, but my question is: Is there a function I could use to recalculate/regenerate them properly based only on the mesh vertices?

What I don’t understand is that this is from the .obj file:


vn 0.980649 0.0489529 0.189555
vn 0.702173 0.0768689 -0.707845
vn -0.300035 0.055718 -0.9523
vn -0.93559 0.00863499 -0.352982
vn -0.963362 0.0316074 -0.266334
vn -0.937405 0.0188249 0.347731
vn -0.230075 -0.00841333 0.973137
[…] etc…

There ARE normals and they’re not pointing in the same direction. This looks legit, so are they plainly ignored by the importer or is there another reason for this not to work? Can it be that the leaves are QUADS instead of TRIS? If so, is there a way to triangulate them or something?

I even tried to print them out with this:

IndexBuffer ib = ((Geometry)spatial).getMesh().getIndicesAsList();
FloatBuffer pnb = (FloatBuffer) ((Geometry)spatial).getMesh().getBuffer(Type.Normal).getDataReadOnly();
for(int i = 0; i < ib.size(); i++){
System.out.println(“n”+ib.get(i)+": {"+pnb.get(ib.get(i))+", “+pnb.get(ib.get(i)+1)+”, “+pnb.get(ib.get(i)+2)+”}");

…and it would output them like this:

n39994: {0.110682, -0.0791595, 0.586649}
n39992: {-0.0791595, 0.88185, 0.110682}
n39995: {-0.0791595, 0.586649, 0.224953}
n39993: {0.88185, 0.110682, -0.0791595}
n39996: {0.586649, 0.224953, 0.522654}
n39997: {0.224953, 0.522654, 0.586649}
n39998: {0.522654, 0.586649, 0.224953}
n39996: {0.586649, 0.224953, 0.522654}
n39999: {0.586649, 0.224953, 0.522654}
n39997: {0.224953, 0.522654, 0.586649}

WHAT I DON’T LIKE FROM THIS OUTPUT is that if you analyse it, you can see the exact same 4 vertex normals are printed on each line (a little off, which makes me think I got the FloatBuffer reading wrong, but if I’m right about this assumption, the normals are A,A,A,A and B,B,B,B and C,C,C,C which is basically always like a ZERO vector right? So this would explain the whole thing, except for how one would go and regenerate those normals properly :stuck_out_tongue:

This also seems more and more like this model is QUADS, not TRIANGLES. How can one programmatically convert those vertices to form triangles or IS IT REQUIRED for lighting to be triangles at all?

Thank you so much whoever replies to me for your time. All suggestions are welcome.

Well, it turns out the OBJ file was not triangulated and thus, it’s now obvious to me that the normals were not correctly interpreted by JME3. I want to share this hair pulling mess with everybody and even if I forget one day, at least, I’ll know if I search on Google, I’ll find this thread lol…

All I had to do (but it took me many hours and so much useless Google searches to figure this out) was to create an empty document and import this OBJ in Blender, don’t touch anything and just export it. Right before saving it, in the export options, make sure to check TRIANGULATE and INCLUDE NORMALS. That’s it. Everything is simply perfect now. Case closed, thanks for reading me.

I’m happy and I can go on with my life now… LOL! :smiley: