Ok, it's now been 3 weeks since I handed in my dissertation report and now is the time to share what I've found with you lot. First things first:
Dissertation Report Document (3MB )
Demonstration Video (HD, Quicktime 7 required, 295MB ) UPDATE: the link now works, sorry guys 
Dissertation Poster (20MB PNG file, 10k*7K full resolution )
I'm now going to shamelessly cut and paste from the report itself giving the conclusion for the project.
This project set out to create a method of realistically destroying or fracturing 3D polygonal objects in real-time. This technique was targeted for use in computer games to produce better interactive environments for the latest games.
Research for this system came from variety of sources. The project was most heavily influenced by Fox [2] and Miller [3] yet the base for this entire project was the work by O’Brien [10]. Additional influence came from attempts to simulate this in commercial computer games such as Red Faction [13].
It became clear early on that in order to maintain the real-time aspect of this system there would have to be an offline process to generate crack patterns. The Fracture generator created patterns in a way that could be directly influenced by an artist with the use of an alpha texture. This gave the artist much more control over how the crack pattern would look so that objects in the real-time environment would fracture in different ways dependent upon their material strength set out by the artist. However, due to difficulty with the implementation of the volumization algorithm, this module of the system was unable to output crack patterns in the desired format. If further work was to be carried out in this area, the modular design of the real-time and offline systems means that the real-time program does not have to be rebuilt as it will accept crack patterns created with any generator.
With a manually created crack pattern, the real-time aspect of the system, the fracture viewer, was able to successfully crack objects in to the volumes set out in the crack pattern. The performance of this system was good; however, the time to complete the cracking process was noticeable in models with more than 1000 polygons. Using this technique on low-polygon objects such as walls, glass and small to medium sized household objects would be an excellent way to simulate a dynamic environment. That said, improvements to the cracking algorithm could be made. Using a high-performance programming language i.e. C++, would improve the speed of the algorithm so that this polygon limit may be increased; however, the choice of C# as the programming language was the best language for the rapid development of the project at the time. An optimized sealing algorithm would decrease the number of polygons to be rendered in the resultant pieces, thereby increasing rendering speeds. The use of a bounding sphere test with each volume in the crack pattern could also increase performance. With the advent of multiple processor desktop computers this process could be threaded and performed in parallel so that the performance of this process is increased significantly.
The quality of the resultant pieces was generally good. As described in section 6.4, problems were encountered re-meshing the pieces. Whilst this caused problems with more complex crack patterns, figure 6.7 showed that the re-meshing process could work successfully. The quality of the sealing algorithm was acceptable but further work into this area of the algorithm should be performed.
If this system was added to a physically based environment (by the inclusion of a physics engine in the computer game) the resultant pieces of a cracked mesh would be animated in a realistic manner. This would make the destruction of each 3D object look realistic and therefore suitable for a commercial product.
Quite simply, with a bit more work on the re-meshing (using multiple clipping planes to seal the mesh, a better algorithm than the naive one to create continuous meshes that normals could be created from) and getting a bit of shading on it and it'd look much better. But, the potential is there.
Finally, a bit about MDX. Personally, I've loved working with the API. It's been simple to do even the more complex stuff with it and I've been learning 3D programming for less than 8 months. However, one or two little things bug me, like how much difference having the MeshFlags as Dynamic instead of Managed or SystemMemory makes (gave me a whole week of headaches). I would recommend it to the industry.... but not for commercial games. Use it for concept prototypes where the time you have to build something does matter or for a throw-away part of the game. MDX code takes an awful lot less time to write than UnMDX and is a lot less prone to niggly stupid bugs that pointers tend to introduce. MDX is just not fast enough for commercial development. 20% of your framerate is a lot to lose!
So, what next for me...
Back to website development really. I've got 3 on the go. Sheffield Uni Rowing Club want in on the squad system so they're getting a cut n past job of the hockey website, TSC needs an update and the hockey site itself is getting the works, including integrated PHPBB and my own fantasy league online that's integrated into the user database and match reports system. That's gonna take a looooong time to do.
I'll keep y'all up to date with that over the summer
Steve
Currently Listening to: Guillemots - Best live band EVER
Currently Reading: 1001 Albums you must listen to before you die
Currently Eating: Birthday Cake - (I was 21 yesterday)
Currently Drinking: Champagne (see above)
Days until my one and only exam: 7
and a DOC (Word 00-03 compatible) file (9M
