3D Engine, Game Engine, Math, Programming, Review

Review: Foundations of Game Engine Development, Volume 1: Mathematics by Eric Lengyel

Volume 1 Mathematics

I’ve always been a big fan of Eric Lengyel, from both his work on the C4 Engine (and now the new Tombstone Engine) and his previous math book, Mathematics for 3D Game Programming and Computer Graphics, which is on it’s 3rd edition and is one of the definitive texts in the genre. This latest book, Foundations of Game Engine Development, Volume 1: Mathematics, I feel does it again and is well worth reading.

The text, which clocks in at around 200 pages (short for a technical book) actually has a decent amount of information crammed into those pages. Lengyel breaks it up into 4 chapters, each focusing on a different aspect. Chapter 1 starts with vectors and matrices, then continuing to transformations, next to geometry and the finishing chapter on advanced algebra. The first 3 chapters are about what you’d expect from a game math book, but explained clearly and succinctly. Early in the book, when discussing vectors, the author states: “Loosely speaking, the dot product provides a measure of how much one vector is like another.” Though it seems obvious now, I’m not sure I’ve ever heard it explained quite as clear before. Much of the rest of the coverage in the first 3 chapters feels like this. While it may be a refresher to many, it’s like seeing some of these concepts in a new light just from the stellar delivery.

As I mentioned, chapters 1 through 3 cover the basics, that most game programmers are likely familiar with. Vector and matrix operations, transformation spaces, finding relations between points, lines, and planes, etc.  I’d consider this to be a good refresher for people at least somewhat familiar with game mathematics. Though I could also see it as an decent introduction for some, there may not be enough hand holding for a complete novice.

However, in chapter 4, Lengyel dives into new territory with Grassmann algebra. Though the math is very old, I’m not sure I’ve ever seen it covered or mentioned in any of the popular game math books I’ve read. The concepts are actually quite interesting, and seem to tie together some different areas that originally seem disparate. To be honest, I think I’d have to read this chapter a second time for the concepts to really sink in. It did make some sense but, being somewhat new material to me, I wasn’t sure how I’d immediately apply the knowledge. That said, I applaud the author for bringing something new to the table and I can’t imagine it being described better.

One part I really did appreciate were the code listings, shown in real C++ code that, while I did not type them in a computer and compile, seem like they would be ready to basically lift off the pages and use in a project. I also very much liked the coding style, which felt clean and modern, unlike some other books I’ve seen where it looked like the code came from a 1980’s mainframe.

Overall, I very much enjoyed this book. It was able to cover basic game mathematics in an extremely clear and concise manner, and introduce new concepts along the way. I think this would make an excellent edition to any game development library. While the book was refreshing at only 200 pages, that brevity meant that some concepts could have been in more depth, and other topics weren’t covered at all. For more thorough coverage, I’d look to  3D Math Primer for Graphics and Game Development by Fletcher Dunn or to Lengyel’s prior book, Mathematics for 3D Game Programming and Computer Graphics. That said, whatever your skill level, I think Foundations of Game Engine Development is a worthy read.

3D Engine, Graphics, Tutorial, Unreal

Tutorial: How To Make a Cube Roll On A Grid in Unreal Engine 4


In this tutorial, I will show how to make a cube roll from side-to-side on a grid. This project took me around 3 days to complete, though much of that was wrapping my head around basic things in UE4. Some of the areas explored here include setting up key bindings and action mapping, setting and clearing timers, and rotating around an arbitrary point.

First, you want to start by setting up the action mapping. What this does is basically binds an input button (like a keyboard key) to a particular action (really just a name that you make up). For this test I needed 4 keys for up, down, left and right. Since the arrow keys and WASD were already used by the default Unreal fly camera, I choose to employ the IJKL keys to move the cube around. These options are found in “Settings->Project Settings->Engine->Input->Bindings”.

UE4_Cube_Grid_01

Next, we will need to connect those actions to a function in order to make something happen on the screen. You can do this by creating an “InputAction” Blueprint and choosing the name you created (like “Action_Up”). I set these actions to call a function I created for this example called “StartMoving”. In some cases, you may want to bind the action to a custom event, which may simplify the code and allow for a cleaner Blueprint (as you can use events to effectively “jump” to other points in the same Blueprint without a line connecting them). In this case, I had to pass in some state (to know which direction the cube is moving) so using a function was better suited for the job.

