Month: February 2014

So after a lot of mucking about with render states and blend modes and shaders and reading, and z buffers and other tedious things i think i now have the previously unattainable mixture of proper smoky effects, happening in 3D with my shadow casting and bright ‘burn’ laser and flame effects all working together. This means a ship exploding can look like this (click to enlarge)

Which I’m pretty happy with. Those particle effects are all a mess, placeholder stuff that I can fix easily once I’ve rebuilt my editor for them. Plus I need to add a lot more stuff, and also those ships are obviously just modified GSB 1 ships not designed to take new lighting capabilities into account fully. I also need to fix some boxy depth-of-field artifacts for the distant asteroids. Next on today’s agenda is likely to be getting ship hulks to cast shadows (easy!) and then work on letting hulks drift in pseudo 3D (towards or away from the camera, but always planar, as they are sprites after all :D).

So what was the solution? Well it was as I suspected (amazingly). I just needed to take the key scene objects, the hulks, the ships, the turrets (which are separate items) and the asteroids and draw them to my own depth buffer. I then set that depth buffer to be texture layer 2 when rendering the smoke & flames (so that I can reference it in a shader) and just set alpha to 0 for any pixels where the depth buffer is closer than the particles I’m drawing. Right now I’m using a manually created and rendered-to depth buffer, so it’s actually a render target. You can’t in Directx9 have a z buffer that is a render-target, so I might experiment later with toggling the z enable on and off and using a standard directx zbuffer. I’m guessing that internally the card drivers can simultaneously render to a dedicated Z buffer AND the current RT, whereas if you use a manually created RT it’s a separate call. It’s no big deal because I build up a ‘deferred’ list of depth buffer render objects in the engine anyway, but it would let me reduce my video memory usage.

To recap, I’m doing all this because I want the smoke effects to be rendered last, so I can do some clever-ass light compositing that excludes them, such as laser beams lighting up the ships they pass over.

Non-Programmer version: “Blah blah geeky geeky…Explosions!” :D

Sooo…consider the image below (click to enlarge) it’s from GSB 2. A ship has blown apart (no bright fire pixels yet, just clouds of smoke) and there are smoke plumes. So far so good right?

Sadly no. The problem is, that ship was in the distance, and behind all the other ships, but if you are really eagle eyed you will notice the smoke plumes get drawn above the ships next to it, and this is a HIDEOUS RENDERING ARTIFACT. For complex reasons to do with the way I build up lightmaps and composite them back, I can’t just draw the smoke cloud after I draw that far-off ship, and then let other stuff render over it. I do some nonsense with multiple render targets that means despite using a ton of transparency and ruling out a conventional Z-Buffer system, I have to render some things out of order. So those smoke plumes are actually rendered last, just before I do my (slight in this screenshot) bloom effect. This lets me have them work sensibly when it comes to obscuring lights behind them, and avoids other artifacts.

The problem is…I need a way when drawing them to prevent them appearing in front of far off objects. Thankfully I have z-positions for everything, so in theory this could be done, although reading up on it, it seems like a conventional z-buffer is not going to cut it, due to it being all translucent smoke particles. So… right now I’m considering the experiment or the day is for me to create my own z-buffer, fill it with the ships (and asteroids) and their z-positions, and then manually compare the z-positions in a special shader I can use for drawing the smoke plumes. In my head, I know that even if this works perfectly, it won’t work perfectly…because there is nothing to stop a smoke plume going ‘through’ a ship. But hey… we can live with that, as long as ones in the background don’t get obviously drawn on top of things in the foreground. Because GSB 2 uses a lot of parallax, it looks slightly 3D-ish, and I don’t want to ruin that effect.

This probably will all go wrong, it’s one of the many experiments you go through when you have an unusual game and your own graphics engine. In my head it seems easy. Create new offscreen render target (yikes…performance), render all of the items I want to sort to it (yikes…performance), using their z-position as the value written to it (it could be a simple and small 8bit format), then set that as a texture I can read from my smoke-plume shader, pass in the Z value to the shader and compare the two, setting alpha to be 0 if the pixel should be obscured. Job done right?

Place yer bets!

Sooo… I’ve been experimenting with lighting of spaceships for GSB 2. If you played the original game you might be aware that although it often looked pretty l33t, it also had a tendency to look a little ‘flat’. The lighting was always the same (apart from the odd ‘global’ shader effect, and it could certainly have had more depth. This is one of the things I wanted to address when re-doing the game. The original game just had simple sprites for ship hulls, and the new version is tons more complex and lets me do lots of magic. Basically, I combine sprites for the ships with normal maps, and specular maps and lightmaps, and use a shedload of different shaders and render targets to do all kinds of compositing voodoo. So here I present some early screenshots showing me monkeying around with the options I now have. It’s a GSB 1 ship (as a test) and it looks like ti has another one stuck to the front of it. This is a test of something else (secret!) but it shows how one ship can now cast a shadow on another (Not correctly positioned yet, but easily fixed…)

So here is a screenshot showing the bloom effect everywhere: (click to enlarge)

Here is one with the bloom effect turned down but the 3D bumpiness up a bit:

Here I turned down the exterior lighting, and may have moved the lighting direction too:

Now I’ve gone full-on moody lighting and likely moved the light again:

Now I’m in real ‘dark-battle lit only by the light of our warp engines mood:

You really need to see it all big screen (and moving!) to see the full effect of it all. And you also need to compare it to the original flat looking default-shaded sprites in GSB 1 to imagine the final effect with all the battle raging around it. I’m quite pleased with it so far, although there are loads of things that need improving and tweaking, and no doubt needs more optimizing. It’s a start though!