How does loading geometry work? Concepts/Pro&Cons

Started by
8 comments, last by alexnecro 12 years, 9 months ago
I am currently trying to build my own geometry loader in c++ for games i will make with opengl. I have learned a great deal of c++ and i feel comfortable enough to take a stab at this but i am not fully understanding something. when I find a geometry file format that i like such as 3ds, obj, or some other kind. when creating a parser do I want to have the information that is being parsed to be loaded to memory or do i want to read and run it from the file? so like do i need to turn it into binary and store it or do i create a file from the (obj/3ds/whatever file) and read from that while the program is running with like a stream or something? I hope my question is not to convoluted? please help thanks for your time.

also i might add that I am asking on a beginner area because i have only been studying for about 4 months now and I feel this is a beginner question because it is crucial if one is interested in building their own game engine. I am not asking for code or a tutorial on vectors and buffers I am just interested in the conceptual understanding of this process.How does it work? briefly what are the different approaches and perhaps pros and cons of each of those? I have found very little info on this topic as far as some one describing the concept rather then just showing their version and how it works. I am looking for Pros and Cons of perhaps different methods and approaches to this question. thanks again :)
J-GREEN

Greenpanoply
Advertisement
Youll want to store all the data you need for drawing the file in RAM
So does that mean i need to turn geometry file type into binary then store to memory? and wow thanks for replying so quickly :)
J-GREEN

Greenpanoply
I just realized I might have read your question wrong. Do you have some sort of class/struct for storing the data
ex:

class Model
{
Mesh *meshes;
int numMeshes;
//etc
};
class Mesh
{
float *verts;
float *uvs;
float *norms;
int numVerts;
int *indices;
int numFaces;
};


Basically, are you asking if you should read the whole file into memory and then parse it, or parse it off the disk and store the output in memory?
I would use a class similar to your example yes. and yes Basically, I am asking if I should read the whole file into memory and then parse it, or parse it off the disk and store the output in memory? which of these is the best method? Also what if you have large amounts of geometry is this all loaded into memory? I am just confused on how levels and character geometry work in memory. say i have two levels in a simple game. I don't have geometry for both levels loaded to memory at the same time right? even though some one is only playing one level at a time? wouldn't I have a file holding geometry for levels the levels that are not being played waiting to be loaded to be loaded to memory or do you just load your entire game to memory from the beginning? I hope this is making sense
J-GREEN

Greenpanoply
Youre basically correct about the multiple levels. Unless you had problems with load times, or something, and preloaded the next level in the background or something. Parsing the files from RAM would be faster, but more complicated. I wouldnt bother for a simple game. Many games, however, store their game files in one big data file, or in a zip file or something, for various reasons. If you think it might ever come to that in your game, you should defidently load the file from RAM, since that would enable you to use the same parser with any storage system. There are, of course, libraries that can help you with this too. Im currently converting my code from load from disk using fscanf/fread to reading from memory, and its annoying switching over, but Most likely you wont ever need to store your files in one pack, thats more of a personal preference really. For a small project, youll be just fine loading files from the disk as needed.
To avoid loading entire resource file (mesh,texture, etc) to RAM using one game archive file (such as Quake PAK) you must just construct helper hierarchy: filesystem reader in one side and resource reader in another. and your MeshReader will can parse from your FSDisk, or FSZip, or FSMemory - you just change your filesystem reader reader, saving its interface. You even can use multiple filesystem readers at one time: each request to _your_ fopen() passes throught the pipeline (FSMemory->FSZip->FSDisk) until one of readers find your resource file.
...But there is a problem with built-in helper functions, such as LoadBitmap() and so one - they can't use your modern filesystem helpers and you must load file to the memory buffer of even extract it to the disk
Parsing a file in memory is as easy as parsing a file from disk. Most of the APIs you'll use (D3D for example) allow you to create textures and other resources also from a file in memory. There may not be much of difference in the loading time, but it is nice to think that everything that needs parsing is already in memory and you don't have to worry constantly if there is an error reading the file etc.

I once implemented a virtual file class which could read (or write in some cases) stuff from memory or file on disk or file containing files. So the classes which load things don't need to care where the data is coming from.

Cheers!
this seems like thing I've mentioned above

This topic is closed to new replies.

Advertisement