UE4_Cube_Grid_02

The “StartMoving” function is not that complex. All it does it check first if the timer is active (to avoid registering input while the cube is already moving), save some state on the cube itself (the direction of movement and it’s last position), and then creates a timer to handle the animation.

UE4_Cube_Grid_03
The key part is the creation of the timer itself, using “SetTimer”, which is shown below. You can think of a timer as spawning another process or thread that can run concurrently with your main logic. The timer just calls a function of your choice (“MoveTween” in this example), at a specified time interval (use 0.0166 for a 60Hz animation cycle, which looks smooth enough). You can also set whether it loops or not, we use looping in this case.

UE4_Cube_Grid_06
Finally, we have the “MoveTween” function, which is what is called by the timer and what does all the math calculation to rotate around a particular axis and point in space. It’s also what animates the cube, and clears the timer at the end itself. It’s very useful to be able to spawn a timer, and then have it terminate itself when necessary. The full function is shown below.

UE4_Cube_Grid_04

Really, the core math of the method is done by two function included in UE4, “RotateVectorAroundAxis” and “RotatorFromAxisAngle”. We first create a axis based on the movement direction. Then we subtract the pivot point (in our case, the bottom edge of the cube), rotate around that axis, and then add the pivot point back to the location. The rotation around axis logic is actually based on an example shown on the Unreal Answer Hub, though it was modified to fit my purpose.

UE4_Cube_Grid_05

And that is basically it. I’ve even included the full project file below for you to download and experiment. I imagine this type of motion could be used for a type of puzzle game created in Unreal Engine 4. Download Link: UE4.7.4 Cube Motion Project Files

3D Engine, Graphics, Tutorial, Unreal

Tutorial: How To Make a Textured Spinning Cube Using Unreal Engine 4


 

Today I will show how to create a textured spinning cube using Unreal Engine 4. Making a cube spin is basically what I consider the “litmus test” of 3D engines. How long it takes you to figure this out will show how convenient or capable the engine is. While I might have skipped this test (by jumping straight into creating Pong) I thought it was worthwhile to go back and try it. Hopefully this tutorial will be helpful to some of you just getting started.

UE4_Rotate_Cube

First thing you should do is create a new blank project. I chose to make the project with the starter content (and deleting the furniture) however that won’t be important for this guide. Next look on the left-hand panel, make sure you are in place mode (the icon with the cube), and look under basic and find Cube. Now drag the cube into the scene. It will probably start inside the floor, so just press Q to go into move mode and then drag it up a little.

UE4_Rotate_Import

Since looking at a gray model is not that exciting, lets add some texture. In the Content Browser on the bottom, right-click in the empty area and select “Import to /Game…”. Then find your image file and press Open.

UE4_Rotate_Tex

You should see the new texture appear in the browser. Now drag this texture onto the cube model. You’ll see this automatically create a default material for you. With the cube still selected, click “Movable” in the Details panel on the right.

UE4_Rotate_Comp

The next step is to create the component Blueprint. You can do this by clicking the green “+Add Component” button on the top of the Details panel. Choose “New Blueprint Script Component”. In the pop-up window, pick Scene Component, click Next, type a name in, then click “Create Blueprint Class”.

UE4_Rotate_BP

In the new Blueprint window, you can delete the “Event Initialize Component” (though you can also leave it alone, won’t matter in this case). Pull off the output execution pin on “Event Tick” (it’s the white arrow looking thing on the upper-right). You should see a menu open. Start typing “rotation” and then pick “Add Relative Rotation”. In the Y field for “Delta Rotation” type in “1” and press Enter. Pull off the “Target” pin and type “parent” then click “Get Attach Parent”. Now you can save and compile the script.

UE4_Rotate_Play

Switch back to the main editor window and press “Play”. That’s it! Hopefully this tutorial was useful to some people (please let me know in the comments). I plan to produce more of these in the future, and they should gradually get more complex as I get more familiar with the engine.

It’s really quite amazing how quick and easy it is to work with Unreal. Using straight C++ and DirectX, one would be lucky to make a textured spinning cube in 2 hours, let alone 2 minutes. It really speaks to the robustness of the engine. Of course, I still have a long way to go in terms of learning the engine, so please follow me on this journey (and pray I don’t give up on this one).

