Wanting to Load Bezier Patches Internally rather than Externally

Hello,

Since I’m a new member, apparently I am only allowed one attached image, and no links like the one I was going to include to my Google Drive, so this is going to be a lot more challenging than I thought.

I have an OpenGL in C++ tree traversal program that loads a teapot, a teacup, and a teaspoon through the use of Bezier patches and vertices. This method of reading in the data from these .patches and .vertices files is not something I am wanting to do any longer. The biggest reason is that the compiled .exe file still requires those files in the same folder in order to run. What I want to do, and am already very very close to accomplishing, is simply storing the patch and vertice data inside of individual header files and then simply reference the header files at the top of the program. Should be easy, and for the most part it technically works! For whatever reason, when I toggle from the main screen to the wireframe, the wireframe is stretching the vertice points at the teapot, the teacup and the teaspoon and I have no idea why. Please see the following image that I’ve attached:
72d8d137dab64f2a889df54a797f4686.Stretched_vertice-points
Again, for whatever reason, everything else works fine in the normal scene, it’s just when I toggle wireframe mode that it stretches the points of the three objects. This has me wondering if there’s something wrong with the wireframe portion of the code, but I cannot figure out what it is. Here’s my function for reading in the data externally from the files:

void readData(char* pointfile, char* patchfile, patch* myarr) {
  ifstream points(pointfile);
  ifstream patches(patchfile);
  if(!points.is_open() || !patches.is_open()) {
     cerr << "Failed to open file. Press enter to quit:";
     char throwaway[2];
     cin.getline(throwaway, 1);
     exit(1);
  }
  
  int numpoints, numpatches;
  points >> numpoints;
  patches >> numpatches;
  GLfloat tp[numpoints][3];
  for(int i = 0; i < numpoints; i++) {
     for(int j = 0; j < 3; j++) {
        points >> tp[i][j];
     }
     if(points.rdstate()) {
        cerr << "Failure reading " << pointfile << ". Press enter to quit: ";
        char throwaway[2];
        cin.getline(throwaway, 1);
        exit(1);
     }
  }
  int tempint;
  for(int i = 0; i < numpatches; i++) {
     for(int j = 0; j < 4; j++) {
        for(int k = 0; k < 4; k++) {
           patches >> tempint;
           for(int l = 0; l < 3; l++) {
              myarr[i][j][k][l] = tp[tempint - 1][l];
           }
        }
     }
  }
  if(points.rdstate()) {
     cerr << "Failure reading " << pointfile << ". Press enter to quit:";
     char throwaway[2];
     cin.getline(throwaway, 1);
     exit(1);
  }
}

and then the node traversal portion of the program reads in the teapot data like this:

teapot_node.f = teapot;
teapot_node.child = NULL;
teapot_node.sibling = &teacup_node;
readData("teapot.vertices", "teapot.patches", teapot_data);

That’s the version that works perfectly, but is reading in the files from a required external file, which is not what I want anymore. I need to be able to read everything internally from a header file.

Ergo, this is my preferred way of reading in the data internally from a header file but is stretching the vertice/patch data:

void loadTeapotData(GLfloat myarr[32][4][4][3]) {
   int numpatches = 32;
   for (int i = 0; i < numpatches; i++) {
       for (int j = 0; j < 4; j++) {
           for (int k = 0; k < 4; k++) {
               int index = teapot_patches[i][j * 4 + k]; 
               for (int l = 0; l < 3; l++) {
                   myarr[i][j][k][l] = teapot_vertices[index][l];
               }
           }
       }
   }
}

and then the node section again, only the last line being altered:

teapot_node.f = teapot;
teapot_node.child = NULL;
teapot_node.sibling = &teacup_node;
loadTeapotData(teapot_data); 

and then I initialize the teapot in my main function:

loadTeapotData(teapot_data);

and the vertice and patch data is referenced within my header file which I include at the top for each drawn object:

#include "teapot_data.h"

I’ve removed my Google Drive link to my Bezier .patches & .vertices files along with my header file for the Teapot since I’m not allowed to post links. Please let me know what you think based on the info I’ve been allowed to provide. Thanks!

I’ve not looked in detail at the two ways you are processing the data, but from your description the arrays of GLfloat you end up after loading should be the same (whether you load from an external file or the values baked into the executable). Have you compared the two to see where they differ? I suspect the difference will be at the start or end of the data and you probably read one “line” of data too much/too little or something along those lines.
Once you’ve located where the difference is you can hopefully narrow it further down in a debugger by stepping through the corresponding parts of the loops.

Thanks for your swift reply! I have compared the two, and I cannot find a distinction or issue between them. I really wish I could be allowed to post my Google Drive link because my header file that I’m referencing is in that file and it’s possible that I created an oversight or other issue related to that file, but you’re not going to want to see that code posted here. It’s Bezier data so I don’t think that requires any further context as to what it will look like in a forum post. Everything else works fine though, I just cannot understand what the problem is. No issues in the debugging console, no warnings, no errors, nothing. I have worked on this for so long and if there is anything else in my programming career that has been both close to a solution, yet simultaneously far enough away that I cannot see it, this is it.

I’ve ruled out how anything is drawn in the rest of the program, because all of that is working perfectly fine when I read it the .patches and .vertices files. I need a Bezier expert who’s worked intimately close with patches and vertice data.

This is not a problem with the mathematical concept of Bezier patches. This is a problem in your code’s implementation of that concept. The places that you decided are “working perfectly fine” are the first places I would look. There are innumerable places that it could be hiding, and the only way to find them would be to sit down and go through the entire code, sometimes line-by-line, to see where the problem is.

If you genuinely have looked at every byte of data that you upload to the GPU and see that it is exactly what you expect, then look at your drawing command. Are you drawing the byte ranges that you mean to? Are your indices correct, or are you indexing the buffer out of range? Stuff like that.

We can’t do this remotely based on a few code snippets. You’re going to have to sit down and do the work, with no assumptions of what code is “working perfectly fine”.

Wow, what a great way to push people away by demonstrating your social handicap! Notice how Carsten at least responded respectfully, so he got a respectful response. How easy that was for he and I to pull that off, what a thought!

I never said the problem wasn’t with my implementation…that’s exactly why I’m here because I know there’s a problem in my code. Not sure why you would make such a comment like that. This didn’t help anything.

Blockquote

Yeah…again, that’s what I’ve done and that’s exactly what I’m continuing to do. Again, it’s the fact that I’m exploring all areas and ruling out the areas that are definitely not the issue. Did you forget that I mentioned that EVERYTHING in the code does in fact work as long as I load it externally from the files. Reading comprehension issues?

Yeah, exactly, AS I MENTIONED ABOVE, I wanted to provide more, but I was restrained by Khronos system from doing so since I am a new member. I really don’t know if you’re skipping over reading, and only seeing what you want, but your disorders are not my problem. You have a horrible negative attitude. You’re the kind of people that ruin the image of how people view forums. Way to keep those stereotypes going there little Reinheart!

Cody AI. For all your coding needs when stuck on a project that I worked hard to build. Go AI! Forums are going to slowly dissolve.

I love how your community has the hypocrisy to shovel out rude comments, but can’t handle it when I respond in a similar direct manner, and then proceed to cover up my comments, but not the unprofessional ones left by the one who began the antagonizing. Again, Cody AI resolved this for me and you did nothing to help the situation at all with your negative attitude. AI has replaced you!