C++ OBJ Loader Fstream Issue

Question

I'm currently trying to create my own OBJLoader using Fstream to load and search through the OBJ file to read the vertices and such. This is what I've got So far (It's not finished yet)

Mesh* OBJLoader::LoadModel(char* path)
{
    Mesh* mesh = new Mesh(); //New Mesh

    std::vector<Vector3> vertices;
    std::vector<TexCoord> textureCoords;
    std::vector<Vector3> normals;


    //Loads OBJ file from path
    std::ifstream file;
    file.open(path);
    if (!file.good())
    {
        std::cout << "Can't open texture file " << path << std::endl;
        return nullptr;
    }

    std::string line;
    while (std::getline(file, line))
    {
        std::string text;

        file >> text;
        if (text == "v")
        {
            Vector3 vertex;

            file >> vertex.X;
            file >> vertex.Y;
            file >> vertex.Z;

            vertices.push_back(vertex);
            //std::cout << vertex.Z << std::endl;
        }

        file >> text;
        if (text == "vt")
        {
            TexCoord texCoord;

            file >> texCoord.u;
            file >> texCoord.v;
            textureCoords.push_back(texCoord);
         }
    }

return nullptr;
}

It seemed like it worked at first, I tested it by printing out the values to see if they match the values in the OBJ file and it seems... most don't and I'm not sure why.

I'm putting these vertices I get from the OBJ file in a vertices vector so I tested this loader by printing out the vertices vector to compare the values, this is what I got:

These are the last couple of vertices and should match the last couple of Vertices I have in the OBJ File:

As you can likely see, the values don't exactly match. Some values are missing a single number off the end while some display something completely different like "-3E-06". Does anyone know why this is happening and how I can fix it since it almost works perfectly.

This is also the code I'm using to print out the vertices which is within the function above if you wanted to know:

for (int i = 0; i < vertices.size(); i++)
{
    std::cout << vertices[i].X << " " << vertices[i].Y << " " << 
    vertices[i].Z << std::endl;
}

EDIT I've noticed that simply pritning out the Vertices using file >> instead of putting them into the vertices vector and then printing them out results in the correct value being printed out. It seems when I put the values into the vertices vector, it changes them slightly. I tested printing out just the first X vertex of the OBJ file after I had put it into "vertex.X" which outputted "-2.97217" while the value should of been "-2.972168". It strangely seems like it's rounding the last two numbers or something Though it only seems to do it for the X and Y vertices and not the Z.

What's up with those `file >> text` calls? You're already calling `std::getline()`. You can use `std::stringstream` to further parse each line, [example](https://stackoverflow.com/a/14887071/44729). — genpfault, Mar 12 '18 at 17:29
That's what rafix07 said though it still gives the same problems — codelyoko373, Mar 12 '18 at 17:34

score 1 · Answer 1 · answered Mar 12 '18 at 06:57

1

The issue is you call 2 times

file >> text;

this line should be called only once.

Another issue is that in your while loop you are calling

getline(file,line)

so content of a line was read into line variable but you don't parse line string to extract data from this line of OBJ file.

I think you should read line by getline(file,line) then you create istringstream object and you can parse data, so modified code should look as follows

    std::string line;
    while (std::getline(file, line)) {
      std::string text;
      std::istringstream iss(line);

      iss >> text;
      if (text == "v") {
        Vector3 vertex;
        iss >> vertex.X;
        iss >> vertex.Y;
        iss >> vertex.Z;
        vertices.push_back(vertex);
      }

      if (text == "vt") {
        TexCoord texCoord;
        iss >> texCoord.u;
        iss >> texCoord.v;
        textureCoords.push_back(texCoord);
       }
  }

answered Mar 12 '18 at 06:57

rafix07

20,001
3
20
33

https://i.imgur.com/Qvwsuqz.png Well I did what you said though it's still giving out the exact same problems like the last number of each vertex being missed and the strange values returned like "-3E-06" – codelyoko373 Mar 12 '18 at 13:06
You should edit your question, with current code and paste lines where you are printing x,y and z coordinates. – rafix07 Mar 12 '18 at 13:22
My code hasn't changed, that code shown in the question is my current code and I've added the code that prints out the vertices. – codelyoko373 Mar 12 '18 at 14:19
I've made another Edit to my question to give a little more info – codelyoko373 Mar 12 '18 at 17:25
GLfloat has limited precision, you can use GLdouble instead of GLfloat, change it and see what output you will get. – rafix07 Mar 12 '18 at 19:29
I tested it with GlDouble and it sadly outputs the same wrong number – codelyoko373 Mar 12 '18 at 19:55
I believe your data is read correctly, problem is with printing values, add `` header to your includes, and call `std::cout << setprecision(10) << vertices[i].X << " " << vertices[i].Y << " " << vertices[i].Z << std::endl;` – rafix07 Mar 12 '18 at 20:35
It seems you're right :) Doing that with a single vertex works though not if I print out all the Vertices since it seems each Vertex has a different precision number so sometimes they return weird numbers like this: https://i.imgur.com/RrK4txM.png When it's meant to be this: https://i.imgur.com/TvqFo1A.png Like you see how some numbers print out stuff like "-4e-06", I'm guessing that's cause of the precision? or simply cause of cout? – codelyoko373 Mar 12 '18 at 21:10
Well turns out that I'm actually an idiot XD. It turns out I was using the wrong object the entire time, and what I was simply doing was trying to load in a .txt file as a OBJ file which is why it was giving the strange values. So now it... sort of works: https://i.imgur.com/dCkgYP8.png – codelyoko373 Mar 13 '18 at 03:20

C++ OBJ Loader Fstream Issue

1 Answers1