3D Engine, Game Engine, Gaming, Graphics, Unreal

Making Pong in Unreal Engine 4 (My Very First UE4 Game!)


 

Today I’d like to unveil what I’ve been working on for about 2 weeks: Pong in Unreal Engine 4. Most of that time was spent reading documentation and watching tutorial videos just to figure out the basics. There is actually a *lot* of good material out there for Unreal Engine 4, the docs have been helpful and there are plenty of videos. Disappointingly, there are barely any books out there for the engine, but I’m sure that will change quickly.

Pretty much anyone will tell you, when you are learning to develop games (or switching to a new engine/platform), the best thing to do is to start small and try to complete something. It’s really silly to try to make an MMORPG as your first game (I have fallen for this one!) and even relatively simple things can become complex fast when you are not familiar with the platform. So I chose to do Pong as my first excursion into Unreal 4. It was not without some trials, but I made it through alive. Oh, and, no. This will not be considered my “finished project of the new year”. There are some other, cooler, things I have in mind.

Previously I was making multi-part blog posts with basically quick status updates. This was fine, but I think it will be more helpful for the community for me to do focused tutorials on a specific topic and post those more frequently. I learned quite a lot about Unreal with this project, and I think I can share some of that on this site. Some of the things I picked up working on this demo include: importing assets, working with Blueprint, basic flow and logic, movement, collision, HUD, events, keyboard control, functions and variables, and just getting familiar with the Unreal Editor interface. Not sure I will make tutorials on everything, but I plan to break this into a few posts. Below you can see the level Blueprint for the game, just to give you an idea of the complexity.

UE4_Pong_BP

Overall I have been impressed with Unreal Engine 4, and I can’t imagine purchasing a more capable piece of commercial software for less than the pennies they are giving this away for. People can complain about the 5% royalty but, really, if you get to the point where 5% is a significant dollar amount, you will be rolling in the the dough and shouldn’t care if Epic wants a piece of the pie. Cost aside, I do like the engine a lot. Granted, I ran into some bugs, and more crashes and stability issues than I’d care to admit. At one point, the project saved in a corrupted state and I was blocked from even opening it at all. Luckily, I was able to update the engine and convert the project, but I was sweating pretty hard for a little while. That said, I’m sure this can be improved in time and it didn’t stop me from developing (I’d just recommend using source control and committing often).

The visual programming system, Blueprint, is very powerful and I used that alone for this demo (no C++). I did start checking out the C++ support and it seems to add some extra power and flexibility, but I haven’t got that far yet. However, I can see building some simple games and experiences using the visual coding by itself. This is also great for designers, who may be able to rig up some basic stuff themselves. Keep in mind, it’s still programming (just not with text). You have to understand the basics of logic and control flow and, in some ways, it may even seem alien to veteran programmers. I know there were definitely a few cases where I had a non-trivial amount of nodes and connections and thinking “I could have done this in 1 line of code”. Once I got beyond that, I think I may prefer it to coding manually, as it’s much harder to make mistakes (or to create stuff that doesn’t work).

I hope to continue working with UE4 in the future and I’ll continue updating my blog as I make major developments. Thanks for watching.

3D Engine, C++, DirectX, Game Engine, Graphics

Creating a 3D Game Engine (Part 25)

So it comes with great reluctance but I think I will have to suspend development on my 3D game engine, at least for the near future. Surely this will be a disappointment to anyone following the progress and I did not make the decision lightly. After spending some time thinking about it, I think it’s the right move. It’s just really hard to justify the amount of time and effort put into this when there are much better solutions available off-the-shelf.

In the little less than 2 years I’ve worked on this project, I think I have made decent strides. Honestly, I was not working on it full-time. Just on weekends mostly or maybe here and there when I had time after work. My initial goal was to have something functional in about 6 months to a year. It took a little longer, but I guess eventually I did have the basic features of an engine somewhat working. I will list what was implemented below, but it was enough to load in some textured models and fly a camera around. Not ground-breaking work by any means, but I built nearly everything myself so I was happy about that. There was just an enormous amount of work remaining to get to a state where a game could be produced. Finally, it was too much.

So before I give my personal advice, I’ll break down how I got to this point. First, let’s look at all the books I read as research for this project:

