Project Update: Solar Flux

Well it's been a while since I posted, that's because I've been working hard finishing up my degree, and collecting all the content togeather for my online portfolio.



Anyways, I thought I'd share some quick gameplay footage of our alpha playable for solar flux.

Project Update: Solar Flux

Feature: Lights & Effects

Things are really coming along, the last few features are making their way into the game engine.

Recently I've been working on the lighting and effects. The effect engine is alpha complete. We're really pleased with the results we're getting, by having a custom effect tool (Unholy Mess) it's allowed us to have alot of power over how the effects in the game will look.

The lighting engine is in its early phases, and I personally feel it will end up having a huge impact on the overall result and look of the game.

The following video is some test footage of both the lighting capibilities and the effects engine. Enjoy.

Project Update: Solar Flux

Feature: Mesh-Batching

In my last post, which I admit was a while ago (this is because I've been adding loads of new features to Unholy Mess), I was ranting on about Mesh-Batching.

Well since that post, I've integrated Azzaman's Frustum detection and my Bounding Volume Hierarchy code, which means non-visiable meshes are actually not draw, which inadvertantly boosts the total number of meshes that you can play with in a scene to about 100 thousand, which is actually absolutely insane.

So as a result I knocked togeather a little video of an asteroid field, with some depth of field applied (DoF is very expensive, my little laptop cries and slows down to 30FPS), I also did a quick flocking algorithm and stuck some drones in to help give the scene a sense of scale, at which point I removed the DoF. Everything is happily rendered in full HDR !

Anyways, enjoy.

Project Update: Solar Flux

Feature: Mesh-Batching

It's not as good as mesh instancing, but it's certainly quicker and easier to implement than mesh instancing.

On the 8th of april 2008, Solar Flux will be mock pitched, and our prototype demo shown to members of Team 17, so these last few weeks certainly are requiring that some corners be cut, so we can get our little presentation togeather. As a result, one of the features which we will be handling at a later date is mesh instancing, there just isn't time to get all the features into the game before the 8th of april. Without any form of instanced mesh rendering, its time to say goodbye to the idea of 10,000 asteroids on screen and approch the problem in a more pragmatic manner.

Thusly I've begun implementing a batch rendering technique, which is certainly adequete for now, on my meager laptop it begins to drop below 60FPS with 4000 meshes being draw, which is quite an improvement over the non-batched rendering result of about 800.

While 4000 meshes are available to be batched, it's more likely that the technique will only at most be used on 1000 meshes at this stage, but atleast we can render 1000 asteroids now, before that would have been a mere pipedream... Oh and did I mention that they're all normal mapped?

Project Update: Solar Flux

Feature: Unholy Mess & The Chaos Particle System.



I promised that when I had chance I would, or should I say when I had completed more of it. Which I now have, I recently added a brand new emission system.

This takes our particle engine and treats it like the filthy whore it is, an absolute Unholy Mess. I don't think any self respecting programmer could work on a space shooter without having a top notch particle system capible of thousands of different effects.

There are still pleanty of features left to go into the system, such as a hierarchy control so subsequent particle effects can be played in the correct order to achieve said final result.

Anyways I ramble too much, so without further ado... The Unholy Mess Emission Tech Demo.

The video took about 1.30 hrs to 2 hrs to generate all the particle effects, and composite the video. Some effects I admit aren't great which is probably my own fault, but I took alot of care with one or two of them and I hope it shows, with some effort some really great results can be had.

Thanks for your time.

Project Update: Entropy Earth

Feature: Applying the Skin(CPU)

It's really early on in the development of applying a correct 3D skin, to my skeleton of a tree which has been generated using an L-System, but as I actually have something new on screen I thought I'd share it with everyone.

So what's wrong with this picture? There is currently no varience in the radius between trunk and branch, there is no code in place either for correct blending between limbs, nor is there any sort of correction to the verts in regards to direction. This is afterall a very early prototype, I am currently more interested in getting features working than getting it to look all nice and pretty.

If the code is written properly, actually getting the L-System to generate a more accurate tree is a matter of L-System construction, so it can all be tweaked later.

Project Update: Solar Flux

Feature: R.U.S.T. & Unholy Mess

Well I've done pleanty today, or should I say yesturday, well... It's still thursday for me in my head.

Anyways, I've fixed a bunch of bugs, highly exciting stuff honestly! It's quite frustrating if anything, because bug fixes don't always count for much outside of stability of the software... Well at times that is true, certain bug fixes actually get something new working.

As far as feature updates go, R.U.S.T. has an axis manipulation tool, which can be kinda handy, and now the material colouring selection is thankfully flawless.

Unholy Mess is a tool I haven't yet spoken about, it's basically a particle editing suite which allows for a user to generate and test particle effect settings before implementation in engine.

Heh, It's called Unholy Mess because it's initial incarnation was code wise, my idea of an absolute unholy mess. Infact it was so full of hacks I'm surprised it ran.

Anyways... Not very exciting I know, just bug fixes... Although, they should be finished at some point next week if things go well, so I shall profile them both in more depth when the time comes.

Project Update: Entropy Earth

Feature: L-Systems in 3D.

L-Systems on 2D planar surfacesare incredibley easy to construct and manipulate. My system also allows for 3D L-Systems, which when you actually get down to writing one, isn't as easy as a 2D L-System, it requires a more complicated L-System to generate a good result.



So after much adoo, I've created what i would call an acceptable tree structure:

This will be my Base shape, now to slap a nice acceptable skin on it...

Project Update: Solar Flux

Feature: The Power of the Othala Engine Material System.

The Othala Engine boast a very capible and powerful material system which can be manipulated through the use of the R.U.S.T. tool which has been designed for use with the Othala Engine, materials can also be hand scripted and providing that the artwork is decent the results which can be yeilded from the engine I believe are very impressive.

It is worth noting that all the initial shader were written by the one and only Micheal Short. I have extended these base shaders to include extra effects. Mike has also written a bunch of post-processing effects which I will cover at a later date.

So on with the show.

We begin with the most basic shader avail to anyone when using the Othala Engine.

Ambient Colouring:

Shaders don't come any simpler than this, you literally set a colour for the mesh to return and hey presto you get a very simplistically shaded object, it's excellent for debugging and performance testing.

Textured Ambient Colouring:

This allows for a single texture to be placed onto a mesh. Such techniques may seem somewhat useless, but if you observe the first picture you will see that the mesh has subsections, and different effects can be placed onto each subsection, ambient textured colouring is especially useful with HDR for faking light emission.

Next we have the most basic complete lighting model.

Phong Based Per Pixel Lighting:



This is a basic method of treating a surface as if it is uniformly shiney. Note that the red centre isn't reflecting light, that is due to that part of the mesh being rendered using Textured Ambient Colouring.

Ashikhmin Specular:

This particular method of lighting allows for fine control to be place over how the light spreads across the object.

Normal Mapping:

Normal mapping is fairly common in games nowadays, it allows for fine control to be place over how the surface reacts with the lighting, on a per pixel level. This requires a colour map and a normal map to be generated.

Phong based lighting with Specular Mapping:

By adding the specular map we can dictate how the light interacts with a surface. Nice result I think.

Ashikhmin Specular with Specular Mapping:

Normal Mapping With Specular Mapping:

When we add HDR to the scene as you would expect for such a game, the magic really begins to come alive.

Adding a new shader to the renderer is very straight forwards, so expect to see more material processes as time progresses.

And here's a video of all the effects rendered in full HDR. Though as I reminder I knocked the materials togeather in next to no time by hand, and didn't tweak the HDR settings, so some of them don't look anywhere near as good as they could.

Project Update: Entropy Earth

Feature: L-Systems

L-Systems are a funny idea, I personally view them from a perspective of they're a language within a language which writes itself based upon the rules of a said language. Which is exactly what they are... But they're not that complicated at all really.

The process of generating something with an L-System requires that a grammar of some description is defined, and that the elements of that grammar have a result. It's Computer Sciene 101 stuff in alot of ways, and in a bunch of others it more parsing and language translation.

Okay, so I figured that it's probably best to allow whoever is writing said L-System to have absolute control over it so, the grammar is defineable. I'm currently using the following:

'X' ->"D[+X][-X]DX"
'D' -> "DD"

When we construct our string using our defined rewriting rule what we end up with is something like as follows:

X ->"D[+X][-X]DX"
D[+X][-X]DX - > DD[+D[+X][-X]DX][-D[+X][-X]DX]DDD[+X][-X]DX

This string obviously grows and grows at a dramatic rate.

This is a common grammar, we use the initiator X and then set a number of iterations, and as a result I feel a good starting point, which provides a basic 2D result.

While this is obviously a work in progress, it's always nice to have good results early on.

Okay anyways, once the L-System generates it's final resulting string, which may I add over the amount of iterations in the image is a very large string.

The characters of the string are parsed, which gives us our mini-language each character yeilds some manner of result, this is based upon Old Turtle drawing systems.

So I'm using:

{D} -> Draw over a distance.
{+} -> Positive Rotate on Z Axis.
{-} -> Negative Rotate on Z Axis.
{R} -> Right Rotate around Limb.
{L} -> Left Rotate around Limb.
{[} -> Push Data onto Stack.
{]} -> Pop Data off of the Stack.
{(} -> Number Input Begin.
{)} -> Number Input End.

While I'm not currently using all the commands that I have written, I am starting to open up a tremendious amount of power, notice that X isn't a command thus X is ignored when we come to draw out the result.

Project Update: Solar Flux

Solar Flux: Othala Game Engine & Gebo Physics Engine

I've recently started the Bounding Volume Heirarchy for Solar flux. If you don't know a BVH is basically a Heirarchy tree which stores well pretty much whatever you want, withing a bunch of bounding volumes.

Building the generic bones was rather easy, and I'm impressed with the results this far, traversing the BVH is amazingly quick, I ran a few tests, and using a single thread it could traverse 80,000 nodes in 0.05 seconds, which considiering I haven't optermised it yet, I must say that's a fairly impressive number, and better still when rendering 100, 1500 polygon meshes using normal mapping and ambient colouring it only took 0.005 seconds.

I also finished up parts of the renderer, I've introduces effect technique manipulation and some new lighting methods. While the basic renderer is finished so to speak, you merely need to supply it with a mesh and something will render, that rendering usually takes place using predefined material and effect settings. I've added the ability to render meshes with external techniques and effects as well, so the engine doesn't require each mesh to have static effects, which isn't the case anyway, its purely for render speed that the extra memory is spent.

Solar Flux: R.U.S.T.

R.U.S.T. or The "Really Useful Shader Tool", is a basic material editor which is being built for use with the engine.

I switched out the method of material colouring assignment, so it uses a Colour Swatch, this should dramatically speed up the amount of time it takes to build a material for meshes. I also fixed some generic bugs lurking in the system.

R.U.S.T. still requires alot of work, and some of those tasks include Axis offsetting, Lighting manipulation, Null Correction and Particle Effect Assignment.

Welcome....

I used to have a sparodically updated blog on MSN, but I decided to branch out, so now my blog will exist here! A fairly nice place for nobody to read a damn word that I write, just another voice in a sea of well... Voices.

Anyways, I'm hoping that I will be able to document software that I have written previously, and software that I am currently writing. Which if you're ever had the misfortune of meeting me, you will know that its all I ever talk about anyway. You could say I'm a little obsessive about it all, but better that, than being addicted to WoW, atleast I'm being productive!

Opposed to sitting on my arse all day grinding XP and forgetting to eat, I sit on my arse cutting code and forgetting to eat, that could be percieved as productive? Couldn't it?

Ahhh but there is that one problem that gets in the way every Tuesday and Thursday, University... Its such a pointless endevour for me now, the only class that feels like it has any substance is Neural Networks, and the rest really are a waste of time... "I've got CODE! to write damnit, I dont wanna listen to folk repeat stuff that I already know or dont give sweet fa about".
Well as deadlines will be looming I imagine I'll be making the trip from Sheffield to Huddersfield less and less, as time itself is a precious thing, and if I give it up to pointless endevours just for a tick on a sheet of paper I'll never get anything of substance done...

So as it is my final year, and I'm coming up towards my favourite time of year which is, crunch time! I'm hoping to take an hour or so everyday to document my progress on my projects in this final year, as a way of taking some kind of a break from it all, so hang on to your seat folks over the next few months its going to be a insane ride... I've got the potential Dream Build Play contender Solar Flux a new twist on the space shooter, which I am happily developing with Mongoose Games, currently a pseduo-company, as part of our team project module on the course, the DX 10 Engine I am working on for my final work, Entropy Earth, which should see how far I can push procedural generation of mundane object like trees, and whatever I manage to throw togeather for ChiChi, which I'm utterly undecided upon... But hopefully it'll be enough to entertain myself :-D.

All that said though, first thing on the list is to cover previous works, stuff I worked on last year, at Canalside Studios.

Canalside Studios: Softography

So here are some projects I worked on at Canalside Studios, ahem, and a horrible year it was too...

G3 - Lead Programmer












G3 or Gravitas as it was often refered to inhouse was a Canalside Studios project which was bizzare to say the least. The only way to explain it, is as follows:

Take one cube, add some tetris style block upon its surface, add some bizzare characters, give them suction devices and send them off running after a ball in an attempt to suck the ball up and then shoot it at a target.

The official line would be that it was "cancelled due to lack of resources". Which is true enough, the project always needed more people than it had, the following video is a snippet of the generic features of the engine.



Status: Unfinished & Cancelled, percieved as a R&D project.

Yo Ho Kablammo! - Additional Programmer/Research and Development

The premise of "Yo Ho Kablammo!" is very simple.

Each player controls a pirate ship in a play arena, the premise is to score more points than all the other players, the player with the most points wins.

Players gain points by collecting mines, treasure, and blowing other players ships out of the water.The uniqueness of Yo Ho Kablammo! Is that when the player collects a mine, it is primed to the players colour, any other player which hits the mine then takes some damage as a result, the mines were thrown from a central island by a monkey.

A very successful project, it came second in the 2007 XNA Dream Build Play compitition, held by Microsoft in Seattle at their Gamefest conferance. In coming second in the compitition the project was offered a publishing contract.

Status: The game is still in production by core staff at Canalside Studios, but is due for release on the X-BOX Live! Arcade, at some point in the future.

Hexothermic - 2D Engine

A very simple puzzle game where the player attempts to cause a chain reaction and destroy all the atoms on screen.

The player is limited by the number of clicks which they can spend to change the state of the atoms, the atoms exited in 5 states, after the final state they explode sending out particles which are added onto the surrounding atoms, by causing a chain reaction all the particles on screen could be disposed of.

http://video.google.com/videoplay?docid=-8083171989016147682&hl=en-GB



Status: Unreleased.