Thread: What's an acceptable file to store mesh data on?

Hi!

Been having hell with mesh file conversion! Decided in the end to just export all the raw data regarding mesh and animation frames etc... directly out of the modelling programs using the scripting console within it.

It means I can load the mesh data as and when I choose from a raw format and update it's position using my own code and then send it to DirectX.

But I'd like to know the most sensible choice of file to store this in. I need obviously to load a copy of the data into dynamic memory where I can then change its variables depending upon its position.

BUT ;o) What's an acceptable file type to store this data that allows very fast access to the data. I'm getting there with C++ but I am a newbie when it comes to understanding things like for example how fast can a .dll be accessed in comparison to say just a good old .txt file?

Given I'm real time rendering it needs to be very fast. I could even I suppose store it in a .h header file.

I'm pretty stumped here, can anyone recommend anything? Thanks ;o)

Reading from a file is reading from a file. Your program has to take data from the hard disk and put it into memory. This is why many games have load times. They are putting all of the relevant files into memory so there is no slowdown while you are in-game playing.

There would be no difference between a .h and .txt file. They are both ASCII files. The dll would be binary. This is irrelevant because you are concerned with disk access speed, not file type.

That's great thanks. So it doesn't really make any difference as they all end up living in memory anyway once the game's commenced.

I am worried about too many models being loaded into memory though. It would be nice to be able to access one at run-time for say a model that isn't normally seen such as a jet flying over an infantry group from the infantry's perspective.

Would a .dll help with this at all or am I just barking up the wrong tree? I don't really want to load everything relevant to the game at the start. Some of the environments will be massive and will have to be accessed at run-time.

What do you think mate?

No, a .dll has nothing to do with that at all.

Most games can't load everything into memory. This is why there is a load time between levels, etc. It's up to you how you want to cut the cake.

Some engines can stream assets into the game depending on player location. So they will dynamically, asynchronously load in more assets as the player is playing to give the feel of a huge, streaming world.

Ok thanks! So basically I can put it in any file type I like but to take care of memory I just need to make old fashioned careful use of the new and delete functions ;o) Thanks ;o)

Well, yes, you have to manage your news and deletes as usual, but you need to pay attention to how much memory you are allocating for your assets in total. If you have a 2GB model and load that in memory, you might find your computer not running so well.

Sure thing. Resource management is everything so I hear in games whether you can write good code or not doesn't mean anything unless you handle your resources properly. Not just I hear a simple matter of chucking everything into memory at the start and consulting when needed.

Thanks for the help pal. Two last questions if you or anyone else will:

1) Is all this stuff loaded into RAM so the game can get to it quickly? If so I would obviously need a target RAM size for users to have and make absolutely sure I never hit anything over that or presumably they'll hit the hard drive and freeze for a few frames, maybe at a critical point like flying close to the ground.

2) Given a .dll is in binary would it make it any faster to load when required? I'm getting ok with code but I sense I'm showing my general limitations in computer science here. Surely a binary file will go quicker than an ASCII text file?

Thanks again ;o)

Originally Posted by shrink_tubing

1) Is all this stuff loaded into RAM so the game can get to it quickly? If so I would obviously need a target RAM size for users to have and make absolutely sure I never hit anything over that or presumably they'll hit the hard drive and freeze for a few frames, maybe at a critical point like flying close to the ground.

Yes, everything is loaded into RAM so access times are much, much quicker. That is why games give minimum RAM requirements. Otherwise, Windows is forced to write data that is supposed to be stored in RAM to a paging file, which is on the hard disk. As you can imagine, this causes tremendous slow down.

Originally Posted by shrink_tubing

2) Given a .dll is in binary would it make it any faster to load when required? I'm getting ok with code but I sense I'm showing my general limitations in computer science here. Surely a binary file will go quicker than an ASCII text file?

You should get the concept of .dll files out of your head. A dll file is a Windows shared library. It is compiled code that can be used by your program by executing functions inside. Forget about the whole .dll thing. It's not what you want. What you want to know is if binary files are faster to access than text files. Any file can be binary and if you do decide to make your own file type to store data, do NOT call it dll because it's already a standard extension.

I should mention that a file's extension only has bearing with the OS. The OS can associate file types with programs. This allows you to open files by double clicking on them. Underneath, though, the file remains unchanged regardless what extension you want to name it. You can rename text.txt to text.dll but that will still be a text file.

To answer your question, binary will be faster because there is no interpretation of the data being read. However, this will likely be insignificant except for extremely large files. You will most likely be reading the file in by chunks if it is that large, anyway.

Originally Posted by syzygy

You should get the concept of .dll files out of your head.

Done ;o)

Thanks another really good post sir! (or madam!). I guess I need to stop worrying too much about file type being read and more about just making sure what's being loaded is being done properly so as only to request what's needed.

Thanks for helping me out ;O)

You're welcome. Yes, you should just focus on getting the data into a file and then back out of a file in a usable form. Once your are there, then you can focus on optimization.