0

I wrote a obj loader. It's very simple but I'm sure it works. I checked values in file and the ones printed by the loader and they match. Problem occurs when I try to load a big obj file like stanford dragon or Bunny. Utah teapot (3664 verts) works perfectly fine, however dragon (50k verts) is rendered horribly wrong:

Renders

As You can see something is wrong with the dragon. It seems like only part of triangles is being rendered.

P.S. All models have been triangulated.

Mesh loading:

void Mesh::load(float* buffer, unsigned int size, char fields, char target) {
        unsigned int vbo;
        glGenBuffers(1, &vbo);

        glBindVertexArray(vao);
        glBindBuffer(GL_ARRAY_BUFFER, vbo);
        glVertexAttribPointer(target, fields, GL_FLOAT, false, sizeof(float) * fields, 0);
        glBufferData(GL_ARRAY_BUFFER, size, buffer, GL_STATIC_DRAW);
        glBindBuffer(GL_ARRAY_BUFFER, 0);
        glBindVertexArray(0);

        vbos[target] = vbo;
    }

    void Mesh::loadIndices(void* buffer, unsigned int size) {
        glGenBuffers(1, &ibo);

        glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, ibo);
        glBufferData(GL_ELEMENT_ARRAY_BUFFER, size, buffer, GL_STATIC_DRAW);
        glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);
    }

and mesh:

mesh = new Mesh();
    mesh->numIndices = indices.size();
    mesh->load(positions, pos.size() * sizeof(float), 3, MESH_TARGET_POS);
    mesh->loadIndices(ind, indices.size() * sizeof(unsigned int));

indices and pos are std::vectors, positions and ind are just content of those vectors copied into heap allocated memory (just in case it'd change something but no, it didn't change anything). load method takes in pointer to data, size in bytes, fields in vector (3d vector - 3 fields, 2d vector - 2 fields) and lastly an integer that tells which attribute is this data (MESH_TARGET_POS - attribute 1, vertex positions).

That code has nothing to do (I believe) with the problem. Every model that's less than 10k vertices works fine, even the dragon in lower polycount works great.

genpfault
  • 51,148
  • 11
  • 85
  • 139
GPlayer
  • 131
  • 1
  • 7
  • @Rabbid76 is it enough? I really have no idea what code should I include. – GPlayer Dec 29 '18 at 09:49
  • 4
    @GPlayer what datatype you use for element buffer? and what is the point count in the wrong mesh? my bet is you got 16bit signed integer and more than 32768 points ... Also hope you are handling the elements properly (in obj the first point is index `1` but in OpenGL `0` ) my C++ parser has no problem with 100K+ face models (other than speed) see [How do I sort the texture positions based on the texture indices given in a Wavefront (.obj) file?](https://stackoverflow.com/a/51722009/2521214) To verify save your loaded OBJ back as a file and compare with original one to rule out parsing error – Spektre Dec 29 '18 at 11:11
  • 1
    @GPlayer also check for statically allocated array sizes along the way ... – Spektre Dec 29 '18 at 11:15
  • 5
    Oh my god. How stupid Am I? Yeah... indices count was unsigned short... Thank you for suggestion! Such a stupid mistake. Thanks again! – GPlayer Dec 29 '18 at 11:38
  • It happens to best of us time to time ... btw how long it loads your dragon ? (I am just curious) ... – Spektre Dec 29 '18 at 12:39
  • 1
    @Spektre sfrl, I've usually spent 4 seconds loading it, including generating vertex normals from face normals, fixing uvs and all that stuff, but I've been using file returned by fopen (scanf and all those stuff, sorry for being inprecise). It was cool for me but it was pretty limited and to support more than 3 verts per face I would need to add bunch of if-statements so I wrote a code that let's me split null terminator string to extract individual parameters. Now it's about 3 sec. – GPlayer Jan 08 '19 at 15:27
  • 1
    Yep that are comparable times to mine: yours `~3sec/50K` and mine `3.7/100K` and yes mine times also include the VBO stuff too... – Spektre Jan 08 '19 at 18:03

0 Answers0