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?

screenshot_27-02-2014_10-42-25

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!

7 Responses to “Fun with 2D game engine rendering algorithms”

  1. You can achieve this easily simply by having depth comparisons on, but depth write off when drawing transparent objects. This will then cull the fragments of the transparent objects properly against anything drawn before them with depth write on.

  2. Bram says:

    You have a bigger problem…. There is no smoke in space!

  3. Alex says:

    I don’t really know how this stuff works, so I’m guessing here. But based on your descriptions, could you try the following:

    – draw the scene as normal, with background ships, then foreground ships, then smoke

    – as you go along, save some extra information about the foreground ships to RAM

    – draw the ships in the foreground a *second time* over the top?

    This would obviously have its own trade-offs, but you sounded quite worried about building these offscreen renders.

    And even if it’s completely impractical, I still had fun thinking about how I’d approach the problem!

  4. cliffski says:

    Ive got it working now :D
    But actually, your solution assumes just background and foreground, there could be ship / smoke / ship / smoke / ship /smoke, 200 times over (in theory). You need a solution that works in every theoretical combination :D

  5. Long says:

    All this reminded me of the days when I waited a few DAYS for POV Ray to render a fairly simple scene of a moon over a fractal mountain range.

    I, for once, am glad of all this progress. Even though I still think games should not be too realistic. There is something to be said about using your imagination, too.

    Then again, a realistic space battle would probably be very boring in a game due to scale, relativistic effects, and the fact that you wouldn’t see any beams anyway.

    :)

  6. Robert says:

    Sounds like a lot of work and then may be slower performance. Why not spend your time switching to a true 3D engine instead? Like Unity. You’d gain so much benefit from the switch and despite being 3D behind the wcenes, could be a top down 2D look.

    3D engines are gonna have to drag you in, kicking and screaming I think :)

  7. ac says:

    Things like Unity are just temporary. I believe in future as games and game engines become platforms for paid mods, the first one to dominate this field obviously won’t be built on Unity as it wasn’t designed for that.

    Something like this could be the future of gaming (or modding) “Bret Victor – Inventing on Principle”:
    https://www.youtube.com/watch?v=PUv66718DII

    Game developers essentially become “mod publishers”, setting up environments for modders and something like what’s seen on the video is requisite for optimal modding experience. Whoever builds those capabilities first on top of a good game that’s suitable for moddable multiplayer content with revenue share, wins. Atleast that’s what I believe.

    The ideal modding platform is such that even a 10 year old kid can build something really compelling on it. The key is very quick visual iteration capability, so that you can test and iterate more ideas in less time. To avoid the “race to the bottom”, the game developers who publish these mods on their themed platforms, need to focus on finding way to promote the best content and not fall into the brick and mortar trap of “pay us and we’ll promote your crap no matter how unhealthy it is”. Any publisher who falls into that trap will likely make quick profits, buy out competitors and then its all back to square 1. To avoid this, each company should be fully self funded and have “poison pill” to prevent hostile acquisition. As this is one of my long term goals I am working on the finance part of the equation since I don’t think the current giants are interested in disruptive models where game developers and publishers are the commodity and modders are the rock stars. Should I succeed then my company would end up being the new EA with all the best modding talent working on projects on my platform with all the state of the art tools available for free for anyone, incorporated straight into the platform/game engine.