Our team’s engine proof presentation went pretty well, although it was over a week ago on 10/7, I wasn’t able to write a post about it the weekend after the presentation because in preparing for the presentation, I neglected some other homework that I needed to race through after the presentation in order to get it done on time. I would say we’re a little behind gameplay wise, but systems are coming together.

Integration

All my summer work had been in what was more or less a standalone graphics engine. So when my teammates started creating their own systems like a Level Manager, Physics System, and a Sound System, there were a few kinks we had to work out in making sure all our systems with their respective dependencies all worked together in a single solution. We particularly had issues with the DirectX SDK. Since I was working primarily on a windows 10 computer where the sdk is included in the windows sdk, there were no issues in accessing it. Some of my team members used Windows 7 on their computers, and the computers at Digipen also use Windows 7. Our game worked on some Win7 computers, but not others.Apparently, on some computers, the visual studio macro for the DirectX SDK actually goes to the wrong folder. In addition to those issues, we also decided to make significant changes to our project structure compared to what I had in the graphics prototype. As a result, some changes needed to be made to some of the art pipeline as well. But after a week or two, we got all systems playing together nicely, and I believe we’ve set up a solid project structure that help us develop more efficiently moving forward.

The textured chimera, the basilisk block model, and a cube falling with physics

Animation

The bulk of my work this milestone was spent trying to implement a skeletal animation system. This task was far more difficult than I expected. I started with changing the rad binary file to store data like a tree rather than an array. Before animation, I was just collecting all relevant nodes and spitting them out in order into the file. However, for animation, I would need to retain the parenting relationships between the skeleton nodes. In order to encode and then decode this parenting information, significant changes had to be made to the fbx converter and the in engine function that loads rad binaries.

After storing the parenting information, I started working more on the fbx converter to get the animation data out of fbx files. Before doing anything with the data, I wanted to encode all of the data that I was going to need in rad binaries and ensure the engine can correctly read and store that data. This also involved creating skeleton and animation classes in engine to store joint data and per joint key frame data.

Once I had all the data I needed in engine to animate skeletons, I started on a function that would be able to debug draw and animate the skeleton. My first attempt was not so great….

This doesn’t seem right…

And unfortunately, I was not able to get complicated skeletons drawing correctly in time for the engine proof presentation. The animation we showed off in presentation is the one shown above in the integration gif of a simple skeleton with 4 bones bending around in half circle. However, after a few days of debugging I identified the issue was in how I was handling some of Maya’s unique transformation matrices like pre rotation and post rotation. I wasn’t sure the correct place to apply them in the animation process. To fix this, my animation / advanced modeling TA suggested I use functionality in the Maya FBX SDK to bake the transform to standard translate rotate scale instead of trying to figure out what Maya was doing. This fixed my issue and I got skeletons animating correctly.

Correctly animating skeleton walk cycle

Model Viewer

Another thing I worked on this milestone as a model viewer that would allow our team artists to quickly and easily see their assets (models and skeletons) in the game’s graphics engine. We didn’t want artists to have to compile the game whenever they make an update to a model and want to make sure it looks fine in game. Developing the model viewer was quick and easy thanks to our project structure. Each individual game system is compiled into a static library which is a dependency for main. So making the model viewer was a simple as writing a new main driver that uses the same graphics lib that our game does.

The Model viewer drawing the chimera skeleton’s run animation

Skybox

The last thing I implemented this milestone was a skybox. In some of the gifs above, you can see my test skybox where each face is just a colored square with it’s axis and sign printed on it. Most of the gifs above have a background  of a giant blue -Z because the camera is looking down the negative Z axis. Because I thought the test skybox was kind of boring and our artists haven’t gotten around to working on a skybox yet, I grabbed a skybox  from here to show off what a real skybox might look like in game.  Although admittedly, the skybox I grabbed doesn’t match our game’s style very much.

Top down view of chimera model with the bottom face of the skybox showing. Placeholder skybox by ‘The Mighty Pete’ of http://www.petesoasis.com

Conclusion

The team has a difficult milestone ahead in finishing up an editor and beginning to implement gameplay for a prototype. I’m just going to continue to work on supporting the artists and improving the graphics engine. The major thing I’ll be working on these next few weeks is skinned mesh animation. Now that skeletons are animating properly, I need to connect those skeletons to models. Another important task this milestone is implementing split screen for the prorotype. If I have time, I’d also like to spend some time supporting more texture maps like normal maps, glow maps, and transparency maps to make the models look nicer.

Chimera and Skybox