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:
normals
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:
[java]
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)+”}");
}
System.exit(0);
[/java]
…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 
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.