Game Engine Architecture – Jason Gregory
Game Coding Complete, Fourth Edition – Mike McShaffry
Real-Time Rendering, Third Edition – Tomas Akenine-Moller
Game Engine Design And Implementation – Alan Thorn
3D Game Engine Programming – Stefan Zerbst
Game Engine Gems, Volume One – Eric Lengyel
3D Game Engine Architecture – David H. Eberly
3D Game Engine Design –  David H. Eberly
3D Math Primer for Graphics and Game Development – Fletcher Dunn
Mathematics for 3D Game Programming and Computer Graphics, Third Edition – Eric Lengyel
Introduction to 3D Game Programming with DirectX 11 – Frank Luna
Practical Rendering and Computation with Direct3D 11 – Jason Zink
Beginning DirectX 11 Game Programming – Allen Sherrod
Game Programming Patterns – Robert Nystrom
Game Physics Engine Development – Ian Millington
Physics for Game Developers – David M Bourg
Physics for Game Programmers – Grant Palmer
Game Physics Pearls – Gino van den Bergen
Shadow Algorithms Data Miner – Andrew Woo
The C++ Programming Language, 4th Edition – Bjarne Stroustrup
C++ Primer (5th Edition) –  Stanley B. Lippman
C++ Primer Plus (6th Edition) – Stephen Prata
More Effective C++ – Scott Meyers

If you are considering engine development, please read on, but I believe all the above books are valuable to look at. I’ve also read a variety of sources online, from tutorials to official documentation and more. Looking at that list it seems huge, but I am an avid reader and have read and listened to a number of non-technical books in that time-span as well.

Next, let’s look at what features were actually implemented and working (or mostly working):

  • Win32 app template (message pump)
  • DirectX 11 based rendering engine
  • DirectInput mouse and keyboard controls
  • Custom math library (Vector, Point, Matrix, view/projection)
  • Node-based hierarchical scene graph
  • Frustum culling (sphere and point tests, minimal bounding sphere)
  • Generic XML parser (from scratch, kind of hacky and slow)
  • COLLADA importer (only basic vertex and UVs)
  • Custom binary 3D model format (for speed)
  • Camera object (spectator mode)
  • Texture mapping and Skybox (cube mapping)
  • Directional, ambient, and specular lighting
  • Normal and shadow mapping shaders
  • Command-line console window logging
  • Architectural glue and probably some odds-and-ends.

So what wasn’t finished? Way too much to list. I don’t want to get down on myself too hard, cause I think that I accomplished a little something here. Certainly some of this stuff was not easy and, if anything, it has made me a better coder. Even in the current state I guess you could make a Pong game or a simple walk-through demo or the like. Also keep in mind this was a part-time excursion. If I were dedicated to this fully it probably would only have taken months (not counting research time). While I started with a very clean style and deliberate design, by the end I was kind of hacking things together, and some features (like the shadow mapping) became very intertwined with the core rendering code. Of course, this was very much a learning experience, and I planned to go back and clean things up later (which may or may not ever happen, we’ll see).

OK, so by now you are probably getting the idea. As to my advice, if you are trying to make a game (or game-like interactive experience) don’t bother making a custom engine. Everyone basically told me this from the start, and I didn’t listen. It’s sort of like when you see people doing stunts on TV and they tell you “don’t do this at home.” But they did it, and it made them rich and famous. So maybe I was looking for glory, or hoping finishing a big project like this would take me to another level. I guess in a way it did. I’m just not sure that was the best use of my limited time. What I mean to say is that knowledge is valuable, and I feel I learned a lot. However, unless you are really looking to be an engine programming professional, there is not much reason to try to do this.

The crux of the matter is that all-in-one engines like Unity and Unreal are just too complex and mature to expect to compete with. That’s not to say a small team or a single hero-coder can’t produce something great. They can. However, using a pre-built engine cuts out a *lot* of time and risk. Had I been working on a project for a client, I would have never even contemplated a custom engine. It just doesn’t make sense. Both Unreal and Unity have huge teams of expert engineers working solely on engine development. Unless you work for a huge AAA studio with a monster budget, I just can’t see coming up with something better in any reasonable amount of time. Even some huge companies (like Capcom and Square-Enix) are dropping in-house engine development for Unreal 4. Not a good sign for indies or bedroom coders working on their own engines.

