Cliffski's Blog

So I’m working on various stuff I’m not talking about yet for GSB 2, and I ended up with the image below. All looks fine, it’s a ship nicked temporarily from GSB 1, with some tweaks, and I found a bug. The bug is a bit of a pain, and it’s those 2 little axillary engines in the middle towards the bottom. Those engine glows are not supposed to be there, they are supposed to be under the ship.

But they aren’t.

And I could fix this really easily, but actually, it is kinda cool. I mean…why *shouldn’t* i have a few ships with engines that sit above other elements of a ship? the more creative freedom the artists have the better right? and that way the glow from the engines will illuminate the ship ‘fins’ in dark battles. It will look cool. It also means a shedload of irritating fiddling with code that already looks like a psychotic kitten has had a panic attack in a spaghetti factory.

but hey, I’ve trained myself never to think like that. If it makes the game better, I’m going to commit to supporting it, even if it makes life awkward for me. Expect this game to ship sometime this millennium…

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!