Is loading other types of exported formats (like .OBJ files) more efficient/faster than the outdated .X file format?

If you're staying with DX9 - no. DX9 has routines for loading the X file format specifically. It's unlikely you would be able to parse and load data faster than the built-in support.

Are .X files slower to load or do not hold as much useful information as other export types?

With respect to speed, see the previous answer. With regard to "useful" information, the X file format is probably as flexible as you need due to the implementation of templates.

Is the "ASSIMP" library the best option?

See the previous answers. If you're going to stay with loading models during run-time in DX9, stick with the built-in D3DXLoadMesh*** functions, and binary (not text) format X-files. I've not tried it specifically myself but you might want to see if D3DXLoad...InMemory functions are a bit faster than the "from-file" forms of those functions.

However..

The "best" option overall would be to create binary files which can be loaded directly into the vertex and index buffers of ID3DXMesh (via LockVertexBuffer and LockIndexBuffer). That is, you would code a separate application (probably using the Assimp library) designed specifically for importing various formats, parsing the data, and exporting those specific binary files. The advantage of that approach is:

1. you can import various formats using Assimp.

2. Assimp presents all the imported data in an aiScene structure, so you only have to write code to extract data from only assimp's structure.

3. By creating binary files to be loaded directly into DX9 native meshes, your game app doesn't have to support file parsing (either by you through assimp, or through the D3DXLoadMesh*** functions. You create a mesh of the appropriate size and FVF vertex type, lock the vertex/index buffers and stuff them directly with binary data.

EDIT: With regard to calling X-files "outdated," you're using DX9 which was deprecated years ago!

EDIT: With regard to calling X-files "outdated," you're using DX9 which was deprecated years ago!

Hehe yes I know, however I don't want/need to update right now.

So it seems that using .x files for now do not have as large of an impact as I thought they may have. Aside from what you suggested about loading data directly into memory with the InMemory() functions, it does not really seem that the time it would take to upgrade my code would not really be worth it at this time if I understand you correctly. And I do not wish to get into concepts like loading directly into the vertex buffers until I wish to really to some serious upgrading of my mesh and animation system.

Hi. A can't see anything wrong with the .x file there not slow

Ok thanks, good to know! That helps a lot.

So I am thinking of a slightly different direction to improve the performance of resource loading in my game. Simply put, some assets in the game "lock up" the game for up to several seconds while they load in the mesh/textures and set them up to render, as is usual.

Since the way I have the game set up most of the time I do not need the resource loaded "immediately". So, would I be able to put all my mesh/texture resource loading code into a thread and let it process on the background until it is ready?

Will the game run smoothly for the most part while resources are being loaded?

Will file access while loading resources in a thread also work in the background and not "lock up" the main game thread? Or do I need to look into something more involved like Overlapped I/O or asynchronous loading?

A background loading thread can be a good idea, it has worked well for me in the past with DX9.

You should block entry into the game until all objects within the player's immediate field of vision (basically a circle of a certain radius around the players (x,y,z) position) have been loaded. After that, simply load the other objects in the background thread as the player's position moves. If you do it right they won't notice objects "popping" into view when they run forward or rotate their view. This is all assuming your game is a first/third-person open world exploration, other cameras require other approaches.

Brush up on Windows synchronization primitives so that your 2nd thread doesn't data conflict with the main thread and vice versa, also you can only render from the thread you created the graphics device on.

Thanks, I have actually been attempting that approach. Synchronizing with a D3D Device seems to be a bit more tricky than I was expecting however, but at some point I plan to implement this further.

For now I found two simple ways to fix my loading lag issues. One was the fact that I was using a lot of text-based .X files and reading those files. I now compress them into compressed binary files, which actually has been lowering the file size to more than 1/10 its size! This has had a huge impact, as well as using InMemory() load functions to top it off.

I also "Sectioned" out my loading code so not all the processing of loading a mesh is done in one frame, instead it is spread out into many frames (loading 1 texture per frame etc. )

Some simple implementations of course. But that with threading, or splitting up the loading of the file will be something I look forward to finally implementing.

A background loading thread can be a good idea, it has worked well for me in the past with DX9.

Were you able to thread functions that use the D3D Device as well? Like threading a LoadMeshFromX() function that uses the D3D Device parameter? I attempted to thread my mesh loading but it seems it is a bit more complex getting the D3D Device into a thread. It locks up my game when it gets used. Apparently I may need to be using "Critical Sections" but my knowledge on such things are limited.