But let’s say those big engines aren’t for you. There are a number of open-source engines and libraries out there to help you along. Something like Torque or C4 look promising (if you want a full-featured solution), or OGRE (if you don’t mind having to cobble together a bunch of different libraries). If you are interested in web publishing there are things like three.js for WebGL. With source access you can add the features you need or fix critical bugs. Really there are too many options to ignore.

For the last few weeks I’ve been playing with Unreal Engine 4, and it basically does everything I need and a whole lot more. At $19/month and a small royalty (if you sell your title) making a AAA looking game has never been more affordable. Unity may still have a leg up on ease-of-use and scalability on different platforms, but for high-end development I think Unreal is probably the one to go with. Having the source-code is a huge boon, and the price makes it attainable to almost anyone. Plus, with the visual scripting, Unreal can even be approachable to artists and designers. I’m still in the early stages of getting acquainted with the engine, but so far I am pleasantly surprised. I plan to follow up with some posts and tutorials in UE4 in the future, so don’t think this is the end of my blogging career or anything of that sort.

With all that said, there are still some things I’d like to see in engines that don’t exist today. You typically can’t use the editor in stereo 3D (assuming the engine even supports 3D natively), motion control support for placing objects is non-existent, image and model editing is usually very rudimentary (you must switch back and forth to other apps), real-time code editing and previewing can be limited. So things can certainly improve, and I guess there could be a case made for making plugins or forks to existing projects. I’m not saying things can’t improve. Just that reinventing the wheel to make incremental improvements may not be the best path.

At this point I don’t think I would say engine development is a “waste of time.” As a learning experience, I think it was fun and rewarding. Certainly I hope I didn’t just waste 2 years of my life. Doing all the work and research has brought me here to this place. So it was somewhat worthwhile. It just pains me to think how far along I might have been had I jumped on Unreal 4 when they first announced the subscription model, or spent more time with Unity over the years. If you actually want to build (and finish) a game, it’s a pretty clear choice to use an off-the-shelf solution. I’m sorry, guys. I wanted to prove everyone wrong, but they were right. Make games, not engines.

Finally, I’m sure the question you’re thinking is “will I release the source.” I’m considering it, but there are some hacked bits in there and I’m not sure it’s a great example to work off of. More likely I will pull out portions or classes from the project and use them for future blog posts highlighting a particular algorithm or technique. The full source itself is probably less useful compared to other stuff that’s out there. In any case, I hope maybe you have learned something after 2 years and 25 posts on this project. If you click the (somewhat hidden) 3 white line icon on the top right of the blog, you can see a list of all the blog updates in this series for a little history (if you weren’t following the whole time). Cheers, and happy coding.

3D Engine, C++, DirectX, Game Engine, Graphics, Physics

Creating a 3D Game Engine (Part 24)


 

It’s been some time since the last 3D engine update, but I’m still sticking with it. Currently I am working on getting a physics engine implemented. The video you see above is the first glimpse of this custom physics engine. Obviously it’s ultra basic right now, but it’s a start. The algorithm is based on a verlet integrator, and the code is running using DirectCompute on the GPU.

To be honest, it’s pretty hacked together right now, and the bounds/bouncing behavior is hard-coded. But, hey, it’s something! I also tweaked the style of the demo to more closely align with other demos from researchers (and the clean flat-shaded style looks a bit more classy).

I’m planning on expanding this significantly, but still have a lot of work ahead of me. Though I’m still questioning whether GPGPU is the way to go with this, especially since there are 8-core CPUs available for consumers (and which I am running now). There is also added difficulty and limitations of DirectCompute rather than straight C++. But if there are big gains on the GPU obviously I would like to go that route. Definitely more testing to do here, but progress is being made. Stay tuned.

3D Engine, C++, DirectX, Game Engine

Creating a 3D Game Engine (Part 23)

engine_zero_08

While I implemented frustum culling a little while ago, I never actually coded a proper bounding volume. For the  bounding test I was using a sphere, but I just set the radius to some hard-coded value. This was fine when I just had a bunch of similar sized cubes on screen, however it broke apart once I started getting varied models imported. This week I decided to do something about it.

After a quick Google search for bounding spheres, I ended up on Wikipedia. There was some good information there regarding minimal bounding spheres (also known as smallest enclosing ball or minimal enclosing ball), and I was given a few options for different algorithms. After reading the whole page I become very interested in the “bouncing bubble” algorithm, especially due to the spiffy gif animation showing it in action. The brief explanation seemed easy to follow compared to the other methods, and the error percentage was only around 1-2% which is much lower than Ritter’s algorithm (which can be as high as 20%). So far so good.

