Why is my OBJ parser rendering such meshes?
I made a commitment to add OBJ parser / importer support to the 3D rendering engine I was working on. I followed the spec found HEREalmost "to tee", with the current exception limiting all support for groups, faces, vertices, normals, and texture coordinates (so there is no material library or free polygon support at the moment). My goal was to just parse line by line - generate an object-oriented hierarchical tree view of the scene as I walked along - and let the developer automatically bind the data to the shader program with very few manual calls to start manipulating and viewing the mesh. The end result is that my engine successfully parses most (if not all) valid OBJ files, extracts the relevant data, and sends it to the main shader for rendering. However, even though the data appears to bescenes are displayed correctly on the chart, for one reason or another they are rarely displayed correctly ...
Note that a simple plane (exported from 3DS Max, containing only 4 vertices and 2 faces) looks great, but a cube or something more advanced usually looks something like this:
I can't tell where things are going wrong, and AFAIK my code should actually parse and render the underlying geometry just fine ... So why isn't it? For convenience, I have uploaded the project HERE . It contains a NetBeans project with a minimal version of my engine and one test application. I also included 3 different OBJ cube mesh options and one flat mesh. The application is customized by editing the values at the top of Test.java, and the only input controls are A, S, W, and D to translate the mesh and mouse movements to rotate the mesh. While I was able to shorten the project considerably, the most famous classes include additional comments / information at the top of the file.
All things considered, I'll take any thoughts I can get ... and it certainly won't be underestimated!
source to share
I didn't upload your project. What people mostly run into when writing OBJ import code for rendering with OpenGL are indexes. And as @ratched_freak also suspects in his comment, which is very much in line with the visual look of your cube.
The OBJ format uses separate indices for position coordinates, normals, and textures. For OpenGL rendering, you need one set of indexes. This means you need to create a vertex for each unique combination of position / normal / texture indexes used by the triangles in the OBJ file, assign a new index to that combination, and then use that index in your OpenGL index buffer.
I wrote an answer with pseudocode describing how to do this for a similar question recently: OpenGL - Index Buffer Issues .
Edit to illustrate the problem a little more. Here is a "cube" file I found on the Internet:
v 0.0 0.0 0.0
v 0.0 0.0 1.0
v 0.0 1.0 0.0
v 0.0 1.0 1.0
v 1.0 0.0 0.0
v 1.0 0.0 1.0
v 1.0 1.0 0.0
v 1.0 1.0 1.0
vn 0.0 0.0 1.0
vn 0.0 0.0 -1.0
vn 0.0 1.0 0.0
vn 0.0 -1.0 0.0
vn 1.0 0.0 0.0
vn -1.0 0.0 0.0
f 1//2 7//2 5//2
f 1//2 3//2 7//2
f 1//6 4//6 3//6
f 1//6 2//6 4//6
f 3//3 8//3 7//3
f 3//3 4//3 8//3
f 5//5 7//5 8//5
f 5//5 8//5 6//5
f 1//4 5//4 6//4
f 1//4 6//4 2//4
f 2//1 6//1 8//1
f 2//1 8//1 4//1
The file has 8 positions ( v
records) and 6 normal ( vn
records). In this case, the records f
are faces, triangles. Looking at the first vertex of the triangle 1//2
tells you that the vertex is using position 1 and normal 2. When using arrays of OpenGL indexes, you cannot have separate indexes for positions and normals. So we create a vertex for this position / normal pair and assign the first available index to it. It's the same for 7//2
and 5//2
, so we now have 3 OpenGL vertices (indices 0, 1, and 2).
Now on the second triangle we find again 1//2
. We have already created a vertex for this combination, so we can use our vertex again. 0. 3//2
is new, so we create a new vertex for it (index 3). 7//2
we saw earlier, this is the same as our vertex 1.
So we are done with 4 OpenGL vertices for the first two triangles. This makes sense, since the two triangles describe one face of the cube, and we need 4 vertices for the square.
If you continue this process for the whole example, you end up with 24 vertices that you can store in an OpenGL vertex buffer, and an index buffer with 36 elements (12 triangles with three corners each).
source to share