Create a custom theme
When I woke up today, still exhausted, I shot a youtube video of the project, and we went down to the visualization lab at the uni, where we will defend our project on the exam tomorrow. It's a huge screen run by an nVidia workstation.
That's approximately four meters wide, which is pretty epic to experience when you've worked so hard and so long on something!
It ran smooth and with no problems, so I'm really excited for the exam tomorrow now!
And though it might be a bit early to look back at how I've tackled this project, I still want to give that a try.
First thing first though, the project's source code: http://code.google.c...245physicsgame/
I started the project on January 16th. We had just come off a rather crazy start of the year, where I crunched in a big project on fluid mechanics visualization in a week with barely any sleep, so this project started a bit slow as I was recharging batteries. First off, the assignment required that we'd use Qt. I don't find it very suiting for game programming, but since it was a requirement, I had to run with it. I tried to use as little of the framework as possible, and thankfully the new 4.7.1 version supports creating an OpenGL3 context! This all took a while to figure out, and the guys at freenode (irc) #Qt and #OpenGL were awesome helping me out! On january 21st, I had the base application up and running with opengl rendering and updates flowing through my base game engine.
The work on this game engine started about two years prior to starting my master's here at the university, but it's first now during these school projects, where we focus on one project for about a month and a half before we go to the next one, that I've been able to rapidly improve and refactor the engine for each new project. Always grinding in features at the end of each project, finding weaknesses in my API, thinking out possible solutions that I could use on the next project, etc. It's been a great learning experience, and the game engine has really grown into something that's pretty usable for smaller game projects.
I then focused on getting AssImp in for loading meshes, and with it I found that I might as well incorporate DevIL as well for texture loading. Now things started to pick up. It was a lot of excitement getting these libraries working so fast (big thumbs up to AssImp for being such a simple API to work with!), and I quickly got to add in lighting and working on shaders.
I never spent a great deal of time before making sure all my matrix and lighting calculations were handled correctly. But this time around i figured I might as well do it properly, because I knew I had some bugs in there. So, I fixed my normal matrix, turns out the you really have to only transpose over the 3x3 version of the modelview matrix for this to work! I then also did quite a few experiments in shader with using object space light shading and tangent space light shading, and ended up with tangent space, since all the normal maps loaded from textures were stored in this space...
At the very end of january, I got this idea though, that I should really try to optimize my rendering. That is, I really wanted to improve on my OpenGL 3.3 spec correctness, remove redundant state changes, and overall lessen the number of calls to opengl. The idea that came to me was a material-driven rendering pipeline. If I sorted the entities by material, I would be able to bind shaders and textures for entire groups of entities, as well as bind uniform values like projection matrix, lighting, coloring,etc. Each entity type would then have a manager. It was in the manager that the VAO, VBO, IBO and all that mambo jambo was defined and loaded, while each entity instance of a type would only bind uniforms specific to itself, like the modelview matrix. The entity type manager idea was ideally set up for handling instanced rendering, but I never got around to it... A material was defined in XML, and here's an example material:
Entity types in the engine was also defined in XML, and it was here that entities chose their material. A typical entity xml file would look something like this:
This was very cool to work with during development. A lot of the time I was simply working over a compiled release-mode executable and tweaking values in xml files, shaders and Lua scripts. This was very efficient for progress, and also a great way to force the C++ engine to stay general and clean, while specialized code was in the resource files.
However, I did find a great weakness in my Material-driven rendering pipeline design that I hadn't thought about. Transparent entities! I was rendering the scene by iterating over materials, and for each material, I rendered the entity types hooked up to it. How would I then sort back to front all transparent entities? Of course, I wouldn't be able to properly solve this without rewriting my pipeline, but at this point there was simply not enough time left... I had to let it go and be ok with the fact that I could only sort entities per material. I did sort the materials too based on the "weight" applied by the entities it owned with respect to distance from camera, but this was an ugly hack at best and only improved the blending mildly. Quite a few blending bugs is still present in the application today.
In the end, I don't really regret my decision to try this design. Being a student and having a ton of projects like these is a great opportunity to experiment with ideas, and I learn a lot from each and every experiment and idea that I try to implement, fail or success. I will definitely never make this mistake again in an API
A slightly cool thing I implemented, was the crosshair mechanic. I was trying to adapt the approach Starfox has, where the spaceship always follow the crosshair. I decided to render it as a sprite in worldspace instead of drawing it as a GUI element. This had some problems, especially the issue of ensuring that the crosshair never left the bounds of the screenspace. My solution was to convert the position to screenspace coordinates, then clamp it within the screen bounds, then convert it back to world space, and this worked very well
The component system was a great asset to rapid development of game mechanics. All components were scripted, and could listen to events, or even bind itself to receiving updates every frame. At one point I did the optimization that a component had to register which events it was interested in, and would only receive events that it had registered itself to. The update function was slightly harder to limit however... The only optimization I could think of would be to move some of those components over to C++, but the game was performing well after the event optimization, so there was no real need for it.
I spent a day trying to implement atmospheric scattering, but I couldn't do it. There's something magical about this shader that I haven't quite been able to weave yet. Guess I'm no arch wizard yet like Sean O'Neil
At this point there were like four days till deadline. The only physics I had was a hacked together Lua scripted component I called RigidBody... I moved the logic into a C++ physics system, and also implemented angular physics. For a spherical shape, angular physics is really easy to implement... I never found the time though to try my hand at approximating the inertia tensor for a complex mesh, but I think that would've looked really cool with collision response when shooting asteroids!
I also added a pretty bad particle system. It was a simple point cloud that was sent to shaders along with an attribute buffer or random directions. I would overload these random directions in the geometry shader via a uniform force direction vector. It worked "ok" for displaying dust clouds when shooting asteroids, but it was far from good enough to be used for things like engine flames, etc... Thus I didn't find time for that last bit...
At one point towards the very end, my program suddenly started crashing in the Gui code. After some investigation, I found that I had gone beyond the number of supported shader programs! Thankfully I could solve this by implementing a shader manager that made sure that no duplications of shaders were made. This was in the last couple days before deadline though, and I had to spend a day on it all! This is definitely something I should have foreseen and implemented (for good api) long ago!
On the last day I really had to work on my collision detection. The assignment clearly specified that we should have a very solid collision detection for spheres, to the point where we would have to look at all collisions occurring during a timestep, then sort the order of those collisions, calculate the response of the first collision pair and calculate physics up to the time of impact... we'd then have to run the collision detection again, to make sure that this new physical state wouldn't cause more collisions... if it did, we had to look for duplicates in the list of collisions already stored for the timestep and only keep those that occurred first... Potentially this could really damage the framerate, since very complex branches of collision could potentially occur during a timestep... As it turned out, with my implementation I didn't really have to worry about this at all... asteroids didn't spawn dense enough to cause mass-chain-reactions of collisions.
Finally, I finished off the project by converting Bill Lowe's html /css gui design to libRocket's rml and rcss format. It didn't go as smoothly as I had hoped, but I got it up and working after a couple of tries. I then quickly, via script, bound some gameplay logic to these HUD elements. When you thrust the spaceship up to speed, the speed percentage hud element would respond with numbers complementing this. The gun got attached to the energy level, where each shot would drain a given amount of energy from the ship, and when energy got below the gun energy drain level, you couldn't shoot. For each frame, the energy level would slowly recharge. It was pretty cool to see that my scripting system was flexible enough to tie all this logic together with the HUD elements without touching a single line of C++ code!
In the end I must say that it felt really good submitting the project three hours before the deadline. I could probably have added some more minor features and polish in that time, but I was simply too exhausted and tired at that point... and I really didn't want to introduce any misbehaving logic that close to the finish line!
Now I'm very excited for the exam tomorrow and hope everything will go well!
That's approximately four meters wide, which is pretty epic to experience when you've worked so hard and so long on something!
It ran smooth and with no problems, so I'm really excited for the exam tomorrow now!And though it might be a bit early to look back at how I've tackled this project, I still want to give that a try.
First thing first though, the project's source code: http://code.google.c...245physicsgame/
I started the project on January 16th. We had just come off a rather crazy start of the year, where I crunched in a big project on fluid mechanics visualization in a week with barely any sleep, so this project started a bit slow as I was recharging batteries. First off, the assignment required that we'd use Qt. I don't find it very suiting for game programming, but since it was a requirement, I had to run with it. I tried to use as little of the framework as possible, and thankfully the new 4.7.1 version supports creating an OpenGL3 context! This all took a while to figure out, and the guys at freenode (irc) #Qt and #OpenGL were awesome helping me out! On january 21st, I had the base application up and running with opengl rendering and updates flowing through my base game engine.
The work on this game engine started about two years prior to starting my master's here at the university, but it's first now during these school projects, where we focus on one project for about a month and a half before we go to the next one, that I've been able to rapidly improve and refactor the engine for each new project. Always grinding in features at the end of each project, finding weaknesses in my API, thinking out possible solutions that I could use on the next project, etc. It's been a great learning experience, and the game engine has really grown into something that's pretty usable for smaller game projects.
I then focused on getting AssImp in for loading meshes, and with it I found that I might as well incorporate DevIL as well for texture loading. Now things started to pick up. It was a lot of excitement getting these libraries working so fast (big thumbs up to AssImp for being such a simple API to work with!), and I quickly got to add in lighting and working on shaders.
I never spent a great deal of time before making sure all my matrix and lighting calculations were handled correctly. But this time around i figured I might as well do it properly, because I knew I had some bugs in there. So, I fixed my normal matrix, turns out the you really have to only transpose over the 3x3 version of the modelview matrix for this to work! I then also did quite a few experiments in shader with using object space light shading and tangent space light shading, and ended up with tangent space, since all the normal maps loaded from textures were stored in this space...
At the very end of january, I got this idea though, that I should really try to optimize my rendering. That is, I really wanted to improve on my OpenGL 3.3 spec correctness, remove redundant state changes, and overall lessen the number of calls to opengl. The idea that came to me was a material-driven rendering pipeline. If I sorted the entities by material, I would be able to bind shaders and textures for entire groups of entities, as well as bind uniform values like projection matrix, lighting, coloring,etc. Each entity type would then have a manager. It was in the manager that the VAO, VBO, IBO and all that mambo jambo was defined and loaded, while each entity instance of a type would only bind uniforms specific to itself, like the modelview matrix. The entity type manager idea was ideally set up for handling instanced rendering, but I never got around to it... A material was defined in XML, and here's an example material:
<Material id="Ferox">
<Technique id="330">
<Pass id="0" lights="on">
<Properties>
<Property id="ambient" type="vec3" uniform="fAmbientColor">0.0,0.0,0.0</Property>
<Property id="diffuse" type="vec3" uniform="fDiffuseColor">1.0,1.0,1.0</Property>
<Property id="specstrength" type="float" uniform="fSpecularStrength">1.0</Property>
<Property id="bumpstrength" type="float" uniform="fBumpStrength">8.0</Property>
</Properties>
<Textures>
<Texture id="diffuse" type="2D" wrap="CLAMP" uniform="fDiffuseMap">Mesh/FEROX_DI.tga</Texture>
<Texture id="ambient" type="2D" wrap="CLAMP" uniform="fAmbientMap">Mesh/FEROX_AO.tga</Texture>
<Texture id="specular" type="2D" wrap="CLAMP" uniform="fSpecularMap">Mesh/FEROX_SP.tga</Texture>
<Texture id="bump" type="2D" wrap="CLAMP" uniform="fHeightMap">Mesh/FEROX_BU.tga</Texture>
<Texture id="illumination" type="2D" wrap="CLAMP" uniform="fEmissiveMap">Mesh/FEROX_IL.tga</Texture>
<Texture id="diffuse" type="CUBE" wrap="CLAMP" uniform="fCubeMap">Skybox/Nebulea.png</Texture>
</Textures>
<Shader id="ferox">
<Vertex>mesh_default</Vertex>
<Fragment>ferox</Fragment>
</Shader>
</Pass>
</Technique>
</Material>
Entity types in the engine was also defined in XML, and it was here that entities chose their material. A typical entity xml file would look something like this:
<Entity>
<Type>Ferox</Type>
<Special>Mesh</Special>
<Material>Ferox</Material>
<Components>
<Component>InputThruster</Component>
</Components>
<Properties>
<Property>
<Name>FileName</Name>
<Value>Ferox/Ferox.3DS</Value>
</Property>
<Property>
<Name>Position</Name>
<Value>0,0,-10</Value>
</Property>
<Property>
<Name>MaxThrust</Name>
<Value>40.0</Value>
</Property>
<Property>
<Name>ThrustAccel</Name>
<Value>3.0</Value>
</Property>
</Properties>
</Entity>
This was very cool to work with during development. A lot of the time I was simply working over a compiled release-mode executable and tweaking values in xml files, shaders and Lua scripts. This was very efficient for progress, and also a great way to force the C++ engine to stay general and clean, while specialized code was in the resource files.
However, I did find a great weakness in my Material-driven rendering pipeline design that I hadn't thought about. Transparent entities! I was rendering the scene by iterating over materials, and for each material, I rendered the entity types hooked up to it. How would I then sort back to front all transparent entities? Of course, I wouldn't be able to properly solve this without rewriting my pipeline, but at this point there was simply not enough time left... I had to let it go and be ok with the fact that I could only sort entities per material. I did sort the materials too based on the "weight" applied by the entities it owned with respect to distance from camera, but this was an ugly hack at best and only improved the blending mildly. Quite a few blending bugs is still present in the application today.
In the end, I don't really regret my decision to try this design. Being a student and having a ton of projects like these is a great opportunity to experiment with ideas, and I learn a lot from each and every experiment and idea that I try to implement, fail or success. I will definitely never make this mistake again in an API
A slightly cool thing I implemented, was the crosshair mechanic. I was trying to adapt the approach Starfox has, where the spaceship always follow the crosshair. I decided to render it as a sprite in worldspace instead of drawing it as a GUI element. This had some problems, especially the issue of ensuring that the crosshair never left the bounds of the screenspace. My solution was to convert the position to screenspace coordinates, then clamp it within the screen bounds, then convert it back to world space, and this worked very well
CL_Vec3f IGuiMgr::clampToScreenSpace(const CL_Vec3f &pos)
{
CL_Mat4f modelMat = CL_Mat4f::identity();
modelMat[12] = pos.x;
modelMat[13] = pos.y;
modelMat[14] = pos.z;
float w = (float)getWidth();
float h = (float)getHeight();
CL_Vec3f screenPos = coreMgr->getCam()->worldToScreen(pos, w, h); //-1 to 1
if(screenPos.x > w-2.0f)
screenPos.x = w-2.0f;
else if(screenPos.x < 2.0f)
screenPos.x = 2.0f;
if(screenPos.y > h-2.0f)
screenPos.y = h-2.0f;
else if(screenPos.y < 2.0f)
screenPos.y = 2.0f;
CL_Vec3f worldPos = coreMgr->getCam()->screenToWorld(screenPos, w, h);
return worldPos;
}
CL_Vec3f Cam::worldToScreen(const CL_Vec3f &worldPos, const float &w, const float &h)
{
//Transformation vectors
float fTempo[8];
//Modelview transform
fTempo[0] = viewMatrix[0] * worldPos.x + viewMatrix[4] * worldPos.y + viewMatrix[8] * worldPos.z + viewMatrix[12]; //w is always 1
fTempo[1] = viewMatrix[1] * worldPos.x + viewMatrix[5] * worldPos.y + viewMatrix[9] * worldPos.z + viewMatrix[13];
fTempo[2] = viewMatrix[2] * worldPos.x + viewMatrix[6] * worldPos.y + viewMatrix[10] * worldPos.z + viewMatrix[14];
fTempo[3] = viewMatrix[3] * worldPos.x + viewMatrix[7] * worldPos.y + viewMatrix[11] * worldPos.z + viewMatrix[15];
//Projection transform, the final row of projection matrix is always [0 0 -1 0]
//so we optimize for that.
fTempo[4] = projMatrix[0] * fTempo[0] + projMatrix[4] * fTempo[1] + projMatrix[8] * fTempo[2] + projMatrix[12] * fTempo[3];
fTempo[5] = projMatrix[1] * fTempo[0] + projMatrix[5] * fTempo[1] + projMatrix[9] * fTempo[2] + projMatrix[13] * fTempo[3];
fTempo[6] = projMatrix[2] * fTempo[0] + projMatrix[6] * fTempo[1] + projMatrix[10] * fTempo[2] + projMatrix[14] * fTempo[3];
fTempo[7] = -fTempo[2];
//The result normalizes between -1 and 1
if(fTempo[7] == 0.0f) //The w value
return CL_Vec2f(0.0f, 0.0f);
fTempo[7] = 1.0/fTempo[7];
//Perspective division
fTempo[4] *= fTempo[7];
fTempo[5] *= fTempo[7];
fTempo[6] *= fTempo[7];
//Window coordinates
//Map x, y to range 0-1
CL_Vec3f screenPos;
screenPos.x = (fTempo[4] * 0.5f + 0.5f) * w + 0.0f;
screenPos.y = (fTempo[5] * 0.5f + 0.5f) * h + 0.0f;
//This is only correct when glDepthRange(0.0, 1.0)
screenPos.z = (1.0f + fTempo[6]) * 0.5f; //Between 0 and 1
return screenPos;
}
CL_Vec3f Cam::screenToWorld(const CL_Vec3f &screenPos, const float &w, const float &h)
{
CL_Vec4f in, out;
//Calculation for inverting a matrix, compute projection x modelview
CL_Mat4f mvpMat = viewMatrix * projMatrix;
CL_Mat4f inv_mvpMat = CL_Mat4f::inverse(mvpMat);
if(inv_mvpMat == CL_Mat4f::null())
return CL_Vec3f(0.0f, 0.0f, 0.0f);
//Transformation of normalized coordinates between -1 and 1
in.x = 2.0f * (screenPos.x - 0.0f) / w - 1.0f;
in.y = 2.0f * (screenPos.y - 0.0f) / h - 1.0f;
in.z = 2.0f * screenPos.z - 1.0f;
in.w = 1.0f;
//Objects coordinates
out = inv_mvpMat * in;
if(out.w == 0.0f)
return CL_Vec3f(0.0f, 0.0f, 0.0f);
out.w = 1.0f / out.w;
CL_Vec3f worldPos;
worldPos.x = out.x * out.w;
worldPos.y = out.y * out.w;
worldPos.z = out.z * out.w;
return worldPos;
}
The component system was a great asset to rapid development of game mechanics. All components were scripted, and could listen to events, or even bind itself to receiving updates every frame. At one point I did the optimization that a component had to register which events it was interested in, and would only receive events that it had registered itself to. The update function was slightly harder to limit however... The only optimization I could think of would be to move some of those components over to C++, but the game was performing well after the event optimization, so there was no real need for it.
I spent a day trying to implement atmospheric scattering, but I couldn't do it. There's something magical about this shader that I haven't quite been able to weave yet. Guess I'm no arch wizard yet like Sean O'Neil
At this point there were like four days till deadline. The only physics I had was a hacked together Lua scripted component I called RigidBody... I moved the logic into a C++ physics system, and also implemented angular physics. For a spherical shape, angular physics is really easy to implement... I never found the time though to try my hand at approximating the inertia tensor for a complex mesh, but I think that would've looked really cool with collision response when shooting asteroids!
I also added a pretty bad particle system. It was a simple point cloud that was sent to shaders along with an attribute buffer or random directions. I would overload these random directions in the geometry shader via a uniform force direction vector. It worked "ok" for displaying dust clouds when shooting asteroids, but it was far from good enough to be used for things like engine flames, etc... Thus I didn't find time for that last bit...
At one point towards the very end, my program suddenly started crashing in the Gui code. After some investigation, I found that I had gone beyond the number of supported shader programs! Thankfully I could solve this by implementing a shader manager that made sure that no duplications of shaders were made. This was in the last couple days before deadline though, and I had to spend a day on it all! This is definitely something I should have foreseen and implemented (for good api) long ago!
On the last day I really had to work on my collision detection. The assignment clearly specified that we should have a very solid collision detection for spheres, to the point where we would have to look at all collisions occurring during a timestep, then sort the order of those collisions, calculate the response of the first collision pair and calculate physics up to the time of impact... we'd then have to run the collision detection again, to make sure that this new physical state wouldn't cause more collisions... if it did, we had to look for duplicates in the list of collisions already stored for the timestep and only keep those that occurred first... Potentially this could really damage the framerate, since very complex branches of collision could potentially occur during a timestep... As it turned out, with my implementation I didn't really have to worry about this at all... asteroids didn't spawn dense enough to cause mass-chain-reactions of collisions.
Finally, I finished off the project by converting Bill Lowe's html /css gui design to libRocket's rml and rcss format. It didn't go as smoothly as I had hoped, but I got it up and working after a couple of tries. I then quickly, via script, bound some gameplay logic to these HUD elements. When you thrust the spaceship up to speed, the speed percentage hud element would respond with numbers complementing this. The gun got attached to the energy level, where each shot would drain a given amount of energy from the ship, and when energy got below the gun energy drain level, you couldn't shoot. For each frame, the energy level would slowly recharge. It was pretty cool to see that my scripting system was flexible enough to tie all this logic together with the HUD elements without touching a single line of C++ code!
In the end I must say that it felt really good submitting the project three hours before the deadline. I could probably have added some more minor features and polish in that time, but I was simply too exhausted and tired at that point... and I really didn't want to introduce any misbehaving logic that close to the finish line!
Now I'm very excited for the exam tomorrow and hope everything will go well!
