Quaternions and SLERP

Well, the transition to quaternions was pretty painless. They aren't quite as complex as I was expecting, and GLM makes them very simple. That's the good news. Unfortunately, this caused my camera smoothing to go haywire, since it was relying on the older method of rotation. Not to big of an issue though, since I've been needing to rewrite the camera smoothing function for some time. The old method would cause some wobbling if the ship were to turn too fast. The next step is reading up on SLERP.

The Engine Overview

Seeing as how I finally have some visible progress to show, I thought I might create a development log for my engine, tracking it's progress. I doubt I'll be posting much code here, but if you are interested in seeing it, or just have a question, feel free to shoot me an email. You can find my email on my site here: http://www.GamesByMike.com

The Team:
Mike McCollum - Programming
Derek Hetrick - Artist

The Project Goal:
I'm building a 3d game, within a custom engine for PC. Although I would love to someday publish the game itself, the biggest goal of the project, is to breakdown, and gain a more thorough understanding of engine development.

Since my team consists of just 2 people at this point, we decided to take a simplified, slightly stylistic approach. We are supporting flat lighting with diffuse maps only, since getting tangled up in lighting and shaders, could amount up to a very large addition to an already massive project size. It seems best to choose an artistic style that fits within our current scope/skill constraints.

The game is a 6 axis shooter, with a strong physics and grappling component. The core mechanic consists, using your robot, to grab hold of, throw, crush, or otherwise tear apart your enemies, and assimilate their parts onto yourself. We are aiming for an Einhander (for ps1) like mechanic, mixed with Katamari, where as you battle on, your robot grows and grows. As you assimilate more enemy ships, you gain more power and thus assimilate larger parts.

Built using OpenGL 4, SDL 2.0, and GLEW.

History
Some background: The engine started as just an attempt to delve into basic 3d rendering, using openGL and c++. Once there was an artist on board, we decided to make it into a full 3d game engine. It's been my first attempt at creating a 3d engine from scratch, so much of the core programming had to be learned on the fly.

Progress
The first several months of development consisted of laying out the basic framework for the engine, as well as creating a series of proof-of-concepts. After each stable build, I collected feedback, updated my existing code, and repeated the process.

In the beginning, I was following some tutorials from http://www.3dbuzz.com/. If you are familiar with them, you may recognize a bit of the content. While functional, and very helpful at first, they are severely outdated. (Or at least the ones I used)

The first worthy screenshot of progress. It’s more here for nostalgia than anything, since it is just a simple demonstration of openGL rendering, a loaded texture, and applying it to a cube. At this point, I was still using SDL 1.2, and openGL 1.

A Loaded 3D model from an OBJ, I had created some time ago, with an applied texture (Diffuse Only). Without normal maps, he looks a bit odd, but that’s alright, since he was a simple proof of concept, and will not actually be featured in game.

This was a demonstration of parenting hierarchy, and application of transforms. The parenting hierarchy is crucial, since grappling will be a large part of the game, and the parent/child trees can shift rather dramatically.

Flash forward a few months. It was very much like stepping through 20 years or so of technological advancement in a few months. Moving from manual openGL draw commands, to vertex arrays, upgrading to openGL 4.0, delving into shaders, ect. Basically, I had to rewrite a large chunk of my old code. At that point, this was not a bad thing, since the engine was a gruesome mismatch of various tutorials, integrated into one. With each upgrade, a new interface would need to be added, sometimes stacking two or 3 on top of each other. It was my Franken-engine, and it was indeed a monster. Shortly after the rioting villagers destroyed it, I built the current engine to be far cleaner. Since I had already slogged through getting it wired up the first time, the second build took far less time.

 At long last, things are up to date, (or at least as up to date as is practical at this time) and I've moved forward into setting up the engine for game play.

Current Progress

Here is a screenshot of the current WIP, with a demo environment. It takes a planet and randomly populates the scene with them. This helps while testing things like player movement, and physics. The ship also only has a single arm. That will be explained below.

The controls are in place, and the player can move around the world, albeit without collisions. I have systems in place for dynamic object creation, but they will still need optimized, since they are not yet sharing redundant data, and there is a ton of it.

I've just finished implementing the camera system, which allows me to define several cameras within the scene, and switch to them dynamically. Additionally, cameras can be given a target, which they will 'follow.' There is a bit of tweaking, to the camera smoothing, but for the most part, I like the effect it gives.

I'm still ironing out a few kinks, but I'm finalizing the transformations now. The parenting of the various mesh parts is working fine, but recently, I've encountered some gimbal locking while rotating some of the parts on the player's ship. I'm starting the switch to quaternions. I had of course heard of them prior to this, but until the Euler angles started giving me trouble, I had yet to dive into them.

The last major issue, is that our current importer is insufficient for our current needs. Specifically, the ships are made up of many parts, that need to be split into individual pieces, and attached in a parenting chain. For this first ship, I have set it up manually. The next update will feature a more robust importer that will take in parenting chains from 3Ds Max, as well as dividing objects into parts automatically.

And that's it. Everything for the engine thus far. Thanks for reading, if you made it this far. The rest of the updates will be considerably, shorter. This one ended up a novel because there is so much to summarize.