USE (University Sports Engine) v3.01
Fixed:
Lop-sided forums
Standardised folder names
Email addresses always being hidden

Added:
Icons for MSN/AOL/Register etc

Known bugs:
Picture association with even/match incorrect
Profile picture upload not being available to everyone

Scheduled additions in v3.02
Tutorials
"Who is in picture" to be displayed with each picture
Rotate pictures in the edit picture menu
Alternate profile picture upload

The reason for all these new icons is that in the v3.1 update the website will be completely modular, split into Basic, Standard, Full and an additional module known as Fantasy Hockey, available for Standard and Full packages. The website has been renamed 'USE' for University Sports Engine. Therefore, the packages are named: USE-less (basic), USE (standard), USE-Full (Full) with Fantasy appended onto either of the latter two.

Next week I shall be registering www.uni-sport.org and www.steel-software.com and moving hosts to Dreamhost which gives me a bucketload more space and bandwidth. From then, any uni who wants a sports website, just has to ask! They'll be limited with the choice of template at first, but that's a story for another day.

v3.02 is scheduled for late next week. However, some of the changelist may be subject to change.

Steve

Currently Listening To: Belle & Sebastian
Currenlty Eating: Very little, on a diet
Currently Watching: Grey's Anatomy
Currenty Reading: The Times (sudoku)
Minutes Left at current job: 68

Comments

Last year, there were no real functions for looking through previous years' data, or even separating it from the current year. Therefore, on this new version, users, matches, events and pictures now have an 'archived' field. There are now search facilities all over the site, all of which work on AJAX technology which makes things all nice and pretty. Therefore, the major changes are:
Integrated PhpBB2 (single login, single database)
Archive Support
Added user details
AJAX search across the site
Fantasy Hockey online (currently not implemented)
Added admin features including full user control, security log and information pages and adverts in the db
Picture enhancements including better gallery, re-arranged directory structure and a "who is in this picture" aka 'facebook' functions.
Additional squad filters by users' preferred playing position
More user preferences and attributes.
More match statistics including cards and a friendly option.
and so on....

Most of this is now done and can be seen at www.sheffieldhockey.com/beta

It's fucking hard work. It'll all be done soon though, nearly there

Steve

Currently Watching: Green Wing
Currently Eating: very little, damn bank manager
Currently Listening To: Pink Floyd
Currently Reading: A Scanner Darkly

Comments

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

Comments

I'm going to bring attention to one very important part of the evaluation, the performance tests. The image below is the performance graph that's in my dissertation

Look at the polygon count along the bottom and then the time taken up the left. Put simply, for integration into a game, the process must take less than 0.1-0.2 seconds (there are performance improvements to be added, one of them being writing it in C++ and the other being working directly with the Vertex and Index buffers instead of writing to memory first). This limits you to a polygon count of around 600 for a crackable object. Think about it, that's not too much, but it's enough, probably more than enough for most scene objects (look at Unreal Engine 3, most of the detail is in Normal and Relief maps, the actual polygon count hasn't risen much at all). Basically, this can be put in to a game, quite easily too, and it'd look very good and be very effective. Now all that needs to be done is for the right people to listen!

I've actually had a lot of fun doing this project in the last few days. Seeing it all come together is a fantastic feeling which is almost rivalled by the fact that it WORKS!!! (something I still can't believe really). I've learned so much about graphics, game programming design and how object-oriented languages are simply better than anything else. Visual Studio 2005 has been a pleasure to work with and MDX just makes things simple. Something in C++ like optimizing a mesh would involve a whole lot of pointers and guff, in MDX it's just Mesh.Clean(...). Why can't people see that for prototypes and technique tesiting like a project such as this is it's just perfect. If industry prototyped ideas often they should do it in MDX. No arguements.

Ah well, I'll let you know how the final version comes out when it's handed in in 12 days time Unfortunatley I now have to work on my other projects that I've ignored (1x concurrent systems, 2x programming language semantics and 1x computer games tech which is implementing an edge collapse algorithm... yay)

Steve

Currently Listening To: Hot Hot Heat
Currently Reading: ... through my dissertation
Currently Watching: Green Wing
Currently Eating: Bananas
Days until deadline: 12

Comments

This task is unfortunatly being hampered by my body. Yes, that's right, I've got a throat infection and since I went to the doc's on Monday to get some antibiotics I've been feeling rubbish. Constant headache kinda thing, not sleeping well and generally not being able to concentrate. Nor does it help that there's no one in my house but me, or that it's suddenly turned really sunny outside and I don't have a laptop. I've just gotta not let it get to me

However, some really good news:
The Project WORKS!!
After discovering my rather mickey-mouse error of giving a 16-bit IndexBuffer a 32-bit integer stream everything suddenly started working. Clipping works very well too and I appear to have gotten Clip3 to work too (Clip3 is a clipping case where all of the vertices of a triangle are considered to have been clipped by different polygons but there is infact still data inside the volume).
Here's a picture to show you:

This model is the 4000+ polygon model "tiny" supplied with the DirectX SDK. Some things of note. Currently, not all polygons are correctly wound. I need to get it to look at which way the original triangle's normal is facing and then wind it in the correct direction. Also, the mesh does not retain any texture data. This is quite simply because I'm not giving it any. For polygons totally inside a volume this would be easy to implement, however, for clipped polygons this would just be another thing to work out and it's quite tricky. This process also occurs in noticable time i.e. about half a second. With larger models this would be more noticable, with models of around 1000 polygons it may not be noticable.

To improve the performance of this method, I plan to multi-thread it to make use of my dual-core processor. Am I cheating? Not really. Basically I want it to have the initial intersection in the main thread and then each call to clip is in another thread. To avoid any indexing screwups the main thread will have to wait for the clip to join before it calls another clip or adds to the vertices itself. I'll have to run that past my tutor though, just to make sure it's not going to ruin everything or that there isn't a better way.

One final thing. It should be noted that I'm not cut out for 3D modelling. Since the generator didn't work and I'm having to manually make each crack pattern, then manually edit the .X file so that each polygon is double-sided and that it is indexed in such a way that each volume goes from one series of indices to another before describing any other part of the model. When you've just finished making a 200 polygon model, you know that's when it's going to get tedious and in my current mental state I'm just not feeling the love. As this entry title says, don't let it get to you.

Steve

Currently Listening To: M83, Pure Reason Revolution, The Infadels, The Raconteurs. 4 bands that I've only just started to listen to but all of them are utterly amazing.
Currently Eating: Amoxicillin
Currently Drinking: Masses of tea
Currently Watching: Deal or No Deal (UK version, infinitly better than any other)
Words in dissertation: 9,200

Comments

Right, this week hasn't gone so well so far. I've got far too much work and nothing seems to be going my way. Yesterday I lost the vote to get me elected for the hockey club's secretary position to a fresher who didn't really want it anyway. Very pissed off at him. This also means that I won't be on committee next year (as I don't intend to keep up my captaincy and the job of webmaster was given to a 6th teamer so that I could get secretary). So, in an act of foolhardy defiance, I announce the features for the next version of the hockey website.

