CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
Made quite a lot of developments this month. First of all I started to work on some basic artificial intelligence using simple distance and direction calculations between the NPC and the player, I wrapped this into a basic state machine in order to allow other behaviours to be easily added. After this I added a state for fighting and a state for randomly wandering about when the player is not within range. In order to stop the NPC’s falling off the edge of the platform it was necessary for me to add some detection of the platform edge and link this into the AI’s wandering behaviour, forcing them to change direction until they are no longer in danger of falling off. When they are seeking or attacking the player this is not important as zombies are notoriously stupid and would most likely follow a person off the edge of a platform. A problem which still exists in this is that I haven’t added wall detection to the zombies so if they get stuck walking into a wall they may continue to walk into it until they randomly change direction, but this isn’t too hard of a fix.
For each of the npc’s I have attached collision meshes to the limbs used in contact when fighting (head, arms and leg) in order to accurately detect what kind of attack is being carried out and for how long they have been in contact (for harder / varied attacks) in order to apply damage and health. Due to a limitation in the number of different animations I have available I decided in order to make the combat a bit more varied and not so predictable I made it so while the player / npc is in the attacking state and its limb collision objects are colliding with the enemy it reduces health from them, meaning that if you hit a zombie with the ninjas hard attack and you catch them at a good angle the full force of the swing is applied. Also depending on what attack type they have received the AI when attacked receive a force in the opposite direction to what they are facing, and a different attack animation is played based on the attack. A small improvement on this would be to apply the force in the direction of the collision normal as opposed to their direction normal.
The turret I decided to create as I helped someone fix some buggy picking code which inspired me to implement a form of ray traced shooting. It was fairly easy to set up, although I did have some problems with the way newton works and the way I wanted this to work. In order to keep an rigid body still the best way to do this is setting its mass to 0 so that it has an infinite mass, but as I want to rotate the turret smoothly using forces (manually rotating creates serious collision issues) this wasn’t an option. So first of all I tried attaching the turrets dynamic body to a static body of 0 mass via 3 ball socket joints, and then manually rotating the static object, which worked more or less flawlessly, although I did begin to notice some glaring bugs which caused the dynamic body to sink into the ground, so I opted to use the same method I use for moving and stopping my character (applying an equal and opposite force to stop), so if the desired velocity of my turret was to always be 0,0,0 to calculate the force required to keep it still is the 0,0,0 – the current velocity multiplied by mass and time, this worked better than I imagined it to and is much less hacky than attaching to a static rigid body. Attached a cross-hair entity to the end of the turret, basically a specified distance in the turrets local space Z co-ordinate which is then multiplied by its rotational quaternion in order to give the direction, this is essentially how i cast the ray in order to shoot. upon the ray colliding first with a zombie i then apply an attack to it in the same way it is applied when in combat. in addition to this i added a simple particle effect in the same way as the cross-hair in order to simulate muzzle flash, i may add some kind of chaser bullet as well just so you can visualise where it is going.
After I got the layout of the first level pretty much how I decided It was going to be I figured it was time to start making it look a bit nicer with lighting and shadows. I decided to apply modulative stencil shadows, as they where easy to implement, fairly general purpose and still don’t look too jagged on the edges. After much deliberation and stress testing with large amounts of NPC’s I decided to only have one light in the first level (directional light representing the sun) but make it spread across the whole level (I may add some flaming oil barrels later but using omni lights with a very small range). Then using Ogres compositor material frame work I have applied using high level shaders a HDR effect (need to go through and optimise / modify this a lot to get the right look still) to give the level a bit more life and stop it looking dull.
So next up, finish the second and 3rd levels off, this is really a simple case of adjusting what is already there, and adding some more npc’s, turrets and lights. Sound effects which need to be linked into the appropriate physics material systems, the support for audio playback using Fmod is already written and functional so this is more of a design issue than anything else. Sort the sky out so that it is a sphere and not a dome, beginning to get annoyed by the empty spaces under the level. After this it should just be a case of playing around with the artwork (I have no artistic flare but I can still try) and optimise both the code and the shaders (also rewrite / refactor a few and implement my normal mapping shader). Then it will be simply a case of bug fixing, tweaking game play. And overall polishing the front end and usability.
Email: mike"at"rookie3.co.uk
Date of Birth: 22/07/1984
Available for work: June 2008
Profile
I am a hard working, confident C++ programmer looking to further my career within the games industry as a programmer. I am self motivated and a fast learner. I constantly strive to improve, I am driven by success and employ an iterative approach to my work, thus achieving my goals.
Key Skills
Strong C++ experience (7 years)
Good Physics and Maths
Extensive working knowledge of DirectX
Understanding of a multitude of graphical / mechanical techniques (2D and 3D)
Linux and programming for Linux
Windows and programming for Windows
Knowledge of PS3 and Cell architecture
Basic working knowledge of OpenGL, SDL, GLSL, and HLSL
Education
2006 – 2008 - The University of Bolton
(BSC) Computer Games Software Development , Expectant grade: 2:1.
Modules including: Software engineering, Maths, Physics, Multi threaded processing, AI, and 3D rendering techniques.
2002 – 2004 - The University of Bolton
(BSC) Leisure Computing Technologies – Took some time out for personal development
2000-2002 - Lewes Tertiary College
(AVCE) Advanced ICT Double Award – BB
(A/S) Computing - B
(AVCE) Business studies – Half Award – C
1995 -2000 - Tideway School Newhaven
9 GCSE’s A – C
Employment history
Jul 07 – Sep 07 - Quality Assurance Technician - Sega of Europe
Universe at War on PC
Functionality Testing
TCR / TRC Testing
Regression Testing
Sep 05 – Jul 07 - Sales Assistant - Gamestation
Custom Service (advising hardware / software purchases)
Occasional management duties
Deliveries and Stock control
Oct 04 – Sep 05
Worked a variety of temporary factory / bar jobs whilst working on my portfolio
Aug 04 – Oct 04 - Quality Assurance Technician - Zoo Digital
Pool Shark 2 on PS2, Xbox and PC
Functionality Testing
TCR / TRC Testing
Regression Testing
Previous and current personal projects
Currently working on a multi threaded wave simulation project using Sony’s Playstation 3 and its Cell processor via Linux using IBM’s Cell SDK.
Currently working on a 3D game using a combination of my own engine and Ogre 3D
Developed a DirectX 9 based game engine
Worked extensively with Newton Game Dynamics physics API
Have worked on a number of small 2D projects using the Windows API and SDL.
Developed a Breakout clone using XNA and C# for the Xbox 360
I have also spent some time experimenting with PS2, GBA and DS and Xbox home-brew development
Project Plan
for:
A Multi-threaded wave simulation for oceans using the Playstation 3’s Cell Processor
by
M.Stowell
Supervised by A.Williams
March 2008
Aim
This project is an investigation into an optimal technique for simulating ocean waves using IBM’s cell processor on the Playstation 3 and analysing its performance using a range of simulated workloads whilst comparing the results to that of Intel’s Core 2 Duo processor range.
By doing this I hope to achieve a relatively fair comparison of how the two different architectures perform under this type of simulation, and will also serve as a study into methods of carrying out work efficiently on the Cell processor.
Background
With ever increasing developments in technology / computer hardware, and a much greater demand for aesthetically pleasing totally immersive environments in computer graphics and virtual reality, it becomes both necessary, and with current hardware, more and more possible for these applications to use accurate simulations of real world phenomena.
One approach to simulating water talked about in Game Programming Gems - Gomez 2000, describes a method of simulating water in 3 dimensions using only the data for a 2 dimensional simulation. The water is represented as a 2 dimensional plane thought of as a stretched elastic membrane, with the height of the specific vertices being calculated using a partial differential equation. This is considered to be a fairly accurate way to represent waves in computer graphics, but it has a number of downsides with regards to performance and memory. First of all it uses the previous wave position and the current wave position in order to effectively interpolate to the next position, this uses a lot of memory as is it essentially storing two meshes. It also requires that each vertex has access to detailed information about neighbouring vertices in order to calculate the new position. I believe this will create massive problems when it comes to multi-threading the simulation as it will seriously restrict the ability to split the program up into multiple threads of execution.
Another approach detailed in GPU Gems - Finch 2004 is to use the graphics hardware shading capabilities of modern GPU’s (not so dissimilar to the SPE’s in the Cell processor) to apply a “sum of sine’s” approach to the vertices in order to approximate their positions, this will easily allow for multiple waves / ripples. This method appears to be much more flexible than the previous as it uses a parametrised approach as opposed to basing position on forces from neighbouring vertices, it will allow for the workload to be easily divided up into threads, gives precise control over the geometry, and allows for easy scalability. As previously mentioned the work described here is carried out using GPU specific hardware, I plan to rework this into an efficient CPU based algorithm that is especially optimised for the Cell processor.
Unfortunately due to the Cell processor being a relatively new architecture, not too much work has been publicly released, particularly on the subjects of rendering and physics simulation. Insomniac Games recently released a document from one of their presentations at this year’s (2008) Game Developers Conference. Spu Shaders – Acton 2008 It lists a number of methods for using the Spu’s to do the work of a GPU’s shader. Some of the main key aspects I took from studying this where that it is crucially important to concentrate on the layout of data so as it is completely modular, straightforward, and uses as much of each SPE as possible, due to the nature of bandwidth and memory constraints it appears that the SPE’s can process data a lot quicker than they can receive it, so with regards to parallel optimisations following these rules should help me to develop a very efficient algorithm for this study.
Specification
The end product is to be two applications built from the same code base / framework that are capable of running on x86 and Cell architecture. It should graphically represent the wave simulation and include some method of adjusting the scale of the simulation and all relevant parameters in order to accurately benchmark performance. The x86 version should be multi threaded in such a way that the number of cores used can be scaled, so for a single threaded machine it is possible to run just one thread, but this must be scalable up to at least 4 threads in order to benchmark the increase in performance. The Cell version of this should perform the simulation using only the SPE’s (starting with 1 SPE scalable up to 6) with the PPE in charge of rendering the output of the simulation and controlling the flow of data / programmes between memory and each of the SPE’s. In order to correctly assess fair results the x86 should be benchmarked using both the CPU to do the drawing routines and the GPU for each test.
Due to the grid like method I am using to represent the wave surface a main scaling factor can be how many segments of the grid there are, increasing the amount of segments effectively increases the level of detail and also the processing power required. Starting values for my initial tests will be 80 for low, 120 for medium and 160 for high, although depending on the performance of the machines I may increase / decrease in order to get usable results.
Another aspect of GPU Gems - Finch 2004 I liked was the “sum of sine’s” approach that he uses, this can easily be translated into having n number of waves active at any time all being able to affect each other as they would in reality, which should also be scalable from 0 to 4, this should provide a decent amount of data for testing purposes.
The parametrised aspects of the wave data should be fully represented and editable either at run time through a GUI or at lest be easily modifiable via text file to provide quick testing capabilities.
Strategy
In order to effectively implement everything that the specification outlines I must break this down into individual sections.
First of all it is necessary to create a generic framework for rendering. This will require a vertex buffer stored at memory level so that the x86 / Cell has easy access to the data. This should be created using the Irrlicht rendering engine. And should be able to render a grid of triangles with scalable dimensions. This is all that is required from the render as the wave simulation code will handle all of the vertex transforms.
Then just using the PPE of the Cell and one thread of the x86 develop the methods required to carry out the simulation. This will obviously be terribly slow and pretty useless with regards to obtaining results for this simulation. But this will ensure that the starting framework is the same for both platforms.
With all of this working correctly all necessary parameters should be exposed to some kind of interface whether it be a graphical interface or simply using data loaded from text file / entered from a command line.
After this it will be necessary to multi thread the application for the Core 2 Duo splitting the workload into chunks suitably sized to make it execute as fast as possible. The same needs to be done with the Cell processor i.e. splitting up the data workload as effectively as possible in order to create the fastest method for processing this simulation on the SPE’s.
Schedule
CLICK TO ENLARGE
Experiment with the Irrlicht rendering engine looking for the optimum set-up across the two platforms and try to define the best possible way to represent the data.
Test out different methods of manipulating the vertices in software, in order to determine an efficient way of directly modifying the vertex buffer.
Use previously obtained method to attempt first basic calculations to manipulate a single wave moving along a pre set sine wave as a test of what kind of scale / values I’m working with, and to give me an idea how well the buffer manipulation works.
Begin to create a basic wave class containing a lot of the required parameters such as Wave Length, Amplitude, Speed, and Direction.
Concentrate on using the appropriate mathematical terms to correctly create a single wave supporting change in the parameters.
Concentrate on using the appropriate mathematical terms to calculate the surface normal and tangents for the waves at any point. This will be useful for texturing / lighting and also for interacting with any objects outside of the simulation (e.g a Boat object).
Implement the Gerstner wave function in order to add steepness to waves.
Work on the ability to include multiple waves (up to 4).
Create some test scenes using different pre-sets for a number of waves / situations in order to get an idea of what performance to expect and catch any bugs that may occur.
Spend time studying Libspe2 in order to have a fairly good grasp of its functionality before I attempt optimisation
Use OpenMP to split the x86 workload into threads.
Use Libspe2 to create a number of SPE programs that do different aspects of the wave simulation, also create a SPE program capable of carrying out the whole simulation process on a set of data.
Use the PPE to split the Cell workload into threads and distribute amongst some of the SPE programs in order to see what works well.
Research current published resources for methods of optimising for the cell, spend time speaking to other developers to gain insight.
Optimise SPE routines using a number of documents published by IBM and other various other sources as a guide.
Complete prototype report.
Implement all tests on both platforms carefully recording results.
Compile all data and try to determine if the test was successful.
If data seems to have inaccuracies spend time determining if any of the methods used can be modified in order to produce better results.
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
CLICK TO ENLARGE
