Interesting. I'm no 3D programmer, but this sounds like advice from the Quake 1 era when there was a lot of software rasterization/rendering. Is coding a model loader really helpful?

Good advice! I'm roughly half way through the list so far.

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.

How did we get from coding your own model loader for .obj, .stl, or .3ds files to writing your own model file format?

I can see your #5 being educational, but writing your own model file format would be almost pointless.

not bad, I've done all but the skinned animation(though i do have a good idea of how I'll handle this). Where's part 2, steps 11-20?

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.

I would put learning modelling earlier because you can do that without extra work.

@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.

Not too long ago I also coded my first Obj-Loader for android. I did a fully working obj loader with per-vertex normal calculation in 2 or 3 days. I was proud of myself haha.

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.

This list almost exactly describes my beginning years, the order was not really the same and there were some extras (like texture loading), but I surely did all of those things.

However, that was about 10 years ago and since then, 3D programming has evolved to the point where there must be shader programming, the sooner the better.

Nice article

What about frustum culling ?

I never learned 3D programming yet. I am still teaching myself 3D programming. Man it is a whole different world reading this article about it.

if youve got a fancy video card. (like say a gtx 690 or better) you can try making a game with distance fields!!! its really cool!

I would find a decent engine with source code and study and modify it.

The problem with trying to do it yourself is that you'll probably learn the "wrong way" of doing things plus it will take much longer.

And then as another poster said move on to shaders as quickly as possible.

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!

Nice article, but I also disagre on some point:

#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).

Nice article , I will follow your advice .