Unfortunately I found next to nothing on the internet describing the method. What I did find is a post from last year on StackOverflow by someone in the same situation as me. This lead me to the original paper describing the method, which was for sale for $18 on Grin.com. Honestly I don’t mind paying the money for quality information if it’s going to help improve my engine. The article was fairly easy to follow, and provided just enough information to base the implementation on. At first I was disappointed that no source-code was given, but I managed to pull it together using the pseudo-code. All in all I think I spent about 4 hours on it (including research) so I’m happy to have got it working so quickly.

Below is my bouncing bubble implementation. Keep in mind I have not profiled this code, it’s possible it’s not fully optimized. However, I’m only doing the calculation when a 3D model is loaded, so it shouldn’t effect performance at all really.

BoundSphere RenderCore::calculateBoundSphere(vector<Vertex> vertices){
	Vector3D center = vertices[0].position;
	float radius = 0.0001f;
	Vector3D pos, diff;
	float len, alpha, alphaSq;
	vector<Vertex>::iterator it;
 
	for (int i = 0; i < 3; i++){
		for (it = vertices.begin(); it != vertices.end(); it++){
			pos = it->position;
			diff = pos - center;
			len = diff.length();
			if (len > radius){
				if (i < 2){
					alpha = len / radius;
					alphaSq = alpha * alpha;
					radius = 0.5f * (alpha + 1 / alpha) * radius;
					center = 0.5f * ((1 + 1 / alphaSq) * center + (1 - 1 / alphaSq) * pos);
				} else {
					radius = (radius + len) / 2.0f;
					center = center + ((len - radius) / len * diff);
				}
			}
		}
	}
 
	return BoundSphere(center, radius);
}

Also, I should remind myself to do benchmarks more often. After I added all the normal mapping and shadow stuff performance has taken a big it. Before I was getting likely over 2400fps, now I’m only getting around 1600fps. Still acceptable, but maybe could be better with such a simple scene. The culling definitely helps, but I may have to look into other optimizations like batching and instancing if I want to get the speeds I need for my project. I’ll probably get started with the physics engine aspect soon and then optimize later if I can’t meet my 120fps target. Cheers.

3D Engine, C++, DirectX, Game Engine, Graphics

Creating a 3D Game Engine (Part 22)


 

After struggling for a bit with the shadow mapping implementation, I finally have something presentable. I followed a tutorial from Microsoft and thought I understood what was happening. However, it required a lot of changes in the rendering code and it took a little while to get things working. Even once it was somewhat functional, I still had some issues with what they call shadow acne. It seemed really bad on the self-shadowing side of objects. I tried tweaking all the values I could (i.e. the bias in the shader), but I was not able to get it to look right. Finally I just set it so that there wouldn’t be self-shadowing of a single polygon. This happens to look fine, since the lighting equations make the polygon shaded anyhow. I’m not sure if this will work for every single instance, but with the simple models I’m testing with it’s fine.

I’m at the point where I really want to get the physics engine up and running. Still have some more research to do, so I bet it will take some time before I have something more to show. But it’s coming along.

 

3D Engine, C++, DirectX, Game Engine, Graphics

Creating a 3D Game Engine (Part 21)


 

After a few days of hacking away at the code, I’ve got a new video up. In this update I have added normal mapping and specular lighting. I did have a few set-backs while working on the shaders, and it was made even more difficult since I was basically “flying blind” without a debugger. It seems that the Express version of Visual Studio does not support shader debugging, and neither does Nvidia’s debugger tool. Very sad, and I may (at some point) have to upgrade to the Pro version. I’ll probably hold out for a little bit, and I did end up figuring the problems out this time.

With the specular lighting shader, the issue I had was doing the matrix multiply and output on a float4 instead of a float3. To be honest, I am not quite sure why it didn’t work, but switching things around seemed to help. The change I made was also follows.

output.normal = normalize(mul((float3x3)worldMatrix, normal.xyz));

Instead of:

output.normal = normalize(mul(worldMatrix, normal));

