I'm writing an engine with DirectX and C++ but I need to find a way of loading an obj or 3ds file so I can fill the vertex and index buffers for rendering. All I can find on the internet is for OpenGL and are generally geared towards prebuilt engines or DXUT. Can anyone help with this?

The obj file format is pretty simple. It's all text based and shouldn't be too hard to parse yourself. Then just stick that data into some vertex/index buffers and you should be all set. I've not had any experience parsing 3ds files, so I can't be of help there. But obj is relatively simple. The first few search results for 'obj file specification' should be able to help you out quite a bit in writing that.

Yeh I've been reading up on the obj format quite a lot. I understand the format it's the actual implementation of the loader code. Parsing especially. I've looked through the MeshfromObj sample on the DXSDK but it's so intertwined with DXUT that I can't make out what's DXUT and what isn't for half of it. The code in the sdk documentation only touches on dealing with the ID3DXMesh interface once the obj files been loaded and parsed so I had a look through the solution itself and it didn't really help all that much.

I've never used mesh's before so I'm sorry if all this is rather newbish.

There's a sample in the dx sdk called MeshFromOBJ that reads a wavefront .obj file.

Beat you to it. I understand the parts about locking the buffers, copying the data in and unlocking them again. As far as parsing the file, from what I can understand the LoadGeometryFromObj method takes care of this by using an if statement to scan through the lines of the obj file, vertices first, then vertex normals, etc. etc. and if it can't find any of those then it does some random gumf that I don't get, I think it uses faces and gets the data that way but I'm not sure.

It stores the data it finds in a section of "CGrowableArray"'s but it's tight lipped on what data type these are and I can't even see where they're declared, much less what to do with them when they're full of mesh.

There is a very old conversion utility for .3ds files to the .x file format from Microsoft that they used to package with the DirectX SDK. You can search and find it if you want. Also, a lot of free 3D modelling programs will load .obj and .3ds files and save them into .x format. You can then load the .x format model file natively within DirectX, or you can load it and then extract all the info you need from the mesh class. I believe Blender is one such option, but I am not sure.

What you'll see with these various formats is that they don't lend themselves directly to creating vertex buffers and index buffers.  What most people do is to write a tool that reads these formats (or relies on interchange through .x) and writes out a custom data blob that can be used to create VB/IBs directly.  For instance, imagine how quick it would be to load the models if you literally just copied the indices from a binary file and the vertex buffer data from a binary file.  (They could even be in the same file.)  This is generally what people do and only use obj/3ds/x for interchange between applications.  Their custom tool cooks these formats into the thing that is most efficient for loading in DirectX.  AFAIK, that's the way to get the fastest load times.

binary files would really lend themselves very well to the process of vertex streams though would they? I've been reading through more an more of the MeshFromOBJ project and some things are becoming clearer, not including the random appearance of functions that are never declared such as m_material. I've looked everywhere but can't find it and if I try to use it, even by extracting every piece linked to that method it still says it isn't declared in the error panel. This stuff also seems to be geared entirely towards rendering one object. In order to render an entire world it seems I would have to create a mass of vertex buffers and fill them all with objects from the scene as if they were subsets, just like those you have in meshes, and store them in some kind of massive array (which I'm assuming the CGrowableArray's are), manipulate them in the appropriate way for the scene and then ship the contents off to the back buffer. All this stuff really seems more complicated than it should be, and indeed it's more than certain that I'm making it this complicated :D

PS. I really don't like .x

To render an entire world, you have one mesh object for each entity in your world.

And what is wrong with .X?

I don't like its structure. It's written almost like pascal *shuddering memories of college*. It's not a feasable option for me anyway.

I found something called a vertex cache which seems to be the vertex storage I was searching for. It seems that this simply holds the vertices until they are called through the ID3DXMesh pointer to the application to be render by subset in passes. However the program never calls on this cache or any of the previously mentioned sections of the mesh loading sequence and indeed none of it seems linked at all.

PG1:

I don't like its structure. It's written almost like pascal *shuddering memories of college*. It's not a feasable option for me anyway.

I found something called a vertex cache which seems to be the vertex storage I was searching for. It seems that this simply holds the vertices until they are called through the ID3DXMesh pointer to the application to be render by subset in passes. However the program never calls on this cache or any of the previously mentioned sections of the mesh loading sequence and indeed none of it seems linked at all.

Perhaps if you are going to dismiss the help people give you with "that is not a feasable option anyway", you might want to explain why it is not feasable. .X is perfectly passable model format and the bonus is that it is native to DirectX and can be loaded through one simple method call, and displayed via a single method call. There is no need for you to ever look at the "pascal" structure of the .X file. I don't even understand what you mean by that considering the X file is very similar to many other formats, it just holds the data in structures that are easy to parse into a mesh object.

I don't want to use it. pretty simple really. Would you ask a mac or linux user why they don't use Windows? They don't like it, simple as that. Yes .x is easier to impliment but with that harder to control. Xinput is the same. it's easy to put in place but after that you're pretty much it's slave.

PG1:

I've been reading through more an more of the MeshFromOBJ project and some things are becoming clearer, not including the random appearance of functions that are never declared such as m_material.

I don't know what you're talking about here; I've just looked at this sample and I can't find anything called m_material.  Also, the naming implies that this would be a data member and not a function or method.

I've looked everywhere but can't find it and if I try to use it, even by extracting every piece linked to that method it still says it isn't declared in the error panel.

I just loaded and built the sample fine, with no errors or warni