When I print out the number of vertices in a mesh I get 4096, but the mesh only has 1089 vertices according to blender and that there are 1089 lines in the file starting with "v ". Both loader.LoadedVertices and loader.LoadedMeshes[0].Vertices have 4096 vertices. The loaded mesh works fine with OpenGL using a vertex array. It is hard to think that this would be a bug so here is a part of my code:
objl::Loader loader; bool error = loader.LoadFile(path); if (error == 0) { printf("Failed to load %s\n", path); return; } printf("Vertices.. %d\n", loader.LoadedMeshes[0].Vertices.size());
(I am new to github and I do not know how to make it put line spaces in the code!)
Also I am using the latest version of c++.

As you see here, the continue statement does nothing. All files get named "_2". My solution to this was to write it like this:

Thanks for an otherwise great obj loader :)

There is no support for grouping:

• faces - useful if we want to represent a group of triangles as a larger polygon face in 3d

• vertices - useful if we want to represent a group of vertices as a polyline in 3d.

Grouping is supported by the .obj format. Please see here: http://paulbourke.net/dataformats/obj/

powf requires the math.h header. Currently fails to compile on my system (mingw64 g++ 6.2.0).

I know this is not longer supported.
But this project is kinda nice and easy to use, so ill public this issue.

After playing with 3D models in OpenGL i have noticed the following problem:
Almost the whole model rendered fine, but rims are completely messed up. I have never had this problem before.
I have checked source of this model and found out that exclusively wheels has faces with more then 4 vertices.
I assume this is the issue, because model is rendered fine in other application.

The issue

Outlines

How it supposed to look like

Hi,

i think that the mtl parser doens't parse correctly for the bump map.

as defined on http://paulbourke.net/dataformats/mtl/
the keyword is "bump" and not "map_Bump".

To use the file as a header-only library, I had issues as some of the functions have not been tagged with the inline keyword. These functions include at least the first two functions of the algorithm namespace: vector multiplication overload and inTriangle. Here's a Stack Overflow question about the fact.

Is there any OpenGL GLFW rendering sample that I could learn from ?

Thank you.

Hey,

Is it possible to use more than 1 material per mesh ? I checked the code and it seems that it supports only 1 per mesh, but i could be wrong.

starting with line 269:

			float y = (math::DotV3(math::CrossV3(u, w), n) / math::DotV3(n, n));
			float b = (math::DotV3(math::CrossV3(u, w), n) / math::DotV3(n, n));
			float a = 1 - y - b;

now I'm no Vector specialist but im pretty sure that y and b are the same, which could be achived a little cheaper. :)

Im not actually quite sure what happend here but I think you meant to put v somewhere in there. also note that the division can be cheapend when using pow(Magnitude(n),2) instead of Dot(n,n)

When i'm try to include OBJ_Loader.h in several another h files linker throw:
Error LNK1169 one or more multiply defined symbols found main

It makes me crazy )

When I'm trying to print vertices it rounds them to int.

printf("%.6f\n", curMesh.Vertices[j].Position.Y);

Shows me

Loaded mesh Cube_Cube.0012.076665
-2,000000
-2,000000
2,000000
-2,000000

When I set breakpoint and start debuging it display normal output

Loaded mesh Cube_Cube.0012.076665
-2.076665
-2.076665
2.076665
-2.076665

WTF?? )

In order to allow the Vertecies to be uploaded to the GPU without side-effects directly it would be beneficial to make Vector3 and Vector2 POD types.

eg.: instead of:

struct Vector2
{
[...]
		// Bool Equals Operator Overload
		bool operator==(const Vector2& other) const
		{
			return (this->X == other.X && this->Y == other.Y);
		}
[...]
     float x,y,z;
};

like this:

struct Vector2
{
     float x,y,z;
};

inline bool operator==(const Vector2& lhs,const Vector2& rhs)
{
	return (lhs.X == rhs.X && lhs.Y == rhs.Y);
}

Although a little more complicated, it allows the compiler to more efficiently pack the data and thus one could directly generate vertexArrays by using offsetof()

This has been the best OBJ loader for me because of the simple and easy to use API, but during tests I realized non-triangulated OBJs, for example McGuire's version of Cornell Box, force the program to close inside the 'LoadFile' function, unless I'm doing something wrong. After I converted the model to triangles through Blender, it loaded perfectly fine.

No matter whether the 3D model is obj or not, there will be repeated redundant fragments and other data, which is inevitable. If you do not make exception handling judgment and so on, this load loader cannot be universal!



I'm going to give you a simple data model, and there are others.

lamp.zip