By:
On:
In: Gaming, Graphics, Review

CreatingArtGame

Creating the Art of the Game by Matthew Omernick was a quick and easy read. However, I wish I had noticed the age of the book (and also the age of the reviews on Amazon). This book is seriously dated, and it has not aged well. Although some of the topics are still applicable, and lot of the stuff he talks about is ancient in the game dev industry. All things considered, it’s not necessarily a bad book, it’s just not very useful at this point.

The book covers a number of fairly basic topics regarding art creation for video games. Some of what is discussed includes: gathering reference, modeling theory, texturing, lighting, user interface, and tips and tricks. It became clear a few short chapters in that this book was really geared at beginners. I mean total beginners, as in still in high school, no experience whatsoever. Had it not been so dated, I could still recommend it to high school students. The only problem is that a lot of the content is not very useful anymore. He talks a lot about things like vertex lighting (saying per-pixel lighting is to intensive for real-time use), faked shadowing using square/circle textures, planar reflection by duplicating and flipping geometry, etc. These are all pre-shader era techniques and are somewhat amusing to look back on.

Omernick refers to the Playstation 2 a lot (the popular console at the time) and makes some interesting predictions about what the “next generation” (now the last generation) would be able to do. Clearly the guy has worked in the industry and knows what he is talking about. It’s just that the state-of-the-art has advanced considerably in the past 10 years, and this book does not stand the test of time. However, I did learn a trick or two regarding texture creation (which fundamentally has not changed much) so I don’t feel too bad about spending a few days reading this book.

Unfortunately I don’t think I could recommend this to anyone at this point, given the beginning level and dated content. No worries, on to the next book.

By:
On:
In: C++, Physics, Review

Game Physics Engine Development

In this review, I will discuss my experience with Game Physics Engine Development: How to Build a Robust Commercial-Grade Physics Engine for your Game by Ian Millington. This is actually the first book I’ve ever read solely on game physics and I think I made the right choice here. Although I have developed several physics engines previously, they were only in 2D and the extra dimension complicates matters significantly. Game Physics Engine Development is a book specifically about 3D game physics, though the author does make a short reference to 2D physics at the end. I felt like the book had just enough math to explain the concepts, without getting bogged down in technical minutia. I also enjoyed the friendly writing style, the approachable implementations, and a rational coding standard.

Ian Millington’s book covers a lot of ground, and each chapter builds up a single aspect of the engine. Many chapters could stand alone in one aspect or another, though they do come together at the end. Some of the topics covered include: basic 3D math (vectors, matrices, quaternions), laws of motion, particles, rigid bodies, mass aggregate physics, springs, collision, contact resolution, velocity and acceleration, torque, friction, broad-phase collision detection, bounding volumes, and more. While the book is “only” 552 pages, there are a ton of things packed into those pages. I found the coverage to be fairly in-depth, without getting lost of mathematical proofs or anything like that. The book is very practical in that way, and a lot of the code samples could easily be the basis of a real implementation.

Overall I enjoyed the book at lot, and breezed through it within a week, eagerly anticipating each new chapter. Being the only physics book I’ve read so far, I don’t feel 100% confidant creating a physics engine myself just yet. However, I do feel it has explained a lot of key concepts necessary in physics development. The book was everything I was hoping for, and gets my recommendation.

By:
On:
In: Graphics, Review

Digital Modeling

There is no question, Digital Modeling by William Vaughan is a book every 3D modeler (or aspiring modeler) should read. It really captures the essence of what makes a good model, and doesn’t get bogged down with technical details of specific modeling packages. In this review, I will briefly go over why I think everyone with any interest in 3D art should pick up this book.

At 432 pages, it’s a pretty light read. The author, William Vaughan, presents the material almost as you’d expect a teacher or a mentor to pass knowledge onto his students. He’s clearly an accomplished artist, and provides some anecdotes on projects he has worked on. I really like the style, and it made for a very comfortable reading.

There are a variety of topics covered including: what 3D modeling is, what roles are required in a 3D production, how to prepare before you model, fundamentals of 3D, modeling techniques, tutorials for creating 3D text, a realistic head, and a full stylized character, digital sculpting, game modeling, and 3D printing. Most of the chapters are not very long, and are very approachable for any skill level. I especially enjoyed the realistic head tutorial, as this is one of the hardest things to get right. His technique in this chapter almost made the task seem easy, and I am excited to try this out on a real project. I also very much liked the last chapter, which discussed how to get a job in the industry. This will be a lot of help for college students or other people trying to break into the industry, and he gives some good tips you may or may not learn in school.

Overall I was impressed with Digital Modeling by William Vaughan, and cannot give it anything other than a glowing review. What’s great is that he makes no assumptions about what tools you are using. The techniques in this book can be applied to almost any 3D package out there. In this way, I feel the information is more fundamental than other books, which concentrate too much of the specifics of one particular application. In addition, the photos on the Kindle e-book were top notch, large, and high resolution color images (unlike some other books, which skimp out on the quality).

If you have even a passing interest in becoming a 3D modeler, you owe it to yourself to pick up this book. Highly recommended.

By:
On:
In: 3D Engine, C++, DirectX, Game Engine, Graphics

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.

By:
On:
In: 3D Engine, Game Engine, Graphics, Review

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.

By:
On:
In: 3D Engine, C++, DirectX, Game Engine, Graphics

Spent the last couple days adding in skybox support into the engine. Currently it’s a little hard-coded, but it does seem to be working well. I also bumped the field of view (FOV) up to 90 (from 45) so you can see more of the sky. I wanted to make sure I was only using my own artwork for this engine demo. Unfortunately, it would have been rather difficult to take panoramic photos myself. So I generated the sky texture using Terragen. Somewhat of a cheat, but I did technically “create” it myself, so I can live with that.

Ran into one issue that had me stumped for about a day. Basically, I was following a tutorial for implementing the skybox. It seemed like I followed everything well, but I was getting this wild fish-eye type of distortion on the sky. As it turned out, it was my custom matrix transpose function that was at fault. The tutorial used “XMMatrixTranspose()” but I re-implemented this myself. The trouble was, I was swapping around the values without creating a temporary copy first. Meaning, I was doing something like this: 

m12 = m21;
...
m21 = m12;

Clearly that won’t work. The interesting part is that I got stuck on it one night and couldn’t figure out what was wrong. I knew it had something to with the matrix math, but I wasn’t sure what. So I left it alone and went about my day. Then, while in the bathroom washing my face, I had a “eurika!” moment and the answer came to me. Not sure how that works, if it’s like a sub-process in my mind or something cracking away at problems. But I’m glad I finally caught the error.

There are a few things I’d like to try next. First off, the lighting model could be improved great. Right now it’s just a hard-coded ambient and directional light. I’d like to have a more flexible system to add any type of light into the scene graph and have the shader support it. Support for normal mapping would be cool, as well as specular and emissive textures. I’d also like to do some initial experiments in building a physics system, or at least learn more about compute shaders and how they integrate into the pipeline. Plus, better artwork. Stay tuned.