 |
 |
 |
 |
Research ProjectsAll of the projects listed below were built entirely by me during my time at the Guildhall at SMU. All of the 3D projects were built using my own 3D rendering engine WillPower. WillPower is a dual API (D3D and OGL) rendering engine built for Windows operating systems. Particle System Editing ToolI chose to build this editor as my 'Project in Lieu of a Thesis' for my Masters Degree in Interactive Technology in Digital Video Game Design from the Guildhall at SMU. The editor was built in my final two terms at the Guildhall while we were working on our final team game projects. Major features of the editor include.
Patch Based LOD TerrainDuring our 4th term at the Guildhall we were assigned the task of building a patch based terrain rendering system. The application loads in one of the versions of the hightfield data, at a resolution of 1024x1024, 2048x2048, or 4096x4096. The height data is split into smaller renderable chunks and index buffers are built for each level of detail for each chunk. At runtime the application decides which level to render based on distance and biased based of intrinsic detail of the chunk (as determined by the root mean squared algorithm). Smoothing passes are made to make sure no neighboring chunks differ in LOD by more than two, so we can be sure to use the appropriate stitching version of the chunk mesh. This prevents the world from having T-junctions which would appear as small holes in the terrain.
3D Studio Max Exporter / Quaternion AnimationOne third term assignment was to develop a static and animated mesh exporter for 3D Studio Max. My animated meshes supported 4 bones per vertex and bones were stored as a quaternion + translation vector. At runtime the bones were blended using quaternion SLERP and uploaded to the card. Vertex tweening was done in a HLSL shader by transforming the vertices, normals, etc, by the quaternions and corresponding translation vectors. This system bypassed the need to convert bones into matrices, easily allowing 80 bones per mesh on shader model 2.0 hardware.
3D Lunar LanderI developed this little game demo for a project in one of our math and physics classes at the Guildhall. The game simulates the motion of an object subjected to forces while its mass is changing (fuel burn). The goal of the game is simply to land the craft on the ground while moving less than 2 m/s, fuel is quite limited so you must be careful.
WillScript LanguageDuring term 4 I developed a small scripting language named WillScript. WillScript is a weakly typed procedural language. I added support for calling pre-defined engine methods, so I could potentially hook the language to rendering calls. The sample program I wrote to test the language tests recursive methods, and implements the quick sort algorithm. Along with the language compiler I wrote a stack based virtual machine to interpret the byte code produced by the compiler. DOT3 BumpmappingThis demo shows my implementation of DOT3 bumpmapping. The cube is 6 flat faces, detail is added by introducing additional lighting information via a normal map. The lighting model includes diffuse, specular and ambient.
Spring-Mass-Damper SystemIn our 4th term Math and Physics class we implemented spring-mass-damper systems. SMD systems are useful when simulating rope, cloth, and can even make decent approximations to ridgid body dynamics. In the sample shown below each of the spheres is connected to the next with a spring and damper. The sphere masses collide with one another and the walls of the blue box. Collision is determined using simple Minkowski differences.
Volumetric Cloud FormationFor my first directed focus study at the Guildhall I set out to build a procedural volumetric cloud generation algorithm. The algorithm I found approximates the cloud formation process by using a Coupled Map Lattice (a continuous state cellular automaton). The CML approximates the affects of advection, phase transition, thermal diffusion, water vapor diffusion, thermal buoyancy, and the effects of viscosity and pressure. I fed the system vapor sources generated from Perlin noise. The system was able to produce cloud like shapes, but the resolution of the system was pretty low and the simulation space soon became filled with water vapor. The algorithm proved too expensive to run a full sim step every frame and maintain acceptable frame rates, therefore each step was broken up over many frames. I believe the real performance problem came from the lack of temporal coherency of the algorithm, causing cache thrashing. I will one day return to try and generate dynamic cloud volumes, but I would like to research an algorithm that feels less 'tweaky' since getting stable system values that produced cloud likes shapes proved to be a matter of trial and error.
Quake 1 BSPIn our second term we were challenged to load and display Quake 1 .bsp levels. When rendering the level is both PVS and view frustrum culled.
In Engine Terrain Editor[Rebuild Project and Grab Screenshots] Fire MagusFire Magus is the first game I developed during my time at the Guildhall. The entire program was written by me in the first 3 months of the program. The sprites I 'borrowed' from various sources, since my own sprites look very much like programmer art. Fire Magus also featured my first particle engine, which I used to generate the fireball and fire ring spell effects as well as the health and mana HUD elements. Probably the most visuall impressive feature was the dynamic lightning effect I used on the characters most powerful spell. The game was written with my own blitting functions, and only one Win32 draw call was used to swap the back and front screen buffers.
|
|||||||||||||||||||||||