Again, not sure why that works, but I’m happy it does. With the normal mapping, there was a lot of math and changes involved, and it became difficult to find which piece was broken. As it turns out, all the math was (mostly) correct, but the values I was sending to the constant buffer were not being updated. From what I can tell, the pixel shader cannot read the constant buffer (cbuffer) but the vertex shader can. Strange, and I’m not sure why this must be the case. So instead of trying to read the cbuffer values directly from the pixel shader, I passed them in as output values from the vertex shader. In addition, trying to pass bool or int values to the pixel shader would not work. So, as a hack, I added the same int value to all parameters of a float3 and passed that instead. I bet I can figure this one out eventually, but I’ve already spent all day on this and I’m happy just to see something working on the screen.

Next up I will probably try to model something more substantial than a cube so I have something better to look at.

3D Engine, Game Engine, Graphics, Review

Review: 3D Game Engine Design: A Practical Approach to Real-Time Computer Graphics by David H. Eberly

3D Game Engine Design

3D Game Engine Design: A Practical Approach to Real-Time Computer Graphics by David H. Eberly was an quite a read, at slightly over 1,000 pages. However, after a few chapters in I was already getting fatigued and I really had to push my way to the end. That’s not to say that the book was bad, it was not, however it was nothing like what I expected. Let me explain.

Imagine you walk into a restaurant and sit down with a friend. After several minutes of thought, you decide to order a steak. The waiter comes, takes your order, and about 15 minutes later returns with a plate. Except when you go to eat, you realize he has brought you a grilled chicken instead. It’s not that grilled chicken tastes bad, it’s just not what you ordered. I feel the same way about this book. The title says: 3D Game Engine Design: A Practical Approach to Real-Time Computer Graphics, however there is very little to no design in the book, it’s not very practical, and there is not much coverage of computer graphics itself.

But at 1,000+ pages there must be some information in there, and indeed there is. However, it is almost 99% math. I don’t have a problem with math. What I do have a problem with is pages and pages of mathematical proofs, when an explanation of an algorithm would have sufficed. The math is just really heavy, and made even harder to follow due to formatting errors on the Kindle e-book. For example, some symbols would be replaced by squares, making them almost impossible to decipher. In addition, most of the equations and formula were images, but some were too small to read and difficult to click on. Again, making it hard to follow. For a technical book this is all but unacceptable, and makes it next to useless to base an implementation on. I found many times I was reading 2 or 3 pages into a proof and I just would forget what the formula was even calculating. It’s not that I am slow. I have read other 3D math books and had a good time. The explanations here are just somewhat lacking and dry.

The main gripe I have is that the design of a game engine is nowhere to be found. You would expect overviews of class structures, game loops, how to communicate between objects, event systems, scene graphs, encapsulation of graphical APIs, input abstraction, etc. Nope, not here. It’s not even until the end of the book, in chapter 18, that he even mentions OOP. Most of that chapter is general OOP concepts (that you expect anyone that made it that far into a book like this already knows) and at the end sub-chapter the author goes into some topics that I would consider game engine design focused.

Fine, but surely there is something to like. I will say that the coverage of certain aspects of core math of an engine were covered in-depth. Specifically, bounding volumes, collision/intersection detection, and distance testing were given good coverage. Just looking at the table of contents is deceiving because it appears that much more is covered. For example, there is a chapter on physics, yet it is only about 20 pages and is not very helpful at all. Only in the last chapter was really any graphical concepts covered and, again, it was brief and only scratched the surface.

I’m not sure what David Eberly, the author, is trying to do here. This is the second book of his I read, and I had the same complaints about that. The book was mislabeled and deceptive. Had he just titled it “Game Engine Mathematics” I would have been a lot happier. Granted, I may have purchased the book anyway, but at least I would have known what I was getting into. I wanted a design book, I purchased what I thought was a design book, and all I got were a bunch of mathematical proofs. Sorry, I am disappointed.

If you are looking to do research on 3D math then there are better, more approachable, books out there. See 3D Math Primer for Graphics and Game Development, by Fletcher Dunn and Ian Parberry or Mathematics for 3D Game Programming and Computer Graphics, by Eric Lengyel. If you want a game engine design book then Game Engine Architecture by Jason Gregory has a great overview and 3D Game Engine Programming by Stefan Zerbst is better for implementation. Honestly, there could be more books in this field. Unfortunately, 3D Game Engine Design doesn’t fill it’s own shoes.