Please pm me any corrections and suggestions, and I'll edit this (I'm open to criticism)... Don't be shy.
there seems to be a lot of questions, regarding 3ds loading and since Ranger_One has started writing a tutorial on obj loading I thought I might as well do the same.
first of all I would recommend wavefront's obj format over 3ds, for several reasons

obj reasons

Its in a human readable format, so you can use a simple text editor to make changes to the file.

Its a lot more logical, compared to the irratic structure of a 3ds file

There is no redundant data.

3ds reasons

Binary format, therefore it is faster to load, and is smaller.

But there are always people who want to prehaps convert a 3ds file, to their own personal format and 3ds is also a VERY popular format (prehaps even more so than max file format!).
The first and foremost thing to remember about the 3ds file, is that everything is ordered hierachially like in xml.

above you will see a highly simplified version of what I mean.
in 3ds however the tags are replaced by chunk headers.
Everything in 3ds is organized into chunks. In the example above a chunk would be root, meshes, vertexlist .etc
A chunk header takes the form

reading chunks is trivial. lets say, we opened the 3ds file, read the first 2 bytes and realized its not the chunk we want to parse? well, we simply read the next 4 bytes and jump c00 + offset (this is why it is important to store your offset in the file before reading the chunk id's).
Even better lets say we read the first chunk under c00, and realized that c01 is not a chunk we are parsing? well we simply read the next 4 bytes, and jump c01 + offset, placing us right before c02's chunk id (at the point its good to store your new offset within the file).
Chunk ID's are the equivalent to tag names under xml.
Also a side note, the data under chunks ALWAYS comes before the sub-chunks.
OK, so lets parse a 3ds file :)
lets give you the part of the 3ds file you will parse (you will of course need a 3ds file).
we are just going to read a few chunk headers.

i should mention that I spent a long time, searching for a bug when i ported my parser to win32 - tellg() returns strange results without the ios::binary flag :S
some 3ds files may have different output with the above program, so get a different 3ds file (all the 3ds files ive tested so far, have given same result, but they may have a different chunk ordering).
No this is all well and good, but its not a nice way to parse a 3ds file :/
Taking our comparison with xml, most xml parsers work like this

this is how the above example could be coded in our imaginary world.
You may complain how that is longer and more lines, but that sure as hell, is easier to understand.
Now imagine that instead of strings and names we had shorts and ID's. That would then become.

I belive you should finish it. And some mod should add this (and OBJ) thread to FAQ.

And just one note: There are also upsides compared to .OBJ files. The main one would be the fact that data in 3ds files is stored in binary format and this makes them much smaller and alot faster to load.

now, when we create a chunk we need to know where the end of the parent is, so we know once we've stopped parsing sibling chunks.

<root> <teacup /> <nine /> <farah /></root>

once we reach farah, we also reach the end of root.

so we open up our 3ds file. When we start parsing, we pass a reference of the current ifstream to the root chunk (stored as a const reference), and the filesize in bytes.The end of the file is also the end of the child chunks - although a 3ds file should only have one root chunk (rather like xml).

the code for this goes something like this

/*open file stream*/ifstream file(src , ios::in|ios::binary);

/*get child node*/file.seekg(0);Chunk c(file , FileSize(file));

so adding creating the file loader (you will notice I've now wrapped it in a namespace)

Nice work! I would also suggest to you making a .DOC/.HTML version formated and colored [wink]. I have yet to read though it, but new tutorials are always good. When I get a chance to read it, I'll give you some feedback.

anyone spot the bug? what do you think would happen were you to have open 2 seperate 3ds chunk file streams and called operator=() on them? well since the first file stream wouldn't be changed to the second, you'd end up positioned where the second chunk is in their file stream, in this file stream!This is ok, and poses no real threat however when we write the parser wrapper (as it opens a the file stream, parses the chunks and when the function exits, Model3DS::File is destroyed and hence the file stream is destroyed.

the test, to see whether whether this chunk, is at the end of the parent chunk (i.e this sibling and all the next siblings are invalid), we saw above

remember above that most of the loading was done in the mesh object itself? well here we do the opposite. this is because, because we're adding the material to a hash array, we need to know its name. meaning we have to start parsing the 3ds file for the materials name. We also need to therefore extract the needed info from the other chunks.This is a limitation of the way 3ds files uses chunks - a workaround can be made, but it's long and arduous (not worth it).