Thread: reading a .3ds in OpenGL?

Solved: Thanks for the help

Hi guys. I've been playing around in OpenGL lately and downloaded the trial of 3d max. I'm thinking about purchasing the product for a full liscense, but want to make really sure I would be happy with the program. I have about 15 days left on the trial and I have made a complete 3d chess board. I would like to use an old chess engine I wrote and make it 3d. Does anyone know of a library or tutorial (free) that covers .3ds files in OpenGL? I tried asking on the autodesk community site but a majority of the members there seem to be designers and not programmers. I know you guys seem to provide the best answers I've seen around. Thanks.

.3ds files in OpenGL - Google Search

What do you want?
Clues on how to proceed or spoon-fed answers?

Sooner or later, there ARE no tutorials for what you want to do and you have to figure it out yourself the hard way.

3ds objects are loaded in OpenGL

It's simple. You don't. 3DS is a proprietary file format and it's format will probably not be available on the internet. Even if it were the file format probably has a lot of bloat in it so the modeller can load the data into the system correctly. You would not need all of this extra stuff to simply load the data and it's associated scene graph, key frames, etc. As I said the usual practice is for studios to make an exporter for 3D Studio Max or Maya or whatever tool they are using. The exporter takes the data that is in memory and exports that data to a file with a format the engine code can read. 3DS and Maya both come with SDKs that allow you to write plug-ins for them for this exact purpose. Blender, to some extent, has plug-in support but it is through Python which more or less sucks and is not nearly as robust as supporting a C++ plug-in architecture. It is so simple to support such an architecture I have no idea why more programs don't do it.

If you are looking for a free solution you could try out the now defunct Caligari TrueSpace 7.6 which also has an SDK and supports C++ plug-ins and also has very good professional level documentation.

Other free solutions are not that great and sadly I've found that most open-source modellers are sorely lacking in documentation when it comes to plug-ins and writing exporters. Another one you may be interested in is Milkshape. It is not free but it is a good basic 3D modelling program and it also supports C++ plug-ins.

A good open-source scenegraph solution is OpenSceneGraph. Supposedly this is gaining momentum and is supported by a lot of the major 3D modelling software packages. It is limited to OpenGL but that is what you said you were using so this should be a plus for you.

Take a look at some of the files in the games you have bought for your PC. You will find that nearly every engine uses a proprietary custom format that has little or nothing to do with the modelling software that was used to design the files. Gamebryo games use the .NIF format wherein the scenegraph and other data reside. They also rely on some other files for keyframe animations and other data.

Sooner or later, there ARE no tutorials for what you want to do and you have to figure it out yourself the hard way.

You really need to take heed to what Salem is saying here. All the good 'secrets' are just that...secrets. No site is going to tell you everything you need to know to export and load in retail quality assets. And the truth is there isn't one tool that gives you this kind of quality. Studios nearly always rely on several different tools to create the assets and it is no small task. It is also not a small task to export all this data to a file format the engine can read and it is no small task to be able to render the object in your system as the artist created it in the modelling software. However, that is really what needs to happen or it needs to be very close. If you ever go down the path of hiring out your asset creation you will soon find they are creating beautifully rendered objects in their tools but you can't render those with your code so the effort is in vain. The key is being able to load and render those beautiful assets the artists so painstakingly created. There aren't any tutorials for this on the internet. And to get to that point you will need to design a fairly robust and complex system in the first place. I recommend you buy tons of books that address the issues you are encountering. Even then you will find that 80% of the books fall into the beginner to intermediate level and even the so-called 'advanced' ones are not all that advanced.

One good place to learn how to do some of this or the design processes involved in asset creation and asset loading is at www.gamasutra.com. They have many very good articles on this and tons more on other topics.

I have a friend at work that has done exporters for Maya. Unfortunately since 3DS Max is extremely expensive I do not personally know anyone that has written exporters for it. A friend of mine just paid nearly $2700 to do the same things you are talking about here and that is just for the software. After you get into hiring out the art and asset creation that number grows quickly. And that doesn't guarantee you will have great assets or if you do it still does not guarantee you will ever have a game worth playing.

Keep in mind the danger of using 3DS is that if the file format ever changes in future versions (and it will) your code will be broken. It is probably not a good idea to rely on a file format when you have no control over the versioning of it. You are tying your code and your system directly into something that is beyond your control. It is much better to build an exporter that you can update later and yet still have your engine load your own file format that the exporter exports. This way you control the versioning of the asset file and when 3DS changes formats you simply write a new exporter or alter the existing one. File format versioning can become a real nightmare.

Also remember the devil is in the details. Very often I find sites that claim they can load this or that format but skip over tons of information in the file that they either do not understand or for some reason think it is not important.

Triangles are more efficient because that is what the hardware needs. Again geometrically triangles are the only primitive that make sense since any 3 points in space are guaranteed to be co-planar. Thus a triangle will have 3 vertices, 3 edges, and 1 normal. You can overcome the vertex inefficiencies by sharing vertices via an index buffer. The index buffer essentially tells the hardware how to connect the vertices.

A quad with a clockwise winding order without an index buffer in Direct3D would be:

v0: -1.0f,1.0f,0.0f
v1: 1.0f,1.0f,0.0f
v2 -1.0f,-1.0f,0.0f

v3: 1.0f,1.0f,0.0f
v4: 1.0f,-1.0f,0.0f
v5: -1.0f,-1.0f,0.0f

Now notice there are some repeats. So an index buffer allows you to use the 4 unique vertices in the group and share them among triangles.

The vertices would be:
v0: -1.0f,1.0f,0.0f
v1: 1.0f,1.0f,0.0f
v2 -1.0f,-1.0f,0.0f
v3: 1.0f,-1.0f,0.0f

The indices would be:
0,1,2
1,3,2

Index buffers are also optimal b/c it allows for efficient vertex caching on the video card. You might think sending in extra data would clog the bandwidth but it is actually more efficient to use vertex buffers with index buffers b/c of the caching scheme employed on today's video cards. It also reduces the number of vertices you must send down the pipeline.

Even more efficient is to use triangle strips or triangle fans. A triangle strip requires 2 starting vertices and then 1 vertex after that for each new triangle. A triangle fan requires 2 vertices to start with and 1 for every triangle after that with the exception that the starting location of all triangles is the first vertex. Triangle fans are often used in terrain engines to give real-time level of detail. It simply comes down to which parts of the fan to draw and which parts to omit. This can also be done with a clever use of an index buffer. Index buffers can also be used to reduce the number of polygons in a mesh in real-time. Direct3D9 employs a mesh reduction algorithm that uses the index buffer in a clever way and the result is a mesh with pretty much the same shape of the original mesh but with far fewer triangles. The algorithm was invented by Hugues Hoppe - http://research.microsoft.com/en-us/um/people/hoppe/ (click on the link for Progressive meshes).

When it comes to rendering the smarter the better. What you do not render is far more important than what you do render. There are thousands of algorithms out there that will squeeze every ounce of horsepower from the hardware simply by being smart with what is and is not rendered.