Skip to main content

Volumetric Lines

I first started programming PewPew on Linux, with portable librairies (OpenGL/SDL/libcurl). Of course, I had the iPhone/iPod touch in mind, so I designed the gameplay and the UI accordingly.
After a month or two (once I payed for the $99 for the SDK), I migrated to Xcode and the iPhone OS. I'll write a post about that later because it was not as simple as I imagined it would be.
A week ago, I migrated the code back to Linux, and this time it only took a couple of days :) The goal was to make PewPew prettier by giving the lines a glowing look (like geometry wars) by using the infinite power of my computer (compared to the iphone anyway).


Perfection.

Naturally, at first I failed :-)
My first idea was to draw the lines multiple times, with different width and different transparencies. Here's what it looked like:

Not perfection.


Okay so that was ugly, but it had to be done. The second idea was to use pixel shaders. A pixel shader is small routine executed on the graphic card, that is applied to every pixel drawn. In this case, the shader would blur the screen.
And then I remember that activating motion blur in Crysis made the game run at 10fps...

So I got a third idea, where every line drawn would actually be a streched texture. However, a problem would arises when you would look at the line along its axis: you would only see its profil. By searching a bit (actually, a lot) on the internet, I found out that this problem has been solved, and has a name: Volumetric Lines.
I won't go into the detail of the technique, there is some code here. However I will say that his implementation kicks ass, because he actually use the GPU to process the orientation of the texture (using a vertex shader). Here are some glorious screenshots:





This time, the screenshots are made under OS X, and with the iPhone's screen resolution.

Transparency is not yet working, but that should be easy to correct and I think that using mipmapping will reduce the aliasing (and thus make thinner lines possible). Also, the vertex shader has the additional effect of messing up the tab polygon. hehe.

Overall, I am pretty happy of the result. BTW, it might be possible to run this on the iPhone 3GS at a descent frame rate... To be followed?

Labels

Labels:

Comments

  1. sebhJuly 16, 2009 at 12:47 AM

    Hey! Nice work!
    Happy to see that my work is used in great project! :)
    Keep up the good work!

    ReplyDelete

Post a Comment

Popular posts from this blog

PewPew Live's look in a nutshell

Occasionally someone will asked how I obtained the PPL look. In a nutshell: Draw everything with lines, including the text and the various icons. It's a lot of work, but besides looking unique it creates a consistent appearance which is a thing that a lot of indie games struggle with. The lines are screen-space projected lines with miter joins. Draw the lines with additive rendering. This means that if a red and green line overlap, the overlap will be yellow. There are a few things not drawn with additive rendering (like the background of buttons to improve readability), but they are exceptions. Add bloom. There's lots of different bloom implementations. Nowadays I use a bloom that is similarly to the one in  blender's eevee . If you see banding, use dithering. Optional: Add even more post-processing like (very slight) chromatic aberration, lens dirt, scan lines, curved monitor, and vignette. No post-processing, just lines Bloom! Ignore the missing bloom at the top All the...
Post a Comment
Read more

A general state rollback technique for C++

I wanted to write this post for a while. It describes a C++ technique to implement rollback in the context of multiplayer games that I feel is quite interesting and useful. The tl;dr is: don't bother serializing individual objects, just rollback all the memory. Rollback-based multiplayer I've been working on a multiplayer version of PewPew, and for reasons that are outside of the scope of this post, I chose to implement multiplayer with deterministic lockstep and rollback. The basic idea behind rollback-based multiplayer is that the inputs of players are replicated to all the players. Whenever a player receives the inputs of another player, the state of the game is rolled back to the point where the input happened and fast-forwarded back to the present so that the state shown to a player takes into account the inputs of the other players. Because history is being re-computed, some events get undone. For example, it's possible a player saw themselves taking a bonus, but aft...
2 comments
Read more

Ridiculously cheap depth of field effect for lines

I'm working on PewPew's sequel, for which I've revamped the graphics. Instead of drawing lines directly using OpenGL, each individual line segment is made up of two triangles whose vertexes are computed with shaders. Getting lines in 3D space to be properly displayed on a 2D screen is not trivial. In PewPew's sequel I use the screen-space projected lines, a technique very well described in the  Drawing Lines is Hard  post. The upside of drawing the lines yourself is that you are fully in control, which allows you to implement nice things such as joints, perspective, and even simulate depth of field. https://en.wikipedia.org/wiki/Depth_of_field Usually depth of field (DoF) in video games is implemented using a post-processing step that blurs the pixels with an intensity that is a function of the depth of the pixels. When we are rendering lines, we can approximate DoF directly when rendering the lines by having the vertex shader increase the width of lines and r...
1 comment
Read more