5 Replies - 8784 Views - Last Post: 02 August 2015 - 08:35 AM Rate Topic: -----

#1 BBeck  Icon User is offline

  • Here to help.
  • member icon


Reputation: 792
  • View blog
  • Posts: 1,886
  • Joined: 24-April 12

Learning 3D Game Programming: A Road Map

Posted 29 June 2015 - 02:05 PM

*
POPULAR

(Disclaimer: I don't necessarily endorse any YouTube video or website other than my own as to the validity of what is being said or its understandability. If some of them seem overly convoluted and confusing, I thought the same thing. But I wanted to put some examples out there and in a quick search these were some of the best links to these subjects I could find on the Internet. When I do tutorials and videos I try to boil things down to what really needs to be understood and make things clear enough that the layman can easily understand - which may be hard to believe when you watch my hour long videos where I drone on and on but I really am trying to boil things down to their very essence and make the explanation as simple as possible. How successful I am in this endeavor is for you to decide. But I explain things the way that I do in order to make them as easy to understand as possible. And I do so because I believe I can explain them more clearly than what's currently out there from other sources. If I thought the other sources could cut to the chase as well as I can or better, I would just direct you to those sources and not bother trying to explain it myself. So the examples given are to introduce you to the subject and give you someone else's perspective other than my own, which I find is usually a good thing since the more perspective you have on something the easier it is to understand it and the more complete your understanding. But primarily I link to other peoples' teaching material because I haven't developed teaching material on the subject yet myself or because it's another perspective on the subject.

What I'm trying to say is that some of what they say in some of these videos is half confusing to me and I know what they're talking about because I already know these subjects. So don't let all this crazy math talk and such overwhelm you. It's a lot more simple than it sounds when you go to code it. For one thing, the computer tends to do all the math for you and so all that math they're telling you about is not something you have to code, let alone understand. These are just some discussions on the topic to give you some exposure to the subject. Don't expect to understand half of what they're talking about. Just watch the videos casually to start to absorb some of the topic.)


So, I've been thinking about what I think might be the best approach to learning 3D game programming as to what you need to learn and when. So, I wrote this to maybe give beginners some insight into what they need to learn in order to program 3D games.

Not for Unity

The first thing I should probably say is that little to none of this applies to Unity because things are so dramatically different in Unity. The approach I would take when learning a game engine like Unity is substantially different even to the point I don't think you can do a side by side comparison. So, what I'm talking about here is when you're using a framework or SDK for 3D game programming.

The primary difference is that with Unity, you're more trying to learn the engine than you are trying to learn 3D graphics programming. It's more about "What does Unity want me to do?" and "How do I do the things Unity wants me to do?" where programming with DX, OGL, or a framework built on them is more about "How do I make the graphics card draw this?" and understanding the types of things that Unity is doing for you. For example, Unity exposes the "Transform" of a GameObject to you and this is basically a world matrix for that object, but you would almost never know that unless you had worked with a lower level framework.

Anyway, the approach here is really not for a game engine such as Unity but for a lower level framework/SDK.

Prerequisites

Before you even get started, know that this involves a fair amount of algebra, trigonometry, and a whole lot of linear algebra. So, you'll want to understand matrices and vectors and how to use them. You don't necessarily need to know the math behind them, but you need to know when, why, and how you would use them during game programming. You can "somewhat" learn the vectors, matrices, and such from linear algebra along the way. A lot of the math you may be able to copy and paste from stuff you got off the Internet. But to really understand it you're going to want to be solid in algebra, trig, vectors, and matrices. Calculus sure wouldn't hurt although I don't know calculus and it hasn't been a big problem for me so far.

The programming language you're working in will be something you should be comfortable in before even thinking about doing game programming. You don't want to be learning the basics of that and trying to learn this other stuff at the same time.

And you're also probably going to have to develop rudimentary artistic skills along the way. Your art work may not have to be anything to brag about, but you need to know how to produce "functional" art work. If you can get art work in there that works and demonstrates the concept, you can maybe find or hire an artist to come back and replace all your art work with stuff that looks decent (or in the case of music and sound effects, sounds decent). Don't think you can't say "Pew Pew" into a microphone and use that for your gun shot audio until you can find someone to give you a decent recording of a gun shot. It might be pretty entertaining to play a game that had entirely spoken sound effects rather than the real thing. Sounds like you'd get a pretty good laugh out of that to me anyway.

That being said, I've been thinking about what order to learn things in and what needs to be learned for tutorials and such. Probably the first thing is to understand that what you're trying to do in 3D game programming is a lot like movie film.

It's Kind of Like Making a Film

With the old film movie cameras, the film is divided up into frames. It's exactly the same as a still image camera: A shutter opens for a brief second to expose the light sensitive film to the image in front of the camera that is focused on the film through a lens. The shutter then closes before the film is over exposed. When you hit the "advance" lever it moved the film forward exactly one "frame" and then you were ready to do it again. With motion pictures it's the exact same thing except the whole thing is automated to take a picture 30 times per second. A chemical process is done on the film to make it no longer sensitive to light so that it can be brought into the light without losing the images on it. Then the whole process is done in reverse with the shutter opening to project the image, the shutter closing, the film advancing one frame, and repeating 30 times per second. This makes the projection appear to be full motion even though it's actually individual still images. (Less than 30 frames per second will be seen by the human eye as "jittery" or even possible still images if it gets slow enough.)

With game programming, we're doing basically the same thing. We're only drawing one frame at a time, then we clear the screen and draw another frame and so on. When we do this faster than 30 frames per second, it makes it appear as if things are moving.

If you're using a game programming framework like XNA for example, you should have a game loop that has an Update() and Draw() method/function at least. The Update() and Draw() methods are called once every frame to Update() the game and then Draw() the current frame. Update() is for anything that is not about drawing to the screen. There is so much drawing that Draw() really needs its own method/function. This all runs as a loop and if it draws a fresh screen at least 30 times/frames per second, it will appear that things are moving rather than the individual images you are actually drawing.

I think starting out, this wasn't something I fully understood. I wasn't sure what the purpose of Update() and Draw() were and what it was we were trying to do in them.

Raw DX11 Doesn't Let You Start at the Beginning


Now if you're working in OpenGL or DirectX, you have to build the framework in order to do a lot of the "beginner" level stuff. So, you start out from the very beginning more at the intermediate level. Because it takes at least the more advanced beginner stuff to build the framework to do the most basic stuff. That's maybe the biggest advantage of learning with a framework like XNA where you have a built in model class and such.

If you're working in DX (and probably the same with OGL), you have to build the model class and the texture class and such from scratch so that you can do "beginner" stuff. You have to be kind of intermediate level or so in order to build the stuff you need to do the beginner stuff. But you may be able to use libraries and such. DX10 had a model class and some things that you may be able to make use of even if it's deprecated and considered bad form. The "more" correct thing would be to use the DX ToolKit which has a lot of the stuff that was dropped out of DX11 like a model class, sprites, fonts, etc.

So, you probably need some sort of framework if you're absolutely new to this or otherwise you're just going to have to dive into the "deeper" end of the pool right from the start. On my website and YouTube channel, I'm working on tutorials to explain how to build this framework in C++ with DX11 from scratch. In some ways, that assumes you're already at the intermediate level starting out.

The Model Class is the Place to Start

The main thing for starting out at the beginner level with a framework is a model class and the ability to do do vector and matrix math. DX (and probably OGL) has built in classes for the math. But the model class makes it a lot easier to get started and DX11 doesn't have one.

Once you have a framework (especially a model class), the next step to learning 3D game programming is to put something on the screen. If you have a model class, like in MonoGame/XNA, you would want to start by using that to put something on the screen. The code is just a couple lines to load a model and maybe 10 to draw it if you do the whole parts loop and set the effects for BasicEffect in XNA/MonoGame. It's not hard at all once you learn how to do it and it's mostly copy and paste code. Of course, you have to have models. But you can export a model from Blender as an FBX file and then add it to the ContentProject in XNA so that it can be used in XNA. The hardest part of that is figuring out how to make a model in Blender. I'm sure the process is similar with DXTK although you will almost certainly have to use different file formats and the process may be a bit different. In my own framework for the tutorial, I write a custom exporter in Python to pull the raw data from Blender. Then I run it through a compiler that I wrote to basically make it a serialized version of my model class. Then the Model class can read that compiled file to directly load in all the data for the model.

You have to figure out the basics of the Projection and View matrix to even draw the most simple of things. But it's like 2 lines of code and the Projection matrix code is pretty much the same every time. Using the LookAt method with the view matrix makes it fairly easy to do that as well. Most any framework or SDK for 3D game programming should have these.

Maybe this would be a good point to figure out how to rotate the model with its world matrix.

Then the next step would be to learn to put multiple objects in the scene (same thing as before but just do it multiple times in the same code).

Once you have multiple objects in the scene you can see motion. Without at least 3 objects in the scene, you can't really tell what is moving or exactly how it's moving because everything is relative. I like doing a ground plane and a couple other objects.

Once you get that far, the next step is figuring out how to use the view matrix to move the camera around the scene and how to use each object's world matrix to place and move these objects. This would be a good place to figure out the basics of keyboard and game controller input.

Learn to Use Matrices to Move Objects

But you want to focus on using the matrices to do the motion rather than variables or something. My GimbalLock video pretty much explains what to do and what not to do as far as rotations. Learning how to move objects with matrices is probably one of the most important things to learn and I think a lot of beginners want to skip it because it's unfamiliar to them.

Part of understanding matrices is understanding how to use them for rigid animation and how to mount one object to another like putting a gun or sword in a model's hand or sitting the model into the seat of a car. Once you figure out rigid animation, this will almost be self evident.

(You can use any unit of measure you like as long as it stays constant, but 1 unit of size/distance equals 1 meter is pretty much the industry standard for most things.) If you keep the camera at a height of 1.68 meters, then it feels like you are walking through the scene. I calculated once that that's about the height of the average man's eye level. On a flat terrain, this works pretty good to start with. To allow for jumping, you just have to make sure the camera never goes below 1.68 meters but you can allow the camera to move upwards beyond that. You might have to implement gravity, which gets into real world physics, but you could also just "fake" it. The main thing is that you fall back down after jumping.

Then You Can Start Exploring Other Areas

Somewhere in here you may want to explore topics like sound effects, music, and the game timer. The game timer allows you to keep things moving at a constant speed even if the frame rate changes to speed up or slow down.

After that, you've got a pretty solid foundation and there are many directions you could go in after that. You probably want to explore collision detection around that time. It's good to know spherical collision detection. It's the easiest and most efficient. You'll want to learn Axis Aligned Bounding Boxes as this is the second most efficient. However, it's pretty severely limiting to never be able to rotate your collision box. So, you'll probably want to learn Oriented Bounding Boxes so that you can rotate them. Then there's hull collision after that.

Skyboxes Improve the Look and are an Opportunity to Learn Vertex Buffers

You may be getting tired of not having a "proper" sky at this point. So you can do a skybox just by making a cube in Blender, texturing it inside out, and importing it into your scene like any other model. The only key is that the skybox has to move with the camera (and be big enough to not interfere with the terrain and such but you can scale it to proper size). It doesn't rotate with the camera, but when the camera changes position, the skybox follows it. This is probably the easiest way to implement a skybox.

Pretty soon you are going to be wanting to figure out how a vertex and index buffer work. Perhaps the skybox is a good opportunity to work on the vertex buffer since a cube is one of the easiest shapes to hard code. It's at least "do-able" compared to a more complex model which you just simply can't code by hand.

This is where you can really start delving into the deeper stuff by using the vertex and index buffer to make your models rather than using a model class to do all the work for you. Really, this is what the model class is doing under the hood. There's a little bit of a learning curve here to figure out that all you're doing is drawing triangles and loading up the vertex buffer to specify data for each of the 3 corners of the triangle. You're going to want to learn about the different draw calls to use with the vertex buffer like "DrawUserIndexedPrimitive", "DrawPrimitives" (probably the first you should learn), and "DrawIndexedPrimitives". You'll want to learn about triangle lists and triangle strips and such.

You'll want to first start out by just drawing a triangle. After that you can figure out how to draw triangles to form a cube. If you figure out how to add UV coordinates and such, you can texture the cube. If you get that far, you can hardcode a skybox without using the model class.

Terrains are Cool and Give You More Practice with Vertex Buffers

And about this point, you should be ready to try and do terrains. This is good practice with a vertex buffer. And when you do terrains you are probably going to want to learn terrain collision which is unique amongst the types of collision. Otherwise, you'll have a ghost terrain that you float through which I find is what they have 99 times out of 100 in terrain tutorials that you are likely to find out there. They may teach some advanced HLSL technique for making the terrain and then fail to tell you how to make it solid. The subject of terrains can get pretty vast.

Somewhere along the way here, you're going to want to learn how to use an index buffer in order to reuse vertices in the vertex buffer. That cube has 3 vertices for every triangle or 6 per side, which is 36 vertices. Obviously you only need 8 vertices to make a cube since you're using the same vertex over and over. As long as you can do flat shading, you can use the index buffer to reduce it down to 8 vertices for the cube. More advanced models have even greater savings.

You're probably going to get into a lot of other more advanced topics almost on accident as you do this like Rasterizer states and such.

Maybe Then You'll Be Ready for HLSL or GLSL

You probably don't want to mess with HLSL until at least this point, if you can help it. (GLSL for OGL. And DX doesn't give you a lot of choice unless you can find a framework that will do shaders for you. You pretty much have to jump straight into HLSL from the beginning with DX11.) Vertex buffers are what feeds HLSL. So, figuring that out first makes it easier to understand what HLSL is actually doing.

Also, all the matrix stuff works exactly the same for vertex buffers. The model class is using vertex buffers under the hood. So, when you're using vertex buffers you're basically making models by hand or procedurally, like with a terrain. And so most of what applies to models applies to vertex buffers especially the matrix stuff. With a vertex buffer model that is stationary like a terrain, you don't need a world matrix and can pass an identity matrix if the shader requires one. But if you want to move the object, you use a world matrix with the vertex buffer just like any other model.

You may want to explore lighting although this may get into HLSL. In XNA, BasicEffect can allow you to explore the lighting topic a little without HLSL.

If you get that far, I would say you've pretty much mastered the basics and you're ready for intermediate level stuff. And the intermediate level stuff can be learned in almost any order.

On to Intermediate Level Stuff


This is about the time to get into HLSL. You'll want to learn about Render Targets and Post Process Effects using HLSL. You will want to learn about particle effects. And you'll want to learn about bill-boarding. You could probably make vegetation for your terrain using models, especially for trees. But even AAA games use bill-boarding for vegetation in the background of the scene. Grass and weeds are often made of a couple transparent quads that cross one another; learning this technique is important and requires a greater understanding of rendering transparencies since there is a problem with rendering transparent objects that are both "in front of" and "in back of" a transparent simultaneously. You'll want to learn to use invisible collision objects to trigger events whether you click on them or move inside of them. This can be used for a lot of things. In Fallout New Vegas, you usually click on a door that has an invisible collision object that you are actually clicking on which changes the whole game to another scene such as the inside of a building.

Animation

Rigid animation is maybe a beginner to intermediate subject. Skinned animation builds on that and is more of an intermediate to advanced subject, especially when you get into everything that goes into making a rigged and skinned model in the modeling program and subjects like inverse kinematics.

Baked Lighting

Baked lighting is something you need to learn probably early in the intermediate stage. It's the most basic form of lighting and shadow. It's the most efficient and least resource intensive. So, it's going to be around for a long time although there are more advanced ways to do lighting and shadow now days in real time. In the early days, baked lighting was pretty much all they had.

Shadows and lighting are at least an intermediate level subject and maybe are pushing towards advanced. You're using HLSL and combining all sorts of things you've already learned from vector math to render targets and so forth. The easiest is to just have a transparent blob quad you draw on the flat ground below the object. Lots of games have used this. Shadow maps and Shadow volumes get into the more advanced stuff as does most of the lighting stuff. Surprisingly, light and shadow are two entirely different almost unrelated subjects in game programming. This is where you start getting so far out that no one can help you because you know more than just about anyone else you meet on the subject. You've certainly surpassed me if you full understand these subjects.

And then the Sky's the Limit

Anyway, there's a whole host of subjects to explore by the time you get to the intermediate level. You can pretty much explore them in any order as you see fit.

This post has been edited by BBeck: 29 June 2015 - 08:58 PM


Is This A Good Question/Topic? 5
  • +

Replies To: Learning 3D Game Programming: A Road Map

#2 modi123_1  Icon User is online

  • Suitor #2
  • member icon



Reputation: 13493
  • View blog
  • Posts: 53,896
  • Joined: 12-June 08

Re: Learning 3D Game Programming: A Road Map

Posted 29 June 2015 - 02:09 PM

You may want to cycle back through that and underline or highlight key concepts and terms.
Was This Post Helpful? 0
  • +
  • -

#3 BBeck  Icon User is offline

  • Here to help.
  • member icon


Reputation: 792
  • View blog
  • Posts: 1,886
  • Joined: 24-April 12

Re: Learning 3D Game Programming: A Road Map

Posted 29 June 2015 - 02:11 PM

Ok. Thanks. I'll take a look at that.
Was This Post Helpful? 0
  • +
  • -

#4 _AB  Icon User is offline

  • New D.I.C Head

Reputation: 1
  • View blog
  • Posts: 10
  • Joined: 31-July 15

Re: Learning 3D Game Programming: A Road Map

Posted 02 August 2015 - 12:16 AM

Great topic. I wish someone would've told me this back when I was starting out. 2 thumbs UP !!
Was This Post Helpful? 0
  • +
  • -

#5 BBeck  Icon User is offline

  • Here to help.
  • member icon


Reputation: 792
  • View blog
  • Posts: 1,886
  • Joined: 24-April 12

Re: Learning 3D Game Programming: A Road Map

Posted 02 August 2015 - 06:27 AM

Thanks! Yep, I wish someone had of told me this stuff when I started out too. I spent so many years wondering around in the wrong direction and discovered most of what I know through years of trial and error mostly.
Was This Post Helpful? 1
  • +
  • -

#6 astonecipher  Icon User is offline

  • Too busy for this
  • member icon

Reputation: 2330
  • View blog
  • Posts: 9,381
  • Joined: 03-December 12

Re: Learning 3D Game Programming: A Road Map

Posted 02 August 2015 - 08:35 AM

I suggest pinning this. Great post BBeck!
Was This Post Helpful? 0
  • +
  • -

Page 1 of 1