Subscribe to the RSS Feed Add to Google

3D Engine - Basic Concepts

August 29, 2008

As you probably know by now, I'm making an indie 3D engine, and last time I talked about the abstraction layer for accessing the 3D hardware. This time, I'm going to talk a bit about the basic concepts of the higher level engine, touching on things like meshes, materials and the scene graph.

It's always difficult to judge what level to start at when discussing these matters. Some people know a lot about 3D already, others might be beginners... and considering how poorly defined the terminology is in the field of game development, misunderstandings are not uncommon. So, I'll skim through the very basic stuff as well, just to make sure we're on the same page.

Definition of Vertex, Edge, Triangle and Mesh

This figure shows a triangle and part of a mesh. A triangle is made up of three points (called vertices), and if you draw a line from one vertex to another, you get what is called an edge. The area contained by three connected edges is the actual triangle. In a 3D engine, everything is made up of triangles, and if you need more complex shapes, you always build them by combining triangles. This is because 3D hardware works with triangles, and all a 3D graphics card really does, is provide a way of drawing lots and lots of triangles really really fast (the more modern cards can do it in a very flexible way, using programmable shaders, but it still comes down to drawing triangles).

There's no definitive name for a collection of triangles, but I've chosen to call it a mesh. In the above figure, you can see that a mesh is made up of a bunch of vertices and triangles connecting them. It would be possible to define a mesh in terms of a long list of vertex triplets, but as some vertices are shared between several triangles, that would mean that we waste a lot of memory by duplicating data (as you will see later on, a vertex can be quite large, as it contains not only a position, but also color, normal  and texture coordinate information). The common solution for this is to specify all the vertices in one big list (called a vertex buffer) and when specifying the triangles, to use the index of a vertex instead of the full vertex. So a triangle would be defined with three simple index values rather than three complex vertex structures. If you look at the platform abstraction layer I defined last time, you'll see that there's functionality for creating vertex and index buffers, as well as a Render method which allows us to specify which vertices and indices to use from the specified buffers.

Mesh Definition

So, the way I define a mesh, is as a collection of vertices and indices, along with a material, as pictured in the above figure. This means that all the triangles in a mesh are rendered using the same material, and it also means that it's not possible to move one part of a mesh in relation to the other parts (for example, spinning the wheels on a car). This means that some models will need to be made up of several meshes, but that's fine - we can deal with that. But it also means that a mesh can be rendered in one go.

Few models are simple enough to be made up of only one mesh. You often want to use different textures on different parts of the character, or you might want parts of the model to be able to move independently of the others (like the wheels on the car). The way we'll be making that possibile, is to create a hierarchy, or tree structure, of nodes.

Node Definition

In the above figure, you will see the contents of a node. Each node has a name, which will be useful to identify the different parts of a model, and it also has a transform, which is a description of the nodes position and rotation relative to its parent node. A node might have any number of child nodes, which can be either nodes themselves, or meshes (as defined earlier).

There are some nice things about structuring things this way, as we will see later on. A model will be defined as just a node, and the entire scene (everything we render) will also be just a node. To add a model to the scene, we just add the models node as a child to the scene node. If we have a model of a car, and a model of a driver we want to attach to it, we would just add the driver model as a child node to the car model, and the car model as a child node to the scene.

More on this next time, when I will talk a bit more about how we go from these basic concepts to actually rendering it using the platform abstraction layer. And if anything is a bit unclear, just post your questions as a comment and I'll do my best to clarify.


   Digg this Digg this    submit to reddit Add to reddit

<< RetroBox - The Specification
RetroBox - The Processor >>


Comments

Mosfet
2008-12-28 01:52:47
\\\"it also means that it\\\'s not possible to move one part of a mesh in relation to the other parts (for example, spinning the wheels on a car).\\\" You can explain in more detail \\\"why\\\" and \\\"how\\\" it is NOT possible to move one part of a mesh in relation to another? You can said it can moved if we used nodes. Whats the difference? Thank you so much for the lovely tutorials
Mattias
2008-12-28 03:12:41
Well, it's like this: If you make the car and the wheels part of the same mesh, you can't move the wheels separate from the car. But if you make the car and the wheels separate meshes, but part of the same model, you can move the car node and the wheel nodes independently.

When it comes to the games industry, there's no common terminology, so everyone makes up their own precise definition for the words they use. In my engine, I make a distinction between model and mesh, while other engines might have the two words mean the same thing.

In my engine, a mesh is defined as a bunch of vertices/indices and a material, with no position in the world. A model is defined as a hierarchical structure of nodes, which each have a position and can contain child nodes (and some of those child nodes might be meshes).

In order to move a mesh, you change the positional information of its parent node, since a mesh doesn't have any positional information in itself. If you made the wheels and the car part of the same mesh, you would only have one parent node for the whole mesh, and therefore could only move the whole thing as one unit. But if you make them separate meshes, you will have different parent nodes for each mesh, and thus you could position the wheels independently from the car.

Further, if you made the meshes for the wheels child nodes to the mesh of the car, you could change only one node (the parent of the car mesh) to move both the car and the wheels around, while you could still spin and turn the wheels by adjusting nodes deeper down the hierarchy, the child nodes of the car mesh (the parent nodes of the wheels).

Hope this helps
Mosfet
2008-12-30 08:11:06
Wow fantastic explanation! Thanks a lot for the reply! You are such a great teacher. I enjoyed your lightmap and vertex lighting tutorials as well. In future is it possible for u explain terms like normal maps and relate things like say what diffuse means, gloss maps, specular lights, more detailed types of lights. You know the stuff we newbies to gamedev need to know. Thank you
Mattias
2009-01-01 03:04:21
Well, I will continue to work through those concepts I think are important for making 3D games, but there are some things (like normal maps and gloss maps) which I think are not only unnecessary - they are the cause of making potentially good games bad.

Whevenever people start messing about with advanced rendering techniques and shaders, they get distracted from what really matters - making a fun game.

Remember, writing 3D engines and shaders is easy stuff. Writing games is hard, so don't focus on the visuals - just make them "good enough", and then focus on making the game fun. And for that, you don't need normal maps or shaders, which is why I'm not planning to get into things like that. As far as I'm concerned, they're a dead end when it comes to games (though the AAA games industry will stick with fancy visuals of course, but they're not actually making real games anymore...)

/end of rant :D
Mosfet
2009-01-03 07:54:27
Lol truely said! I do miss the days of arcade games like Commander Keen etc. I mean you are so right, the game play was those days was sooo addictive. "just make them "good enough", and then focus on making the game fun" You made me remember those real fun filled days of games. I Will try to make them more fun! :-) Thanks
Mattias
2009-01-03 10:37:11
Great, nice to see there are still some people who agree with this :-)

You'd be amazed by how many people I met while working in the games industry who just didn't get it, who thought the visuals and effects was the important bit, and who just ignored gameplay...

Good luck with your games, make sure to post here once you've finished one, would love to check it out :-)

Write a comment








Video Games BlogRankers.com Video Games blogs Directory of Video Games Blogs Blog directory Game Blogs - BlogCatalog Blog Directory Free Page Rank Tool Bloggtoppen.se Blogg om Bloggar.Topplista.se - topplistan med de bästa bloggarna - lägg till din blogg du också! My Zimbio DigNow.net

© Copyright Mattias Gustavsson 2008. All Rights Reserved. Reproduction/republishing of any material on this site without permission is strictly prohibited.