Efficiency in Model Loading.

Ok, im writting an OBJ model loader and im trying to make it as efficient as i possibly can. Anyway, what should i do when i dont know how many verteces or whatever there are in the model.
I can do:
use a linked list for teh verteces therefore avoiding the issue of not knowing how many verteces there are

Read the entire file twice, the first time to find out how many verteces there are and the second time with a dynamically allocated array loading the verteces. But this will take a while reading a file twice.

and preallocating a specific amount of space for the verteces but then i will either have too much memory alocated or too little (which causes erro) and yeh, this will be a waste of memory.

What is the most efficient way, and is there anothjer more efficient way?

Don’t OBJ files have a vertex count specifier somewhere in there?

Anyway, if they don’t then this is what I’d do (pseudocode):

  • Open File
  • Get File Size (skip to the end and ftell)
  • Allocate memory for entire file
  • fread() the whole file into that memory (in one call)
  • Skip through the vertex sets (in that buffer you just read in) until you get to the end, incrementing a counter each time (this gives you the number of verts)
  • Allocate appropriate memory for the vertices
  • Copy them out of the file buffer into this new buffer (you will probably not be able to memcpy, it’s more likely you’ll need to do some manual comversion)
  • Done, you have your verts

You may have to put some effort in to make sure that you can read everything properly given that .obj files are text and you’ve opened them as binary, and you’ve got to manually parse that read buffer, but that’ll give you efficiency (you only make one file call, you only allocate memory twice, not in many small chunks, etc.)


Hmmm, ok then, thats basically the reading the file twice method… I suppose it wouldnt matter coz it would be done at load time and not real time runtime, so yeh… I suppose linked lists would be too slow to traverse for vertex data and we dont want to be wasting memory do we? Thanks for your reply.

Well, you aren’t really reading the file twice… you just have to skip through it’s buffer the first time, there’s no real interpretation needed.
But yeah, load time is when it should be done (as with most file accesses).

Linked lists are not good for vertex data because you have to hop around in memory for them and you can’t use them in GL’s vertex arrays.


Just a little note about the file reading part…
I think it would be better to use something like that:

hFile = _open(strFileName, _O_RDONLY | _O_BINARY);

if (hFile == -1)
char strMessage[127] = {0};
sprintf(strMessage, “Unable to open the file: %s!”, strFileName);
MessageBox(NULL, strMessage, “Error”, MB_ICONERROR);

FileSize = _lseek(hFile, 0, SEEK_END); // We Get The File Size
_lseek(hFile, 0, SEEK_SET); // We Go Back To The Beginning
VirtualFile = new unsigned char [FileSize]; // We Alloc Memory
_read(hFile, VirtualFile, FileSize); // We Read All The File
_close(hFile); // We Close The File

I am not sure but I think those low level functions are faster when you want to copy a big amount of datas in memory…

But those file calls are platform specific.


[This message has been edited by Mezz (edited 07-25-2002).]

Nevertheless,it’s in the ANSI C.



When are you loading your models? On scene changes? Or on the fly when they get within the culling boundaries? If you aren’t loading them on the fly, you might was well read the file in twice. If you need to have a high frame rate while loading models, try something more complicated like the above suggestion.

Mezz -> Have a look in the book of Kernighan and Ritchie… They speak about it,of course at the UNIX chapter,but they say "Since the ANSI C library is in many cases modeled on UNIX facilities, this code may help your understanding of the library as well. "


[This message has been edited by ndj55 (edited 07-26-2002).]

I completely accept that read() and write()etc. are ANSI complient.

Just not _read() and _write() etc.


oups sorry…

I was busy thinking “is there something I’m missing here…?”



if you develop for Win32 there is something as called filemapping. Using some Win32 API calls there you can access a file on HD just by accessing a pointer. So Win32 will assure that the corresponding part of the file will be loaded when accessing. Search the MSDN for further details.


No, i hate windows and M$. I use it only for necessity, and all of my programs are fully portable (GLUT and I try not to use Vid card specific extentions)… Ill try out several of you suggestions see what is best.