Noob wants to render models
And that noob is me. After reluctantly switching from C to C++, I really want to start fiddling around with 3D stuff. I know some basic 3D math and linear algebra, but I'm still struggling on exactly how to start with openGL. Like, how does it all fit together in code?
So I've been messing with blender, so I figure if I can make a simple model, and then write some code that renders it in openGL, that's a pretty good start. But I have a few questions that I'm sure the community has dealt with time and time again.
First, what's a good format to export my models as that will be pretty simple to read into an object? I thought of doing md2, because I found a tutorial on using them in C++, but I can't get blender to export it properly. Maybe someone else has a better idea anyway?
And then I guess I would probably need a tutorial on actually using that format in code form. So if anyone has any links or code or whatever for me, it would be much appreciated!
This is how I did it back then:
Read the official opengl red book (http://www.glprogramming.com/red/). You should read up at least up to chapter 5. That'll teach you basic rendering of 3d models, basic lighting, uv textures, etc. Look at the sample code it shows you if things get confusing.
If you want to try out rendering of 3d models from files, start by using the .raw file format. Its actually just a text file, 3 numbers per line (representing a vertex). If you connect all of those, you'll end up with the 3d model you exported. Pretty simple.
Then try the wavefront .obj format. Its also just a text file, but somehow a step up from the .raw format that it defines which vertices make up which face for the model. Its pretty easy to feed those values to opengl (you better read up more on opengl first though). It can also contain normals and UV texture coordinates data.
Blender can export to both those file formats.
I figured out those things by trial and error. Its really pretty easy provided you're familiar with basic opengl.
None of those file formats do animations though. Md2 or md3 can do animations, but they're a lot harder to process, lots of data. You'll be better off using a 3rd party library that does the hard work for you.
Also try out the nehe tutorials for learning opengl. http://nehe.gamedev.net/
So get the hang of it, make a simple game out of what you've learned or something.
After that, if you're really serious about making some games, I recommend you use a free (open-source) game engine like crystal space, ogre, or irrlicht. Game engines are fairly large behemoths though. Don't try them out yet. Get the hang of C++ first, learn the object-oriented programming paradigm, learn some basic stl data-structures. Then check out the tutorials for those game engines.
[Edited by - anomalous_underdog on November 3, 2008 12:50:22 PM]
Read the official opengl red book (http://www.glprogramming.com/red/). You should read up at least up to chapter 5. That'll teach you basic rendering of 3d models, basic lighting, uv textures, etc. Look at the sample code it shows you if things get confusing.
If you want to try out rendering of 3d models from files, start by using the .raw file format. Its actually just a text file, 3 numbers per line (representing a vertex). If you connect all of those, you'll end up with the 3d model you exported. Pretty simple.
Then try the wavefront .obj format. Its also just a text file, but somehow a step up from the .raw format that it defines which vertices make up which face for the model. Its pretty easy to feed those values to opengl (you better read up more on opengl first though). It can also contain normals and UV texture coordinates data.
Blender can export to both those file formats.
I figured out those things by trial and error. Its really pretty easy provided you're familiar with basic opengl.
None of those file formats do animations though. Md2 or md3 can do animations, but they're a lot harder to process, lots of data. You'll be better off using a 3rd party library that does the hard work for you.
Also try out the nehe tutorials for learning opengl. http://nehe.gamedev.net/
So get the hang of it, make a simple game out of what you've learned or something.
After that, if you're really serious about making some games, I recommend you use a free (open-source) game engine like crystal space, ogre, or irrlicht. Game engines are fairly large behemoths though. Don't try them out yet. Get the hang of C++ first, learn the object-oriented programming paradigm, learn some basic stl data-structures. Then check out the tutorials for those game engines.
[Edited by - anomalous_underdog on November 3, 2008 12:50:22 PM]
Thanks for the reply! I actually am familiar with C++ and OOP, I really just am not a fan of the extended syntax of C++ over C.
But anyway, I'm kind of wondering, is there any point to making one's own game engine when there are so many engines out there? Like, let's say I use crystal space or whatever... then to what extent will I actually be programming anything?
To be honest, the thing that has made me hesitant about making games is that it seems like everything's already been done. Like, back in the day I really wanted to get into doing physics stuff related to game program, but with things like the Havok engine, is there a need for hardcore knowledge of physics in the game industry?
I'm pretty naive on the subject, but I don't really want my game code to be just a framework of other people's libraries. Obviously openGL's capabilities are nice to have, along with it's tool kits. And I'll probably get a sound library because I'm not so interested in that. But if all the collision detection and physics and AI are done for me, it doesn't seem like much fun to get into.
But anyway, I'm kind of wondering, is there any point to making one's own game engine when there are so many engines out there? Like, let's say I use crystal space or whatever... then to what extent will I actually be programming anything?
To be honest, the thing that has made me hesitant about making games is that it seems like everything's already been done. Like, back in the day I really wanted to get into doing physics stuff related to game program, but with things like the Havok engine, is there a need for hardcore knowledge of physics in the game industry?
I'm pretty naive on the subject, but I don't really want my game code to be just a framework of other people's libraries. Obviously openGL's capabilities are nice to have, along with it's tool kits. And I'll probably get a sound library because I'm not so interested in that. But if all the collision detection and physics and AI are done for me, it doesn't seem like much fun to get into.
If you want to start learning Opengl, definately use SDL combined with OGL, it will make you're life a lot easier.
I would suggest looking at MilkShape 3D Binary Model Viewer (http://chumbalum.swissquake.ch/ms3d/download.html), by the author or Milkshape 3D. It's written in C++, using OpenGL. It's pretty easy to follow. The Milkshape format supports static and skeletal animated models.
Here's several free models to test with:
http://www.psionic3d.co.uk/gallery/thumbnails.php?album=2
Here's several free models to test with:
http://www.psionic3d.co.uk/gallery/thumbnails.php?album=2
Quote:Original post by guest42
Thanks for the reply! I actually am familiar with C++ and OOP, I really just am not a fan of the extended syntax of C++ over C.
But anyway, I'm kind of wondering, is there any point to making one's own game engine when there are so many engines out there? Like, let's say I use crystal space or whatever... then to what extent will I actually be programming anything?
You would be programming the core functionality of your own game: the game mechanics, winning/losing conditions, etc. Those are the things you will want to concentrate on, rather than platform specific problems, file i/o, etc.
Quote:Original post by guest42
To be honest, the thing that has made me hesitant about making games is that it seems like everything's already been done. Like, back in the day I really wanted to get into doing physics stuff related to game program, but with things like the Havok engine, is there a need for hardcore knowledge of physics in the game industry?
Just because the physics part of your game is already handled by something like havok, doesn't mean your game's already been done. You will still need to program, like I said, the game mechanics, the rules, the story perhaps if required, etc.
Hardcore knowledge, perhaps not, but you still need to be familiar with physics programming to be able to use something like Havok properly. Also, if you need to modify the physics library you are using, hardcore knowledge wouldn't hurt.
Quote:Original post by guest42
I'm pretty naive on the subject, but I don't really want my game code to be just a framework of other people's libraries. Obviously openGL's capabilities are nice to have, along with it's tool kits. And I'll probably get a sound library because I'm not so interested in that. But if all the collision detection and physics and AI are done for me, it doesn't seem like much fun to get into.
If you don't feel like using it, you could always make your own.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement