However, the objs appear flat and grey, without any shading, looking like they have no normals.
My obj files look like that , so they are with normals vn (this is a short version, the actual obj’s have around 10.000 - 20.000 vertices each):
v 0.000 0.000 0.000
v 0.000 2.000 0.000
v 1.000 2.000 0.000
v 1.000 0.000 0.000
v 0.000 0.000 3.000
v 1.000 0.000 3.000
v 1.000 2.000 3.000
v 0.000 2.000 3.000
vn 0.8571428571428571 0.42857142857142855 0.2857142857142857
vn 0.8571428571428571 -0.42857142857142855 0.2857142857142857
vn -0.8571428571428571 -0.42857142857142855 0.2857142857142857
vn -0.8571428571428571 0.42857142857142855 0.2857142857142857
vn 0.8571428571428571 0.42857142857142855 -0.2857142857142857
vn -0.8571428571428571 0.42857142857142855 -0.2857142857142857
vn -0.8571428571428571 -0.42857142857142855 -0.2857142857142857
vn 0.8571428571428571 -0.42857142857142855 -0.2857142857142857
f 1 2 3 4
f 1 4 6 5
f 4 3 7 6
f 3 2 8 7
f 2 1 5 8
f 5 6 7 8
I also tried reversing the normals, but I still have the same problem.
When I re-create the geometry procedurally by creating my own GeomVertexFormat.getV3n3() , then they look correct, they have normals and are shaded with the lights. However this takes too long, so I prefer to stick to loading objs.
Not sure how you generate your .obj files, but it seems that Panda does not load the normals from the example file you posted.
This is the output when printing the vertex data of the loaded model to the console:
As you can see, there is no normal data column, only a vertex data column.
It works when I add texture coordinates and change the definition of the faces as follows:
v 0.000 0.000 0.000
v 0.000 2.000 0.000
v 1.000 2.000 0.000
v 1.000 0.000 0.000
v 0.000 0.000 3.000
v 1.000 0.000 3.000
v 1.000 2.000 3.000
v 0.000 2.000 3.000
vn 0.8571428571428571 0.42857142857142855 0.2857142857142857
vn 0.8571428571428571 -0.42857142857142855 0.2857142857142857
vn -0.8571428571428571 -0.42857142857142855 0.2857142857142857
vn -0.8571428571428571 0.42857142857142855 0.2857142857142857
vn 0.8571428571428571 0.42857142857142855 -0.2857142857142857
vn -0.8571428571428571 0.42857142857142855 -0.2857142857142857
vn -0.8571428571428571 -0.42857142857142855 -0.2857142857142857
vn 0.8571428571428571 -0.42857142857142855 -0.2857142857142857
vt 0.000000 0.000000
vt 0.000000 0.000000
vt 0.000000 0.000000
vt 0.000000 0.000000
vt 0.000000 0.000000
vt 0.000000 0.000000
vt 0.000000 0.000000
vt 0.000000 0.000000
f 1/1/1 2/2/2 3/3/3 4/4/4
f 1/1/1 4/4/4 6/6/6 5/5/5
f 4/4/4 3/3/3 7/7/7 6/6/6
f 3/3/3 2/2/2 8/8/8 7/7/7
f 2/2/2 1/1/1 5/5/5 8/8/8
f 5/5/5 6/6/6 7/7/7 8/8/8
Many thanks for your answer. Indeed I wasn’t very careful with the obj format, I changed it as you suggested and it works. Also there’s no need to write texture coordinates, then the faces can be written as:
f 2//2 3//3 1//1
However, in the process of figuring this out, I was really buffled by something.
If the name of my obj starts with a number, for example I used to name them 0.obj, 1.obj and so on, then the normals are not loaded whatever the obj format.
When I changed the name to something like mesh_0.obj, mesh_1.obj then the normals are loaded.
I wonder if there’s a reason for that, or if it is just a bug.
Ah, good point! It’s been a while since I last studied the .obj format, so I forgot that faces could be defined that way.
Hmm, I can’t seem to reproduce this; when I rename my .obj file to 0.obj, the model is loaded correctly with normals. Could it perhaps be that you initially named incorrectly formatted .obj files that way and then loaded them again after correcting them, without clearing the model cache first?
Just to be sure, try loading those files as follows:
model = self.loader.load_model("0.obj", noCache=True)