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.