Mission Statement:
To provide the members of the hockey club with an online portal for all their hockey related needs. At the moment it's a glorified message board, the next version will be a community (just thought, that'd be a cool dev codename). I want people to use it for all their activities and spend more time on the website. So, I want to open up everyone's profiles, give people so much more information about people in the club. Lots more comedy needed and little competitions off the main website. Everyone will WANT to visit the website.

Features:
The usual - events, news, matches, squads, pictures, newsletters, email sending
The new - Integrate PHPBB into it, merge their users data with ours and create almost a double profile, controllable from within the website. Message centers will have squad data in it too as well as PMs
More user data, squeeze every last ounce out of the website space.
Games - Fantasy Hockey Online, using the data from the match reports create an automatic fantasy hockey system
Re-work the CSS, give the user more control over the way they view the page

This work will take all summer in my spare time but the groundwork has been done in january. Integrating PHPBB will be the hardest part but I'm confident that it can be done.

Fat chance that anyone will read this so it'll be my little secret until the next committee meeting. yay!

Steve
Currently Listening To: Sum41
Currently Watching: 24
Currently Reading: Sheets and sheets of vertex data
Currently Eating: the same stuff every night
Average hours sleep a night: 5

Comments

This week was spent on the splitting part of my algorithm. Since I was unable to make a mesh out of my crack patterns I'm stuck with trying to disect a box with a plane. Shouldn't be too hard really but if I set it up right there shouldn't be any difference between splitting this and a proper crack pattern. However, most of my week was spent wondering why I was getting squiggly lines. The answer was that I was getting a CustomVertex.PositionNormal when I was meant to be getting a CustomVertex.PositionNormalTextured. The extra information was throwing everything off. Once I had that I discovered another thing. Each mesh has it's vertices "welded" i.e. for each normal of a vertex there is a separate vertex. This shouldn't cause me problems but may make normal computation difficult (however, i believe that I can perform this welding operation as a post-process and then calculate the normals again).

The next part of my week was spent wondering why I wasn't getting any triangles on one side. After discussion with my tutor I finally got the correct algorithm. This algorithm basically is joining a vertex in the target mesh to one in the plane's vertices. Perform a dot product on that vector and the normal of the triangle. However, this still didn't work as each vertex in the target was always over 90 degrees to the normal of the triangle at least once. I managed to get it to give out some vertices by changing the algorithm slightly (connect each vertex in the target to a different one in plane each time) but these positions appeared incorrect. After determining that they were incorrectly wound I re-wound them and tried again. Same problem.
It is at this point that I remain. I do not know why my program wants to make a triangle through my box when none of the triangles given to it do this.

Whilst I tried to figure out this problem I continued with my clipping algorithm. It is currently set up so that if one of the vertices on the correct side of the plane's triangle then it will perform a plane intersect with one of the two polygons and make 2 new vertices. The version for 2 vertices on the correct side will be similar but will create 2 triangles instead of just 1 (this bit hasn't been implemented yet).

If you'd like to have a look at this thing run you're more than welcome to it. It'll need .NET 2.0 and DX9 Feb06 to run but if you want to compile it you'll need VS2005 and the DX SDK. You shouldn't need a fast computer. Running the release .exe I got a frame-rate of 2000fps+
Current Project Source

As a bonus, if anyone can work out why this isn't working I'll be extraordinarily grateful.
What annoys me most of all about this is that I know I'm so close but I lack the other people in my department who know enought about 3D graphics to help me (and it doesn't help that my deparment's lab computers still run Win2000 so I can't install the DX SDK, nor do I have a laptop).

On a slightly happier note, the university's rowing club has asked to use the hockey website's teamsheet system for sorting their boats and crews. I've agreed to meet with them after my dissertation has been handed in but it's all looking good there.

I've got myself a job interview for the summer, working at the uni's IT center writing report forms for a new Oracle database..... fun fun (pay is half decent tho).

Extra-curricular activities (i.e. hockey) brings some good news too. The saturday hockey team (Sheffield Uni Bankers 9s) are currently top of the league and a win tomorrow will pretty much guarentee promotion, though full points from both of the final matches is needed to make sure we finish top.

Finally, I'm off home home this weekend to relax for once.

Steve

Currently Listening To: Gnarls Barkley - Crazy
Currently Watching: Maid Marian and her Merry Men (early 90s kids tv, effin awesome)
Currently Reading: Anything I can find on intersection
Currently Eating: Pringles
Weeks of coding left: 1

Comments

It's now the end of the week and I'd like to officially announce that this algorithm is failing. I implemented the algorithm from the last entry but that did not produce the correct result. Implementing a directional component to the path choice (when multiple paths are on offer) had some positive effect. The actual problem came from when there was only 1 choice and the general direction was not the correct one. Making it naiively always follow collisions produced infinite loops, allowing it the choice still produced infinite loops. I'm actually at a loss as to how to do this.

However, my tutor suggested another method for volumization, a grid based sweeping method that detects each "volume" from the endpoints on the left and then sweeps across until it finds a vertical edge in the paths. once it's found this vertical edge it records it and carries on sweeping until the end. This is much more difficult to implement than the tracing algorithm, but I don't actually have a choice at this moment in time.

It's not looking too good

Steve

Currently Listening To: Yeah Yeah Yeahs - Show Your Bones
Currently Reading: C# books of course!
Currently Eating: Toast
Currently Watching: The Commonwealth Games
Days until code is supposedly finished: 14

Comments

After a discussion with my tutor, a few methods of enclosing the crack patterns were suggested:
Endpoint-Distance Method
For each layer, take all the end points of the crack branches that did not collide with another branch.
For each end point, perform a trigg distance calculation to every other end point and join to the nearest end point.

This method did not work at all. After initial tests and a few attempts to fix it, the problem of two endpoints being exactly the same distance apart meant that my SortedDictionary (a sorted HashMap for any Java coders reading this) wouldn't accept the key every time due to duplication. Endpoints were also joining themselves to the wrong endpoints. The image below shows this method and its failings.

Shrinkwrap Method
This method was suggested by Steve Maddock, my supervisor. Making use of the fact that the crack pattern is grid-based, Steve suggested that I test every row/column from each side to find the point that is furthest out and then join those to make a shrink-wrapped outline of the mesh. However, whilst this will work every time, it doesn't produce the volumes that are needed for meshing, it instead produces a thin skeleton-like model of the crack pattern. So, not very good really. Picture below (please note, the problem with patterns not going to the end points has been fixed, but it still doesn't look much better):

Clockwise Endpoint Method
This method, suggested by my good self, is another method that is very similar to endpoint meshing but uses the angle from the point of impact to the endpoint as its key. It then joins the end points in the order of the angle they come out at. This method works very very well, it produces proper volumes and in pretty much the correct order too. This series of screenshots show front, 3d front and 3d perspective views of a crack pattern joined in this way (note that the pattern in these shots does not join back to itself, the pattern has been modified to do that since):

So, we've got to this stage. Now, for yet another tricky bit:

Volumisation of the areas
So that these enclosed areas can be put into a mesh, they have to be triangulated (and then the adjacency information for each triangle has to be calculated but thankfully that'll be easier). There are a few triangulation algorithms out there (Delauny, Seidel) so my main problem will actually be finding out which area is which! Below is the diagram I've currently got drawn on my white board (taken with phone camera ):

The black lines from the center point are the 'roots' of the crack pattern. All of the blue lines are 'branches' that have spawned during the process. The green lines are the borders of the crack pattern after it has been enclosed. The blue x's are the start points of the branches and the red x's are the end points of all of the branches or roots. Each volume has been labelled 1-12.

My idea for finding the volumes is a kind of 'tracing' algorithm:
Start with root 0; check each point on its path, see if a collision or start point occurred; If that happens then find out which branch/root it was and follow it back to its start/end (dependent on what you found), along the way checking for any other collisions/start points. If found, repeat the above step. Keep doing this until you reach the point on the root where you started tracing from. Take this path, it's one of your volumes. Keep doing this for each start/collision point on the root.
There are a few problems with this, there's no guarentee you'll get all of the volumes (as some don't contain root parts) and also, what happens when you find the edge?! There are also problems with coming back to the root as 4 cracks start at that point. Special cases will be created for all of these points, however, I think in general the algorithm will work. If anyone has a better solution please contact me (as I can't see any other way about it really).

After I've found the volumes I'm going to take a break from working on the fracture generator. I'm going to try and get the actual cracking process working with a simple manually made mesh (two planes in a cross shape). I hope to have some early results from that next week

That's all for now

Steve

Currently Listening To: Feeder
Currently Reading: Practical Algorithms for 3D Computer Graphics
Currently Watching: 24 season 5
Currently Eating: pancakes!!!
Score the mens 1s just beat Aberdeen by: 4-1 congrats!

Comments

After discussion with my tutor, there will now be a basic set of 10 different alpha textures, each with a number of crack patterns, all contained in a CrackLibrary. Each mesh that needs to be cracked will have a texture. Once the impact point is obtained, the program will read the location on the crack pattern that the impact occured and will then load the CrackPattern that originates closest to the location of impact. This pattern will then be translated/scaled/rotates based upon the force and direction of impact, then a Mesh/Mesh intersect method will be used to crack the object and many new Meshes will be created/cleaned/optimized and animated.

That doesn't really pose a huge problem at the moment. The thing proving difficult is actually converting my CrackPattern3D into a Mesh and saving it to the .X file format.
The major problem is that the 2 previous projects' patterns all had boundaries or definitive volumes meaning that when it came to intersect with the target, clear boundaries already existed. With my implementation, I'm growing a Crack sequentially from the impact point guided by a texture. There is never any guarentee that boxes/volumes will be formed. I also have no idea where or when this branching will occur, nor when a crack will collide with another or come to a region it doesn't have enough force to breach.

It has also been noted that the .X file format wants my Mesh in the form of triangles, preferably with an IndexBuffer and it definitly requires adjacency information which I currently don't know how to create (and MDX only has a void method for generating adjacency information).

From my previous tests (see other entries) perhaps my main mistake has been to have a black background (which indicates impenetrable material i.e. steel) so that in general, cracks don't propagate properly and definitly not to the end of their life span (use up all their force). Adding a gray background has improved the situation yet I still have very little idea as to how to work out which vertices belong to which volume. I am also concerned that I'll have to be working with triangles, therefore every side of each volume will be a triangle fan with quite a few triangles in it. I somehow think that I'd be better off writing my own format that contains volumes and polygons with >3 edges.

If anyone has some advice for me or can see a way around my problems please contact me. Leave a note here and I'll get back to you.

Steve

Currently Listening To: Oceansize - Everyone In To Position
Currently Reading: C# 2.0 The Complete Reference, Schildt
Currently Watching: The Constant Gardener, an excellent film.
Currently Eating: BBQ pringles
Amount of pain this problem is causing me: a lot

Comments

Anyway, project work.
Over the last week whilst I was avoiding revision I successfully abstracted the Crack class from the renderer. There are now 5 classes:
abstract class Crack - contains the generic functionality of a crack (drawring, spawn branches, cloneing etc)
class CrackRoot and class CrackBranch - use Crack as their base class and implement their own route finding algorithms. Branches now look for the second best node to go to, simply to stop the "boxing" problem. The cracks look really good now.
class CrackPattern - holds properties for the crack pattern and a list of roots and branches.
class CrackPattern3D - holds an array of CrackPattern classes. Also contains methods to join the layers and export the pattern (not yet implemented).

Update: JoinLayers() has now been implemented and so below I show you the fruits of my labour:

A low-resolution crack pattern with the unboxing algorithm

A high-resolution crack pattern with the unboxing algorithm

My first 3D crack pattern.

From here, I can now progress to Stage 2
This second program will be able to load .x files that have CrackPattern3Ds associated with them (I'll probably have to create a new file format or more simply, extend the .x format). You'll then be able to specify the location of impact and crack the object. This is going to be hard, really hard. Expect an update next week, possibly containing a picture of me crying over the problem. I'll get through it somehow.

I've been watching a Microsoft webcast by Digipen on 3D game development in C#/MDX9 and it's very very good. I asked a question to them the other day, "How easy would it be to multi-thread this game engine?". Their answer, "Dependent upon the part you're threading, very hard". Yet more good news for me and my dual core processor (which I was half relying on to make this run in real-time :s).

Outside of project space, the hockey website now has its third iteration of the picture gallery. Basically it categorises the pictures based on the associations in the database. I think it's what everyone wants and I've had no comments to the contrary yet so I'll assume that I can leave it now.

Back to work!
Steve

Currently Listening To: The Strokes - First Impressions of Earth
Currently Watching: Scrubs - 507 - My Way Home (homage to the wizard of oz, it's their best ever episode)
Currently Eating: Home-made special fried rice (when i get it right it's the best food ever)
Currently Reading: Does Anything Eat Wasps? - New Scientist
Project Deadline: May 3rd

Comments

Firstly, a comment on how far away from "photo realistic real-time rendering" we are. Answer... an awful long way. I'm considering photo-realistic to be a rendering engine capable of "Monte-Carlo" rendering (that is, a mix of ray tracing and radiosity that renders a scene perfectly). Consider this: A ray tracer (with bounding-box collision speed-up) needs to perform R*N*X*M intersections simply to work out how many objects the rays initially hit per frame (where R is the number of rays fired, at least one per pixel i.e. 1024*768 = 786432; N is the number of objects, say 8; X is the number that are hit, say 10% = 0.1; M is the number of polygons in the scene, say 10000. Total calcluation = 6,291,456,000 intersections). That number only rises with each depth level (due to >= 2 rays being produced for each hit). Try to do that at 60 frames per second and you'll need at least 50 billion intersection operations per second. That's just for the ray tracing. Radiosity method is an O(n^2) process. Even if each patch covers 10 polygons, that's still another 24,000,000 complex calculations every second. Such a method, even with all of the possible speed-up techniques would still require processors far far in excess of what we can manage today (ever wondered why a frame in Shrek takes 7 hours to render, even on their server farms? That's the answer).

So, how far have game engines come? Ignoring the perfection techniques of global illumination methods, how much can local methods do?

Well, there's the Phong reflection model. This allows you to calculate the intensity of light at any point on a model:
I = ambient intensity + intensity of incident light*(vector to light source dot vertex normal + (vertex normal dot halfway vector)^n) The halfway vector is specified as (vector to light source plus viewing vector)/2 and n is the degree of imperfection in the surface. Performing this calculation at each vertex and interpolating the result across the polygon is known as Gouraud shading and is a fast and very common shading algorithm. Phong shading provides interpolates the vertex normal across the polygon and shades for every pixel, therefore providing a perfect specular highlight. Phong shading, however, is 3 times more expensive due to the additional vertex calculations and normalising the vectors at each step.

What does this mean though?
Well, what I mean is that computer games don't use this method at all. Even calculating this algorithm in real time is too time consuming, even for today's processors (though there is an exception. See Doom 3 at the end).

So, how do graphics engines look so good?
Well, lets start with the Unreal Engine, version 2.x (UT99-04). I did a few levels for UT99 and I always wondered why I had to perform "BSP calculations" before it would render the "light map". Well, now I know. A BSP (Binary Space Partitioning) tree is one that divides a scene up into segments (not necessarily evenly spaced) and in its tree structure assigns a data pointer to the object that occupies that space (the area is sub-divided until only 1 object exists inside each area). The engine will be doing this so that it's lighting calculations can be performed faster as the lighting will only have to navigate the tree to see if there's anything to shade in the place it's hitting.
A light map is the ultimate way for a game engine to cheat. This same technique is used for drawring static shadows etc. Basically, a high-powered lighting technique is applied to every static object in the scene. This light map is then stored as a texture in memory and applied at game time. The Max Payne game engine used radiosity to perform this step (and back in 2001 it took aaages) and it gave some very impressive results.

So then, if all diffuse interactions are actually stored as a texture, how do they make things shiny?
Well, these days that's done with pixel shader. The Phong reflection model is performed as a separate stage in the rendering pipeline and that produces specular highlights (Battlefield 2's water effects are an excellent example of this). Pixel shader can perform translucency effects too and High-Dynamic Range Lighting (HDR, the latest industry buzzword) can be simulated using pixel shader (but done properly, like in the Source engine, it requires a few more steps).

Still, all of that requires a lot of horse power. So, how do you keep polygon counts down?
Answer: textures and bump mapping (displacement mapping requires extra polygons so isn't considered here). Textures provide much more detail for no additional polygon count. Bump mapping perturbs the polygon normals so as to produce raised/lowered sections when shaded by the pixel shader. The illusion of height is even more pronounced in parallax mapping (see the doom 3/quake 4 mod) and another type of mapping that is being used in Unreal Engine 3.0 (I don't know much about that, am interested to find out though).

So, all of this, combined with the standard viewpoint culling/clipping, Z-buffer hidden surface removal and distance fog provides a platform where good results can be obtained whilst actually doing very little in real-time.

So, what's the doom 3 engine then! Well, as far as I can tell, it performs Gouraud shading in real time. It uses no light maps, just an awful lot of pixel and vertex shader (which is why it requires a graphics card capable of DirectX 8 pixel shaders). It generates dynamic shadows in real-time (most likely with a shadow Z buffer but it may involve some other technique).

In conclusion, modern video games cheat. We don't have the processing power to produce real-time radiosity images so it all has to be an offline process. Maybe one day we'll be able to produce photo-realistic images in real-time, but that day is over 10 years away.

Hope you enjoyed my dissection of graphics engines. I hope that most of it is right! If anything needs more explaining just leave a comment.

Steve

Currently Listening To: We Are Scientists - With Love and Squalor
Currently Watching: Scrubs - Season 5!
Currently Reading: 3D Computer Graphics, Watt, Alan
Currently Eating: Toast with apricot jam... ooh
Hours till my exam: 30

Comments

Christmas has been a nice relaxing time for me and it's allowed me to completely forget about my project, however, it's also let me forget how to code (it happens to the best of us)! So, whilst I've been preparing for my exams (one of 3D Graphics theory and one on information searching and retrieval) I've not had much time to work on my project. I've also tried to work on the website code over Xmas as it needs some security stuff adding to it and a new gallery etc... However, the new menu system I've designed has lots of problems with the way security in the site works. So, until I can sit down and find a workaround I'm going to have to leave it as it is.

So, I've finally taken a break from revision and solved my "boxing" problem. A bit of heuristics and a fudged multi-dimensional sorting algorithm later and it all works very well. The next step is to put all that into 3D, firstly by just duplicating the pattern and extrapolating through the points. That's all that's going to be done for the moment as the actual fracturing stage is a lot more important than making the 3D crack look pretty. I do have to split my Crack class up though, too many things depend upon booleans and the file is now almost 1000 lines long. I'm thinking a simple Crack interface with a Root and a Branch crack (as these two have different node selection algorithms that are currently built into the one class).

So, I'll go and get on with that.

Steve

Currently Listening To: Sigur Ros - Takk
Currently Watching: Peep Show (thanks Amy )
Currently Eating: Chewing Gum (well, chewing, not eating)
Currently Reading: Profanisaurus Rex
Days till 3DGFX exam: 7

Comments

First: Project update
I didn't think I was going to be able to do it but lo and behold I created a crack pattern that followed an alpha texture. The key was in this bit of code:

Locking the rectangle got the multidimensional array for the texture (one for each pixel of the texture). After that and a few refactors later (including one which reduced the processing time by a factor of 5) I came up with a pattern that looked like this:

So all looked good there.

At this point it was time for me to concentrate on my survey and analysis report (yes, this is a dissertation so I have to write lots of stuff) and 2 weeks without any improvement to the code later and I come up with an 8000 word report I'll upload it later as I don't have a broadband net connection at the minute and it's a rather large file (due to post-processing in adobe acrobat).

So, two weeks after that is handed in (today) I sit down with the new December SDK and try to put my code into a .NET 1.1 EmptyProject (not a .NET 2.0 project as the VertexBuffer class seems to have disappeared and I kinda need that. I think it's gone into the generic GraphicsBuffer class but there's no documentation so I'm not touching it yet). Can I do it? Can I hell! There's either something wrong with the way I'm lighting it or there's other things wrong because I can't see the nodes or the crack for the life of me. It also crashes spectacularly if I try to resize the window when I've implemented a VertexBuffer (the VertexBuffer of course being called inside the OnRecreateDevice method). So, I give up on that and go back to my own simple window.

For my report I created a test set of textures that my crack pattern should conform to if they are to pass as a realistic crack pattern. However, with one of them, I noticed that the pattern was going into areas of black. These areas I had set the pattern to stop as soon as it reached it.... Turns out that my visual representation of the crack pattern was out by 90 degrees... however, I'm wondering why. AFAIK (and from all the text books I've read), UV coordinates start in the top left hand corner, and that was where I was doing my transformation to get the correct array index for the node. However, this rotation indicated that the UV coordinates infact start at the bottom left when the description is retrieved. If anyone can spread some light on this I'd be greatful.

So, with that worked out I produced a crack pattern like this:

It follows the lines very neatly and I was most impressed. However, there's one big problem.... little boxes. When it comes to re-meshing this, a small box like that (especially at high resolutions) will be a bitch to clip and re-mesh and will also increase the polygon count far too much. So, something had to be done.

Firstly, I stopped the branches from branching too often. Once it had branched a crack will not be able to branch until it has travelled a further 4 nodes. This eliminates some branching but does not stop the boxing (this is where because the root crack is following the line of most weakness, the crack travels one in its direction and then goes back one across and back to the root crack as that is the line of least resistence. Boxing will be solved by a different method alltogether.

The proposal of a heuristic search when the choosing algorithm doesn't know which direction any of the nodes it can choose from are travelling in is a tricky one. It gets ever more complicated if you want to look at the next node straight after that one to find out the sum of the two white values. I worked it out that it would take 16 if statements to properly work out that algorithm, and therefore it's a bit of a bitch so I won't be taking that option.
Instead, I'll be creating the getNextNodesHeuristic and chooseNextNodeHeuristic methods where the getNextNodes method chooses the nodes in a 2D array with the next node then its next one along as its pair. This will lead to a much faster chooseNextNode method, however, it does lead to some code duplication. These methods are only applied to cracks which are branches. These are denoted by a isBranch boolean value.

That's about it for the project so far. The above should produce some really good results which I'll then be able to take on to the 3D level.

The hockey website:
Well, I'm making some quite significant changes over xmas including:

New member properties (playing positions and other random things)
Staying logged in (cookies)
A new picture gallery (at last)
A new menu layout (no more disappearing login box)
Properly working email thing (FireFox compatible)
Text area formatting (so you can make news posts look pretty without knowing anything!)
New Admin areas
Security log
Generics: i.e. the ability to add pages to the website at will and change the name of the club and CSS style too.

Cookies are done, as are playing positions. I've also fixed a load of minor bugs since the start and it's pretty bug-free at the moment. The reason this is happening now is that the univiersity netball club wants the website for their club. Me and Paddy (co-developer) haven't had a chance to meet with netball yet but these upgrades will all go onto the hockey website first.

Other than that, about a month ago I got a phone call from ABI Electronics (see summer blog entries) firstly to fix a bug with the website (integer limit reached, fixed within seconds) and secondly to report how they'd been doing since the site went live. Answer:

Traffic to the website has doubled and orders have also doubled

For a company that has a turnover of over £1m that's excellent.... and they only paid me £1500...... I've been had!!!

Oh yeah, I've got exams in January, very boring.

Oh, and Merry Christmas to you all.

Steve

Currently Listening To: My old school's production of Little Shop of Horrors (I can't sing in an American accent)
Currently Watching: Late night poker. Why not?
Currently Eating: My mum's cooking
Currently Reading: MSDN Documentation
What Do I Think Of Office 12 Beta 1?: Signs of excellence, just get rid of the bugs!

Comments

This is my third year dissertation project. I'm a student at the University of Sheffield studying computer science. The working title for this project is "A Cracking Algorithm for Destructible 3D Objects".

What I aim to do is damage/fracture/crack/split/shatter 3D objects realistically in real-time. Why is this important? Well, did anyone else feel let down by hitting a plank of wood at its end in Half-Life 2 only to see if break in the middle? Did you put a grenade next to it and all that happened was the plank split in two?

The way I'm going about it is to create library of crack patterns based upon the amount of force applied to an object and a strength texture (an alpha texture). The crack pattern is then applied to the object at runtime (the right size of crack is selected dependent upon the object and force). The crack pattern is then used as a guide for the mesh to be split and re-formed with the shards then animated away in the opposite direction to the direction of the force.

Sound complex? Too right.

I'm writing this program in C# and Managed DX9 because C# is a brilliant language and Managed DX9 is fantastic too. It means I can just write algorithms quickly without worrying about any memory leaks, pointers or any of that rubbish that comes with C++. DX9 is so much better than OpenGL (which my course is teaching me) as it's an actual API, not just a list of commands. Visual Studio 2005 is an infinitly better editor than say Eclipse. VS tells me exactly where I've gone wrong and often corrects it for me! Eclipse's debugger gives unclear error messages and knows very little about 3D development.

Right now, I'm writing up my literature report. Most of my research comes from these two past papers by Dan Fox (2003)and Adam Miller (2004).
My next stage of experimenting involves getting my crack pattern in to 3D from 2D. After that I'm going to get a simple crack successfully working, then make it work with an actual crack pattern. Implementation of the alpha texture will probably have to wait till next term.

If anyone has any comments or suggestions I'm all ears, just leave them at the bottom.

Steve

Currently Listening To: Feeder - Shatter
Currently Watching: The Spongebob Squarepants Movie
Currently Reading: My Own Work!!
Currently Drinking: Tea from my Gromit Mug
Days Till 1st handin: 14!!

Comments

Hi-res image (0.5f between nodes, 61 rows and columns, threshold = 90%)

Hi-res image (0.5f between nodes, 61 rows and columns, threshold = 80%)

Hi-res image (0.5f between nodes, 61 rows and columns, threshold = 93%)

Lo-res image (1.0f between nodes, 41 rows and columns, threshold = 90%)

As you can see, a threshold of 80% (meaning a branch will occur 20% of the time) leads to the shattering of the object. A higher threshold leads to a much more realistic crack pattern. There is also the problem that most of the time, at least one of the cracks turn and hit another crack within 2 iterations. The only way of fixing this would be to check if the crack path is shorter than 3/4 nodes and if so, ignore lines meeting and accept them as possible nodes. However, this is a bit of a bodge.

When (read: if) I get the alpha texture implemented (really, if anyone has a clue how i'm gonna do this I'm all ears) the cracks will follow that texture, taking away some of the randomness (some will be left in however). For instance, branches will only occur when there's say a 0.75f white value or higher and even then it's still another 90% chance of it occuring then. Also, if the node is choosing high strength nodes (say anything less than 0.50f) the force will decrease at a higher rate proportional to the strength of the node it is going through.
This is all great in theory, I just have to make it work!!

The next problem is then the 3D stuff. Creating realistic shards and such. If I have the alpha texture implemented, it would be possible to use the fracture generator to create similar fractures based upon lower resolution alpha textures. However, since I don't have that at the moment I'm down to my backup plan (which may prove to be a better implementation anyway).

The idea is to take the crack pattern as it is backwards on to the next layer. Then, you start looking up a crack's path, finding simpler ways to get to that point. Say you looked 5 nodes ahead (on a low resolution model of course) and it zig-zagged from (0,0) to (2,2). The simpler way to that would be one vertex at (2,0) or (0,2) depending on the crack's direction. Higher resolution grids would need to read further ahead to be able to simplify patterns further. It would also deal with cracks that are, say, less than 4 nodes long and simply remove them.

Now, I hope to have something like that done for next week (all it really needs is a few hours of solid coding). I've got lots of other stuff to do, like write this whole thing up! I've got 25 pages to write for my literature review, thankfully most of it will be pictures

Right, gonna get back to it

Steve

Currently Listening To: The Divine Comedy - Regeneration
Currently Eating: Apples
Currently Watching: Doom, the movie (a bit rubbish really)
Currently Reading: APIs
Weeks Until 1st Handin: 3!!!

Comments

The next thing to do is to make the pattern more accurate. I'm doing this with an alpha texture of strength. This is going to be tricky for me as I'm not rendering to a surface, i'm just creating primitives in world space. To get the appropriate pixel i will firstly have to translate the co-ordinates of the texture into world space. Then I'll have to index the texture by node (possible by creating a node class). That would possibly be the best answer (by requiring fewer calls to the texture). This bit is going to be extremely tricky for me cos I have very little clue about texturing etc.

After that I then have to make the whole thing 3D and create a 3D texture from it. My first attempt at this will simply be to extrude the pattern backwards. After that it gets more complex. However, that'll come after xmas as the next thing that I want to do is to actually look at a polygon/polygon intersection from this 3D texture space. If I could actually get something to have cracked by christmas I'd be extatic because after that it's all bells n whistles, improving the crack, adding features and proper animations etc. If I can get these basic algorithms working properly in C# I might try and port the code to C++ for performance sakes. But that's a last thing to do kinda thing.

Steve

Currently Listening To: The Arcade Fire - Funeral
Currently Watching: Lost
Currently Eating: Chocolate covered hobnobs
Currently Reading: DX9 API
Currently Downloading: FEAR (can't wait)

Comments

This update is showing off my first attempts at the cracking algorithm.

After quite a bit of trouble with getting DirectX running and getting it to display lines on the screen (instead of the Line class I had to use DrawPrimitives as the Line class worked in screen space not world space) I produced my first crack pattern. That said, it was very poor:

After that, I added a few things. The pattern is now based upon the amount of force I give it (currently at 20, reduced by 1 after every node). It halts when it reaches the bounds of the grid and whenever it hits a node already visited by a different crack it stops:

You can see that the algorithm isn't particluarly crack-like. The randomness of the node choosing tends to either go in very long straight lines or double back on itself. Also, since one branch of the crack is done at a time you will get one long crack and three other smaller ones as they might collide with each other's paths.

There's also the giant problem of artifacts! Those diagonal lines from the ends of the crack to the point of impact should not be there! If anyone knows how to solve this problem I'd be greatful. This is what I'm doing.

Each Crack (crack is a class) has its own path (array of co-ordinates) and for each of those I call its DrawCrack method. This method creates a VertexBuffer for that crack, sets the stream to that VertexBuffer, translates the start to (0,0,0) and then uses DrawPrimitives(PrimitiveType.LineStrip) to draw the line, after which it disposes of the VertexBuffer. However, the program seems to be treating it as one big vertexbuffer. I've tried applying each vertexbuffer to a different stream but that doesn't work. I'm quite lost on this one!

The other problems will be solved by firstly supplying a node I'd like the crack to reach and it has to get there by any route of its pleasing. The problem of creating all the crack simultaneously may be a little more difficult to solve. It may be possible with a cascading switch but those won't lend themselves well to creating new cracks on the fly.

Other than that it runs really really quickly. The fps counter I'm using is actually limited by my screen refresh rate (need to fix that). In conculsion, a rather successful experiment!

Steve

Currently Listening To: Starsailor - On The Outside (great album)
Currently Watching: Pulp Fiction cos I've never seen it!
Currently Reading: Journals :s
Currently Eating: Anything that hasn't gone off
Currently Playing Hockey: up to 5 times a week!

Comments

Looking at the previous dissertations by Dan Fox and Adam Miller, and by looking at professional attempts at the same task, I've decided that they all have flaws in their projects. The professional ones don't run in real time because they attempt to model the literal interactions between molecules (modelled as verticies inside of an object) based upon very complex physics.
Dan got it wrong by firstly, using Java, secondly, taking a 2D pattern and just extruding it.
Adam got it wrong by attempting a continuous crack pattern in 2D many times and joining them up. This joining of the 2D patterns to make the shards was very complex to do and only ran at 10-12fps.
I'm doing it differently. The technique is a mixture of Dan's and Adam's. It uses Adam's 2.5D approach yet does it discretely like Dan. By this I mean the pattern starts at an impact point and grows in 4 directions towards nodes then grows the patterns out along the nodes depending upon the alpha texture (for strength) at that node.

So, how am I generating this pattern?
Well, I can't do it by modelling complex fracture mechanics because that wouldn't be achieveable in real time, nor does it lend itself to standard hollow polygon meshes in normal 3D computer games. Therefore, I have to produce something that looks like a fast fracture crack.

In general, a fast fracture follows the path of least resistence in the object. I am modelling the strength of the object as an "alpha texture" so I can measure the amount of white (weakness) at the adjacent nodes and the crack will follow to the node with the greatest amount of white.
To generate the crack splitting and forming new lines, I'm adding a randomness factor in to the algorithm. Therfore, every now and again, perhaps when an area is particularly weak, a new crack path will form.
As my research into crack patterns continues and my testing goes on the crack pattern will become more complex and give a better looking crack pattern.
The question that should come to mind is "But Steve, using a discrete model will give jagged crack patterns and no diagonal lines!" and my reply to that is: With a high density node grid, it is quite possible that the jaggies won't be noticed and diagonal cracks will form. Also, it may be possible later to incorporate diagonal lines into my cracking algorithm as long as they go to a node i'm not sure that it'd matter for the joining of the layers.

These additional layers could be produced in a number of ways. It could simply be another crack pattern generated from the first one with lines removed, or the crack pattern could be generated from the simplest one first. It could also be generated using a lower resolution alpha texture.

I should have a working crack pattern model by next week. It'll be quite simple at first. What I want is a full program working with a really simple model and then I can get on with improving it, optimizing it and all that other stuff.

My current quandry with DirectX is how to get information about the alpha texture back! Looking through the API it would seem that the TextureState.AlphaColor is my best bet, but how do I know exactly where the TextureStateManager is looking? I'll get something done for next week though.

Steve

Currently Listening To: Ministry Chillout Session 8
Currently Watching: Who's Line is it Anyway
Currently Reading: Journals
Currently Eating: Whatever hasn't gone off
Days I spent playing hockey last week: 5

Comments

The next thing to change is to move the login box, add cookies and more user details. The gallery is the next most important thing, then admin menus, new archives and member lists. I don't have a timeframe for these features, just when I get bored with my dissertation.

Dissertation
Well, I've been doing more DirectX stuff, I've got meshes imported, even got a small 'dodger' game going. I've also decided that DX9 was definitly the right way to go. Going through my OpenGL lab classes at uni I've discovered the following things.
OpenGl has no "Vector3" object meaning that co-ordinates need to be inputted manually or multi-dimensional arrays have to be used
OpenGL has no "Mesh" object
OpenGL's way of handling lighting, whilst being similar to DirectX, runs it a lot slower
Now, this last problem may be because of JOGL (Java OpenGL) but the first two aren't. It just seems wrong.
I've finally bought my own copy of the course text book which I have to read religiously. I've been told by next week or at the latest the week after I should have a 2D crack pattern generated. I've got an awful lot of work to do. Hopefully, from now on, whenever I have done some work or discovered a problem, I'll update my blog with some discussion on it.

Steve

Currently Listening To: Radiohead - Hail To The Thief
Currently Reading: 3D Computer Graphics - Alan Watt
Currently Eating: Bananas
Currently Watching: Superted (did u know that all of the main characters are gay?)
Hours a week I'm supposed to be working on my dissertation: 30-ish

Comments

The email system is coming, honest. It's just taking time as we have a few problems to work out.

Dissertation
I've written a short description of my project which can be found here. I think I've confused myself here, but the project does sound feasible. I can see it working in my head. However, I've just been to the library to get some books on fracture mechanics (as recommended by the guy who did the last similar project to this) and these books look really horrible. The real problem at the moment is that I've got too much on my plate and I don't know what to tackle first. Do I focus on the DirectX/OpenGL stuff (my lectures use Java/OpenGL) or do I start reading fracture mechanics books?
Personally, I feel that getting an engine running is top priority. I'm currently learning stuff in OpenGL, then trying to replicate that in DX9. I've got my first lab class tomorrow, so after that, I'm gonna try and replicate it. That sounds like a plan!

That's about it for now. I've got a new phone, same as the last one but in a much sexier black. Tho I only have this one cos I threw the last one at the wall..... oops!

Steve

Currently Listening To: Oceansize - Everyone Into Position
Currently Watching: triangles move around a screen
Currently Eating: Varsity burgers... mmmm.....
Currently Reading: Deformation and Fracture Mechanics 4th Edition - Hertzberg

Comments

Who the fuck is Lock really? Is he a psychic? Did a few weekends with his "father" really teach him to hunt like that? Is he so utterly wrong about everything that he's going to get everyone killed? The "Others", real people. The island is HUGE, there are going to be others. What do they want with Walt? Why did Ethan take Claire if Walt was the one they wanted. What was Danielle doing with Ethan so that Claire scratched her arm whilst escaping? What do the numbers mean? What is down that hatch? Is there a huge tunnel system? Why has the Black Rock not rotted away like its occupants? Why is there an elaborate mechanical security system which would seem to run all the way round the island. When Lock "saw into the eye of the island" (early episode) why did he not tell them what it looked like? Why did he not tell them it was mechanical? Where is this transmitter if it was apparently inside the Black Rock? Why are there 17th century explosives inside a 15th century ship?

I'm getting the first episode of the next series now, apparently it reveals nothing more. They're just teasing us!

Sheffieldhockey.com
Today it's had its first really big test. This morning I loaded it up with 400 members and it's coping well. The proper stats aren't in yet but google adsense impressions shows 3700 hits, the day before was 600 and the one before that was 300. I'm so happy that it's working well (though it has taken a full day of admin work to get it right). I've had a chat to my co-developer and we want to make this into a commercial product, however, the "portal" idea will take a substantial user base and currently, licensing the site to every uni in the country is a better idea. The code will take a lot of work, the whole thing needs generalising so that features can be turned on and off at will. It's gonna be hard but they payoff could be massive.

New PC
I've got my new computer now, absolute beast of a machine. My old pc, I was running Battlefield 2 on medium/low settings and it was going at about 25fps. This one, running at full detail, will be pushing 50-60fps. Windows hasn't given me any jib at all and it's gone so smoothly that I'm absolutely loving it. My old pc is being retired and sold on. Don't know who to tho. I'll advertise it in the uni. If anyone wants it, £250.

Uni
I've only got 4 hours of lectures a week, the rest of it is spent on my dissertation. This will take me all year, so I've gotta learn fast. I've got a book that I'll start reading tomorrow.

Steve

Currently Listening To: Hot Hot Heat - Elevator
Currently Watching: Lost
Currently Reading: Kick Start Managed DirectX 9 - Tom Miller
Currently Eating: Curry, again and again and again.
Amount of Free Time: Possibly too much!

Comments

I've been watching the .net show, reading Meltdown 2005 presentations and generally thinking about where game development is going. The general concensus is that development time and cost is going up and up but sales are rising only a small amount. Only the big games get big sales, graphically beautiful games the same. Limitations on computer power are coming up fast, multi-core is coming along to try and take this problem away, but not everyone can afford it. So, what's Microsoft doing about it?

Well, DirectX 10 (shipping with Vista) is going to try and focus on multi-core development and managed code. Managed code, that being .net common language runtime code (develop your code in whatever language you like, the .net CLR transforms that into native code and runs it at about 95-98% efficiency). This means you can start writing in C#, saving you about half of the development time.

The multi-core stuff, well, at the moment, multi-core development involves multiple threads inside the same program, Windows of course assigning a different thread to a different CPU/GPU. However, its not just like "I'll put the AI in one thread and the audio in another" because its very likely that they both want to communicate with each other. This is rather difficult to do efficiently, so the workload for a developer increases a lot. DX10 makes this easier (I don't actually know how yet, I think that's undecided). DX10 and Vista (through the Avalon platform) will also be able to push graphical menus onto the GPU, saving the CPU valuable time to do other things. This firstly means that your graphical menus can get much more fancy (have you seen the crystal-like windows in Vista beta 1?) but also that they'll run much much faster. Some GPUs are getting almost as powerful as the CPU these days, especially with SLI/Crossfire solutions.

As far as I know, DX10 doesn't have any updates to the Pixel Shader model, or vertex shader, or anything else, it's almost wholly a functionality update, however, for game developers its essential.

That's just my 2 cents about what's going to happen. I think its all great! Bring it on!

Oh yeah, I've decided to do my 3D project in C#+Managed DX9. I've also started buying in parts for my new pc. This morning, my graphics card arrived... nVidia GeForce 6800GT 256MB... mmmhmmm. The final system (i'll buy the rest of it as soon as Athlon X2 3800+ prices come down a bit) will be:
Athlon X2 3800+ (Dual Core)
EpoX 9NPA+SLI Motherboard
GeForce 6800GT 256MB
250GB SATA2 HDD w/NCQ (recommended for Vista)
1GB PC3200 DDR RAM
New case with 500W PSU

It's a PC that'll last me quite a while (especially since I can add another gfx card later ). It also means there's a pc for sale, athlon xp 2400+, Radeon 9800Pro 128MB, 512MB RAM, 40GB+80GB HDDs, case with 400W PSU, Gigabyte GA-7VRXP motherboard. Approx price, £250.

I'm such a geek, I know.

Steve

Currently Listening To: David Gray (new alubm is v good)
Currently Watching: The Island (Scarlett Johansson )
Currently Reading: DX9 API
Currently Eating: Apples
Hours of sleep/night: Not enough

Comments

C and OpenGL would be fine. And I'm sure C# and OpenGL will be fine too. As would C# and DX9. I don't mind what language combination you choose really. It will be the graphics ideas that are most important.
Sumo would most probably prefer C, DX9 and HLSL (High Level Shader Language - Steve). But likewise the graphics ideas are what are important.

Which is really noncommital. I have decided to go with C# because
1. I know Java and C# is very similar
2. You can import C and C++ libraries in if you need to
3. Doing 3D work in C# is actually going to be quite experimental, almost making it more suitable for a dissertation!

However, I still don't know whether to go with OpenGL or DirectX 9. Since I'm going for C#, I'm more inclined to go for DX9 as they work together really well and there's a lot of support for it through the MSDN. OpenGL requires a small C++ class for it to work but from then it's easy. I'm also being taught OpenGL in lectures and there are far more resources for it in the university library (even if they are really old).

I've been informed by a coursemate who has dabbled with this stuff before that I should go DX9 cos of its ease of use with C#, and that OpenGL and DX9 can co-exist in my mind. Also, I'll only be doing manipulation of untextured objects so I don't need most of the advanced functions of the languages, but DX9 is better for what I want. I'm gonna try and contact my friend at Microsoft and see what his take is, and then get them to recommend a book for me. Gamedev.net recommends a book on managed DX9 which has 100% C# code. I need to start re-reading my C# book again I think.

Oh, I also made some minor CSS changes to the hockey site, not worthy of a version number.

Steve

Currently Listening To: Guillemots - Made Up Lovesong #43 (limited edition ep, bloody amazing)
Currently Reading: "The Red Book" OpenGL Programming Guide
Currently Watching: Spongebob Squarepants
Currently Eating: Steak pie
Days Till Housemates and Therefore Sanity Returns: 2

Comments

Step:
Last time i'll talk about step. I did my presentation, everyone thought I did well, everyone except the judges. So, I didn't win jack squat so I'm even more pissed off at my payment for step. All over and done with though.

Dissertation:
I've been investigating 3D renderers and all that, and have recently been put off by C++ (Windows Vista is mostly coded in C#, a much easier language). So, I went looking for the easiest option (I have so much to learn the easiest way will be the best cos I have to learn so much for all this). C# works very well with managed DirectX 9, it kinda works with OpenGL but there's a small workaround to get it started. C++ works very very well with either DX9 or OpenGL. DX9 is more complex than OpenGL as it's a Microsoft Language but it goes to a higher level, there's not a huge difference between them. However, at uni, we're taught OpenGL with Java (Java being criminally slow thanks to the Virtual Machine (VM)).
I'd like to do it in C#, I'm gonna send an email stating my case. Also, I'd love to be able to all my coursework for that module in C# instead of Java. That might shake the department to finally moving to C# and away from Java.

I've gotten an OpenGL book out of the library to get me started. I'll try it their way to start with (C... urgh) and then try it out in C#. See how it goes.

Steve

Currently Listening To: Editors - The Back Room
Currently Watching: High Fidelity
Currently Reading: OpenGL Primer by Edward Angel
Currently Eating: BBQ Pringles
BitTorrent downloads currently running: 15

Comments

Hockey Website/Unisport
Firstly decided whether unisport will rear its head this year. If yes then a full roadmap will be drawn up and a rather relaxed timescale will be drawn up for site improvements so as not to clash with my dissertation. Things will follow that and everything will go along. Oh yeah, and I'll actually tell you what unisport is!

If no, then unisport will be postponed a year. Any additional features to the hockey site will be added at holiday times only and these will not be major features, just small things and bugfixes.

Dissertation
Well, I've gotta really start learning my stuff now. I think this is now my priority, especially since the hockey site is now stable. Such a shame that at the moment I don't really understand it. I'm sure i'll post my musings on it here later. I'm going to concentrate on C++ first, then do the 3D theory, mostly cos I'll be doing the theory inside uni modules. No need to do it twice, but I will have to stay ahead of everyone

It could be a really great year. I'll keep you posted

Steve

Currently Watching: Tarrant on TV
Currently Listening To: Bloc Party (STILL)
Currently Reading: 3D Graphics Theory
Currently Eating: Picnic food
Days till freshers week: 21

Comments

SUHC v1.9.10
Added: Thumbnails
Fixed: RSS
Fixed: Birthdays
Changed: upcoming events are now the next 3 events no matter how far away they are

Thumbnails are working well, website traffic is up and yet bandwidth usage is down. A great result.

The picture gallery really really needs re-doing. It's very ugly and needs a good kick up the backside. Then it needs a full re-write. I might try and find some free gallery classes for now and then customise them to my own needs.

A new gallery is due in the v2.1.0 update.

STEP:
My report and presentation are going well. I have got to finish them tonight. I've been doing press releases and brochures for the past few days, all good.

The website will FINALLY get launched tomorrow, pending press release acceptance and a final check.

I'd also like to wish my friend Emily a happy birthday

Steve

Currently Listening To: Editors - The Back Room
Currently Watching: The Family Guy Movie
Currently Reading: Press releases
Currently Eating: spag bog
Days until STEP finishes: 3

Comments

SUHC v1.9.9
Added: User birthdays back in
Added: Poll using Advanced PHP Poll (free)
Added: RSS feeds for News and Events
Added: Message after login telling you that you've been selected for a match
Fixed: CSS - background colour now closer to the gray of the navbars
Fixed: News articles not updating

Regarding bandwidth usage:
Looking at the hockey site's webstats you can see that we've used 80Mb of bandwidth in a little over a week. That's with an average of 30 users a day. What's gonna happen when 160 users look to see if they've been picked on a Monday morning. What about people uploading pictures from the socials on a Thursday? It's gonna use so much bandwidth and frankly, the site might not take it. I've located the main use of bandwidth and that is, of course, images. Currently, there are no thumbnail images for pre-viewing, slowing the site down and using huge amounts of bandwidth. Therefore, a thumbnail system has to be built.
The way I'm gonna do it is simple, make a lower resoultion copy and put it in a folder called thumbs inside the user's img directory. The thumbnail path is simply the image path but with an additional thumb in it. However, I'll still have to ammend the database to make queries to it faster, but it's a small price to pay.

STEP:
website nearly completed, was recently described as "so 1990s". Giant who cares.

Steve

Currently Listening To: Bloc Party
Currently Watching: 24 Season 3
Currently Reading: The newspaper
Currently Eating: Whatever my housemate puts infront of me

Comments

Yup, I'm running out of things to change! The jump in bugfix version reflect the major size of the account activation challenge (actually it went through first time but never mind). I've sent out emails to the whole club who are in the database (147 people so far) and only got 10 back from not having an email address or having an incorrect address.

I'm now playing with web polls. I've found a great set of scripts called PhpPoll so I'll be using that until I write my own (could be all year

One thing about the activation that did bother me though. The tutorial I found to help me do the en/decoding told me to use the md5 hash on the password and then use md5 again on the resulting hash to get the original back. This is clearly wrong as it just generates the hash of the hash string! Therefore base64 is used for each of the password and userid strings. If anyone knows why it was recommended that I md5 something twice I'd be greatful to know. The article i used can be found here

Steve

Currently Listening To: Coldplay - Fix You
Currently Watching: England beat Australia
Currently Eating: leftovers (yes, still)
Currently Reading: boring press releases and not much else
Currently Bored at Work: 60% of the time

Comments

Why the minor version jump?
Although email is not finished it is not being developed by myself, other parts are. Therefore I'm gonna keep raising the minor version as features go in. Scorers is in 1.7.0 therefore it's jumped. Also, the top scorer is now on the front page, nice little feature I thought.

STEP:
I chaired a meeting today. Showed the finished website to the boss, he liked it (i think). I've got lots of stuff to follow up on, will say more soon.

Finished Dan Brown's Digital Fortress today. I wasn't exactly disappointed, it was worse than Angels and Demons though, and I'm also shocked that none of the "greatest minds in the US" had never done chemistry. I guessed the final code within seconds, it took them 10 minutes!! Losers

Steve

Currently Listening To: Feeder - Echo Park
Currently Watching: TV again!
Currently Reading: Nothing
Currently Eating: leftovers
Final date on the SUHC Roadmap: - September 2007

Comments