Right this moment(well not this moment) I am writing a 3d model loader interface for my engine. The current one i am using is made directly for 3ds files. But this new one i am designing will be independant of the file type you are using, 3DS, milkshake(shape?), ect. You will be able to load objects with a simple MLOADER->load("town.3ds") or MLOADER->load("town.ms3d") without addressing individual functions like load3ds or loadms3d ect. Each model loading class will register its extension with MLOADER and when called will call the right loader based on file extension. If no loader is fount returns error. Loaders will register objects, cameras, lights, etc. with the different managers CAMERAMAN, OBJECTMAN, LIGHTMAN, so on. Is that enough? or is more control over objects needed. Later I would probably add in a search and load. Tell me what you think.

Over the past year I've developed a similar system in various incarnations. Its main purpose is to abstract resource loading and make it as flexible as possible. Its a somewhat complicated system and I don't have time to go over it now, but maybe I'll go into detail if this thread is still around in a couple days. Anyway, I would encourage you to go for it. Its a good idea to avoid locking yourself into specific file formats. You can even go to the point of abstracting archive formats, encryption, and compression, making them invisible to the rest of your program. I use a path to identify resources, separating each level by a slash, similar to a file-system. Archives and individual resources are treated the same, and both can return loaders for multiple contained resources depending on the file format. This way I can store resources recursively, enabling me to load, for example, a win32 bitmap from a zip file inside a unix tar archive. I avoid using the file extension to specify file format, instead examining the internal representation of the data to determine its format. Although this could potentially lead to incorrectly identified file formats, I handle errors very carefully, ensuring that the resource is not loaded unless everything is accurate. The benefit is that you can refer to a resource without knowing its extension (specific format), only based on its general resource type (image, mesh, etc).

Hopefully the above wasn't too disjointed. I'm sure there are other, possibly better, approaches. I'll try to write some more detailed information in a couple days.

I did something like that too. Only i did mine extension independant.

Its a very useful feature, since what i did, is first i looked at the file being loaded, saw whether it had a familiar extension. If it did, i would try to load it. If it didnt load, or had an unknown extension, i would check it's header tag, and look at the similar/compatible header tags in the list of compatible model types. That way you allow user for even more flexibility.

Good luck!
Tim

if this is meant to be in a game-type engine, don't do anything except storing binary dumps of vertex- and indexbuffers. don't preprocess the data in anyway, except from MAYBE doing some simple data-packing (like storing normals as 3 bytes etc)... this will keep the loading-times down. just design your own format with as little runtime processnig-overhead as possible, and make a converter/exporter for it. this simplify the engine-code (no need for "flexible" loading-systems etc) aswell as decreasing the chances for runtime-bugs.

ofcourse, if you're writing some sort of 3d-model-converter or -tool of some sorts, having multiple-format-support is a way more sensefull thing. ;)

Maybe check out the IO system of OpenMesh.
I think it's well done. www.openmesh.org

Christian

I myself am doing the same code right now... maybe a bit different.

My sound, script, model loader ect: managers register functions with the Resource Manager which load data of specific type...

Resource Manager nows nothing about what it is loading. This means a clean interface. My resource managers main responsibility is to FIND the resource... currently it can look at the exact path, local directory, and in my custom pack files... ( no .zips yet ) It then calls the registered function. This function creates the games objects from the resource data.

Example:
sound_manager.create_sound_obj( "test.wav" );
// resource manager is called...
// it locates file ( whereever it might be ) and returns file* to start
// it then calls registered function matching type, passing it the file*
// this function creates the obj.

I am making custom formats for resources as I go along as the previous poster mentioned... this cuts down alot of loading... I do quite a bit of processing to .obj files. ( I want to avoid all this extra processing in the game. )

The main reason i choose this interface is I will be using same resource manager in all my tools. Code reuse at work! As the game engine becomes complete and my custom formats solidify, I will be removing all the various types ( except the custom formats...) leaving a fast clean, and easy to use resource loader. The functions removed just make thier way to my convertion utility and game content creation tools... ( probably where they should have originated! ) Definitly go with your approach. It's not all that much extra work...


-lordcontrary.

While thinking over things said and testing new code i written i had a idea to make a plugin system. Should I make it an all inclusive loader, You know loading model plugins and engine plugins(Handling anything pluggable). The system will come with my model formats built in and if you want to add other file types (3ds lwo obj ect.) just add a dll in the plugins folder. What do you think? Even further make a base 3d engine with standard features (base 3d engine) then add plugins crutial to the game you are creating. You could use the same engine for games that are totally different leaving out features you dont use. Would this kind of setup be slow??

independent

Thanks for the spelling lesson

me no no right speak way

I have been having problems with dll's, when i try to load more than 1 at a time the second one fails to load unless i free the first one. Am i doing something wrong or does windows have this limitation?