File Loading Module

Started by
3 comments, last by Tispe 10 years, 10 months ago

Hey guys,

I've been thinking over a problem today and I wanted to have some input from you lot! :D

I have a DX11 engine I'm building up and I need a system where I can load in different model types, .obj, .md5 that sorta thing. But I can't seem to come up with a way to decouple the file loading from the data itself.

I thought I'd start here because you have much more experience than me :P

3oaP1BJ.png

This is the general Idea I have in my head. Using FileLoadingManager as a singleton and IFileImporter as an interface.

How would you do it? Design limitations?

This is a learning exercise for me so throw books, examples and whatever else you want at me too :D

Many Thanks.

Advertisement

I think the main problem with this design is the genericness of the FileLoadingManager. If you rename this class to MeshLoadingManager, things will be more logical, and also the return types of various loading functions in the class is alot easier to comprehend (i.e. the LoadFile method returns an object of type IMesh).

You will then need different types of LoadingManagers for each type of object you want to load (i.e. Mesh, Sound, Texture, etc). You can then make a generic FileLoadingManager that contains a MeshLoadingManager, SoundLoadingManager, TextureLoadingManager and so on, with a file extension map to the different types of loading managers.

I would also rename the classes to FileLoader, MeshLoader and I wouldn't make them a singleton.

Hopefully you can adjust your design based on the above.

btower, on 22 May 2013 - 23:34, said:
I wouldn't make them a singleton.

Quoted for emphasis.

In any case, an engine should typically only support one file format and that format is a custom format.
If you want to support multiple formats, such as MD5, OBJ, FBX, etc., you would make a converter from those formats into your own format. These converters would also each be separate utilities, not one monolithic utility that converts just anything to your own format.


L. Spiro

I restore Nintendo 64 video-game OST’s into HD! https://www.youtube.com/channel/UCCtX_wedtZ5BoyQBXEhnVZw/playlists?view=1&sort=lad&flow=grid

But I can't seem to come up with a way to decouple the file loading from the data itself.

What an odd statement. What does "decoupling the file loading from the data itself" actually buy you? What does it even mean? Are you suggesting you should write your own generic ifstream/FILE routines? What improvements would you add to the standard runtime ones? Endian flipping for loading cross platforms?

And why are you making an engine from scratch? Are you trying to accomplish a specific goal? If so, just code towards that goal and write little one-off resource loader routines as you need them.

In my project, the loading module is a class that encapsulates creating and communicating with a new thread. I pass the 'this' of the loading module to the thread so that the thread has access to memebers.

6 mutexes to control 6 vectors that contain "data packets (pointer to struct)", for bi-directional asynchronous communication to the thread. Rx/Tx for client side, Rx/Tx between, and Rx/Tx for the thread.

The client (calling code) can at any time push a data packet to the Tx vector and at any time pop a packet on the Rx vector. Each frame I "tick()" the class to move data between the cleint vectors and the between vectors. I only "tryEnter" on mutexes on client side to avoid blocking.

The thread has a main loop which ticks data to and from the thread vectors and the between vectors. We can block here so I use EnterCriticalSection.

The thread then uses OverlappedIO asynchronous file loading. It controls all of the loading progress. Once a load is complete is takes the file to a processing function. Once processed it is encapsulated and sent to the client.

This topic is closed to new replies.

Advertisement