Parallax and defomable terrain

I am working on some serious stuff, including a lot of parallax layers, and a deformable terrain. Screenies below.

Right now, I apply brute force fragment shaders, rendering a total of 8 textures in one pass. This sound efficient, but it really isn’t. While it runs 60fps on ipad2 and 3 ( retina ), and somewhat slower on ipad1, the problem is, that I render way to many transparent pixels. Even if parallax 2 only is 5% visible at the bottom, I render a nearly entire blank screen of parallax 2, because I am forced to render only one piece of geometry. While mix( ) is insanely fast, with 8 full screens of textures, things will eventually start to slow down.

And then it struck me.

The parallax should be split into 5 quads, each being a band of overlapping parallax layers. First quad will be pure skybox. Second quad will be skybox and far most parallax. Third quad will be etc etc etc etc. If you adjust you parallax textures to include fewest possible transparent pixels, this will render it all, with an absolute minimum of pixel operation.

You of course have to write 5 shaders, in stead of one shader, but that is a small price to pay.

All the images below, is rendered in a single quad.

Enjoy the landscapes.

The earth crust is made with inspiration from a demo I watched, and is fully deformable, meaning that if I dig a hole into the ground, the grass will disappear. Not by magic, but by the insane power of the shader.
I did some math, and calculated that I could save 35-80% of all texture look-ups ( currently the shader does 25.2M look-ups pr frame )
The final picture shows how I plan to implement it. The picture is a bit fuzzy, but so is my ideas on how to implement this also.

5 responses to “Parallax and defomable terrain

  • slembcke

    Hey, that’s awesome. Way prettier than my hacked together programmer graphics. :D

  • pfg2009

    Neat! I’m diving into something similar so it’s good to hear about your success in the area. Thanks for posting!

  • Sergey Kravchenko

    I just found your blog, its pretty cool, thanks for the postings!
    So, please correct me if I wrong, you’re minimising the redraw by drawing only maximal possible visible rectangle , right?
    What if use Z buffer test, and draw the terrain first? and after 1st layer (taking most of the screen’s real eatate) is drawn, you draw the second bg (and z-test prevents you from overdraw the pixels already claimed by 1st frontmost layer)
    What do you think of this approach

    • Birkemose

      Hi Sergey
      Sorry I did not see your post earlier.
      Main problem with 2D is, that you draw blended pixels, and thus have to draw what is behind first. Otherwise it just looks weird.
      Your approach is used in 3D of course, where mpst things you draw are opaque.

      I ended up, breaking the front most layer into quads, and disable blending for those of those which were 100% opaque, not render those which were 100% transparent, and only applying the expensive shaders to those which has transparent content.
      Good thing about rendering opaque pixels, are, that the cost of rendering transparent pixels underneath, drops significantly. Try rendering a black opaque quad, covering your entire game, and watch what framerate does.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

<span>%d</span> bloggers like this: