Ten Things to Achieve When Starting 3D Programming

Starting 3D programming is not an easy task to accomplish. There are a lot of new things that come into play, and they vary from choosing a programming language to selecting the correct 3D modeling software. These 10 goals are the things that when they are done, no matter in what language and with what rendering engine, you can consider yourself a semi-expert on this matter.

#1: Build your own custom graphic initialization function

Today with the great variety of 3D engines and platforms, this task is always delegated to those. I still remember the times when you had to initialize OpenGL with all the windows functions, and how you had to manage windows handles and resource loading yourself. This is useful to understand how things are managed internally and will give you more comprehension of what you are doing. My advice is to start looking at NEHE tutorials, it has a graphic initialization function written in C and with windows APIs in chapter one. If this is a lot for you to handle, you should look at C++ equivalent functions or try to port them to managed languages like C#, Java or Python. There are plenty of examples on the internet.

#2: Implement your own camera

You can copy and paste a camera code from the internet, and use it without major problems, but it is not until you make your own camera from scratch that you will fully understand some concepts like vector handling, translation matrices, angle conversion, etc. You should start by coding a FPS (First Person Shooter) camera; it has everything it needs to get you ready. Later if you want to make your own game and you can’t use it, I recommend you to read this article to find out the type of camera that best suits your needs.

#3: Understand primary 3D concepts

When I started, I began to hear a lot of new words like anti-aliasing, anisotropic filtering, occlusion testing, z-buffer, alpha testing, shader language, bump mapping, etc. Maybe if you are a gamer, you have seen some of them while configuring the graphic settings of your game. Make sure you spent some time reading about this, because it will give an overview of what 3D programming is.

#4: Learn everything you can about vectors and matrices

This is always underestimated, I strongly recommend that in order to correctly manage things like cameras, terrain following, ray tracing; you should know everything about this. You should also learn minimum trigonometry basis. Now I understand how easy my life would have been if I would had spent only a few hours studying this matter.

#5: Code yourself a 3D model loader

I recommend beginning with a .OBJ file or a .STL file because they have an ASCII format representation. Later, you can move to other more complex formats like .3DS. With this, you not only will understand more how 3D models are saved, you will have to draw it in its raw manner: triangles, and then you will understand how everything is drawn in a graphics engine.

#6: Successfully make your own collision algorithm

It is one thing to draw a world and another thing to manage its geometry. In a virtual 3D world, there are no physics laws, so you have to create them. If you want an object not to go through a wall, then you have to create an internal geometric representation of the wall and make all the calculations yourself. There are several approaches to handle collisions; I recommend starting with binary collisions with a labyrinth project. Try this link for more information.

#7: Implement a small particle engine

I was disappointed when I found out that fire, smoke, some lighting and other stunning effects that you see in 3D games are made by particles and that particles are in essence planes with textures facing the camera. The more particles you add, the more realistic the effect looks but the performance is more compromised. The first particle engine I made was for rocket smoke and I did it without looking at a particle engine tutorial. Later I realized I had reinvented the wheel but I was really into this. By carrying out this, you will understand concepts like particle emitters, particle behavior and bill boarding techniques, among others.

#8: Learn the basics in a 3D modeling software

In order to make changes to the 3D models you want to use in your application, you should at least know operations like translating, scaling, rotating, texturing, exporting to other formats and making simple models. If you don’t do that, you will suffer from depending on other people to do your first game. I’ve worked with a few modeling software and I strongly recommend 3D Max or Maya.

#9: Load and play an animation

Loading and correctly playing an animation was the most difficult thing in 3D that I ever did. I had to do reverse engineering to a 3D max .XAF file. I had to also learn stuff like bone hierarchy, matrix interpolation, among others. At the end, it was very gratifying to look at your own models moving by themselves. I recommend starting with animating a robot since models like animals and people require another technique called skinning.

#10: Code a 2D custom Graphic User Interface (GUI)

When I began programming in XNA; I was forced to build my own GUI because XNA does not have implemented any windows controls. This gave me two things, the first one was the ability to make my custom GUI controls and the other one was the understanding of concepts like event handling and event capturing. It is not easy, the most difficult control I have made is a listbox, but once it is made you can use it everywhere.

Conclusion

In this journey you will come across several issues. You will spend a lot of time trying your code to work no matter how smart you are. But I can tell you that from a programmer side of view there is nothing more comforting than seeing your own code working. I still remember the joy when I first coded an OBJ model loader. I was trying to load a face and after several hours on the task at 3:50am suddenly a very weird face appeared on the screen and scared the hell out of me, I laugh every time I remember that story.

I am sure when you manage to achieve these ten things, you can say you have the basic knowledge of 3D programming. I wrote this because I spent a lot of work and time to achieve them, and because I would like everyone to have a small guideline when starting in this world. My advice is to start making a small game and to try to adapt them on the go. I think this is the best way because trying to learn all this without the possibility to see it in action is not very motivating. You will see after a while that gaming won't be same for you, because you will spend some time trying to figure out how they solved some technical issues that you faced before. Thats all for now I tried to keep this article clear and understandable, if you liked it, you can visit my blog for more stuff like this.

About the Author(s)

Born in 86. I have been in 3D programming for a few years. I am a software engineer but I learnt it as a hobby. Later the hobby became my passion. Now I run a small 3D programming blog http://vasilydev.blogspot.com/ where I have placed everything that I have been working with in the last few years.

I was with you up until the collision detection. That's a big task, and there are a lot of libraries that handle the low-level broad/narrow-phase algorithms that you can plug in to. I guess it's a matter of preference and intent: do you want to get something working, or do you want to learn everything there is *behind* getting something working? For the former, learning to read a few whitepapers and then the docs for a particular pre-written library is a much quicker approach that still nets the same functional outcome.

Otherwise, these are all great points, and great practice for someone who has the time. I wrote an obj loader for a JOGL game framework during my undergrad because everyone else was writing all their 3d meshes vertex-per-vertex. It certainly helped me understand the route from modeling software to in-game visuals.

To answer Alpha_ProgDes question, it's somewhat sure you won't be using the 3D Model file format you wrote on your own (at least, not you first attempt of it) and end up using someone else's (there are exceptions though).

However coding your own model file format will make you learn A LOT from it. There's A LOT, and I mean A LOOOT happening behind the scenes that a programmer learning 3D programming should know. It's not just relevant on how to store vertices in the disk and get them back into your game. You end up learning how GPUs work, how APIs work, end up realizing why vertices are stored that way, lighting issues, causes for UV seams, real time performance issues, GPU memory layout, and many "why does X behave like that" or "why does X require Y? They're [apparently] unrelated!".

Also, there's like 7 ways to skin a mesh, not to mention at least 3 ways to animate the vertices, each with it's advantages, drawbacks and memory vs processing power tradeoffs; many ways to store the animation data but only a handful to store them efficiently (and define efficiency: low hdd? low ram? low cpu usage?) and each animation method works better in different scenarios.

So, it's more of an incredibly useful learning exercise rather than having a practical implementation of your own model format; but this doesn't always mean your won't end up using that file format in your own future games.

I would disagree with you Dave Hunt. Other than being an educational learning experience, creating your own custom format along with creating custom tools, either through programs like blender that allow you to do just that using python, or through your own application, can allow for a whole new technology to be created, allowing for unimagined capabilities of your game assets.

Good advice overall. All these things would be definite pluses if I'm hiring a mid to senior level graphics programmer. For a good senior-level graphics programmer, it's nice if they'd done ALL of these things before. A broad knowledge of the rendering pipeline and tools is vital because they might not be doing any of these in an in-house engine, but it's important that they be able to do it, or fix problems with this code when they arise.

@Slig Commando - My primary point was that comments should be in reference to the article's contents. The article didn't address writing your own model file format, so I thought it strange the author responded to a comment in reference to loading models with reasons why writing your own model file format was a good thing.

My secondary point was that, in the context of the article's title ("...Starting 3D Programming"), writing your own model file format would be of little or no benefit. Someone just starting 3D programming wouldn't have much of an idea what to put in a model file beyond what they would already find in an existing format.

@Dave Hunt: While you're stressing the word "Starting", the article is really advice on goals, things to achieve as a graphics programmer. So while the article is advice for those who are starting, it's not advice on things to do when you're starting.

The intro clearly says that if you can achieve all these things, you can consider yourself a semi-expert on graphics... which is fair enough if by "semi-expert" he's talking about a mid-level graphics programmer. I think the list is incomplete because any mid-level graphics programmer also needs solid experience with things like shaders, lighting, post-effects, at least a bit of multi-threading experience... and probably many more things.

I think it's a helpful article because I see a lot of posts on these forums from people starting out and who want to become this or that, but have no idea what it even entails. This gives a nice set of goals for anyone starting out on the road to doing graphics.

mmm yes I should have put lighting on the article,On the other hand, to be true when I started OpenGL programming, Shaders and Post effects articles where written in a very dark C, beyond my knowledge scope. Now with XNA and other game engines you couldnt imagine how easy has become.

I did every point of this article back when I was at university (some for the course, some for a project) and feel that I came out better for it.

Sure, I forget the specifics of the X file format (and more), but I know how these things work behind the scenes, where they're slow, and what can be tweaked, which is fairly important for getting into this kind of programming.

From beginning the hello world aproach, I hear often as advise keep start project small. So to start small you choose the scope of you first hello game with as limted requerments as possible. Because its a decent long list to start with and not complete.
The criteria is take only those that are critical to get first playable result. The first iteration. That would be a huge confidence boost.

I drop the 3 d modeling by going for a extreem abstract asset.Very simple 3D objects that they can be even hardcoded.
So no need for model loader yet.
No learning a heavy 3D software yet.
Fancy features as particle system yet.
3D animation. Well I think of games that need animation lets avoid that. No FPS or TPS. With characters.
Not mentioned but choose a genre with no terrain.

So something like a simplistic space shooter.

You start with the bare minimum for a playable game. And then you iterate by extending it with each optional features. Wich enrich it. Where other features may depend on.

Direction that could be followed. Depends on preference.. Mine, would stay lone wolf as long as posible so depending on a artist I would avoid.
So I go the procedural way. Could be not pure but mixed.

As a gamer I don't like retro or abstract games. So the project wil grow to better GFx so more 3D model features and effects. And animation.

But we start with the core features a minimal playble game needs.

Still missing.
Sound and AI.
In short at least every feature you need as critical part of your gameplay mechanics.

I think the message here is a bit dated, but the spirit of that message is spot on. There is a ton going on behind the scenes of modern day engines. And if you don't know what those things are you will have a really hard time tracking down bugs.

Studying an engine that is already in place is a good start but to really learn something most people (me included) need to actually do it. I often I find I learn faster by doing something and making 18 million mistakes than by following a tutorial. It's like if someone led you through a dark room to the exit, you might be able to find your way back from the same starting point but come at it from a different direction and you'll be lost, scared, and alone.

Great article! I would also focus on the shaders - how to use them in the renderer. Another things is maybe to know both OpenGL and DirectX - at least try to create some basic app in both of those APIs.

I've done everything except #6 and #9... can't check those off because every time I try, I fail miserably
But I agree completely - everything you've listed that I've done has been a tremendous boost to my knowledge and confidence. Highly recommend everyone to try out the things listed here!

#5: why program a .obj parser ? I wouldn't say it's a waste of time depending of the skills of the "3D programmer", but that's pretty far from the point, just read some documentation about it and open an .obj in notepad++ should bring the same knowledge in 2 hours (instead of 2 days).

#6: physics and rendering are two different subject, even two different jobs I would say. Either you want to learn physics and use Ogre (example) for rendering, or want to learn rendering and use bullet (example) for physics, but trying to learn everything at once sound like a bad idea.

I would add 2 things:

- program a simple raytracer, I learned a lot doing this (octree, culling, ...) and knowing how these works will become mandatory in a near future since rasterizer days are counted.

- program some procedurally generated meshes (with marching cubes, or whatever), but this probably replaced the .obj parsing stuff.

Nice list. After a lot of work I've done all 9 of them . No particle system added yet, because I don't really need it for now.
I also recommend (what I did) to create your own file format and converter for animation related data (skinned, skeletal). I find files like fbx very hard to understand, and Collada files (*.dae) contain much more unnecessary data and are not structured well (in my opinion).