Wednesday 5 March 2014

Strange Frame Rate Fruit

Work

A rather mixed bag today. Once I had dispensed with the first five hours of the day on menial stuff and nonsense, I began the adventure of performance seeking in earnest. My plan was to re-introduce the quad system, but tie it to the individual static objects in the scene, so in addition to their LOD transitions they would have quad's at the furthest range. This was accomplished relatively quickly, but the next part of my evening would be filled with non-quad related musings.

It turns out that after adding the quad system, and as a quick test replacing ALL static objects with their quad equivalents, and ensuring that the quad textures or quad vertex buffers where not being locked, I only gained 4 fps for my trouble on a GeForce 9600 GT using the 'run to the river' level with everything set to Low. That's right, I went from 141 fps with real objects to 145 fps with quad replacers. You could have knocked me down with a feather. My knight in shining quad armor turned out to be a total faker. It was remarkable in that the 141 fps was pushing 134K polygons with 225 draw calls and the 145 fps was pushing 86K polygons and 132 draw calls. I achieved my goal of halving the draw calls but I did not get my reward of more frame rates. I should also mention that I switched off my built-in occlusion system for this test, initially as a way to un-bias my results but in fact when I did remove my performance helping system I went from 66 fps to 141 fps. Sometimes the universe likes to have a huge belly laugh at my expense!

Getting 163 fps on a GeForce 9600 GT - It IS possible but at too High A Price

Undeterred, I decided to abandon logic and look for something that would give me some more performance. Having done everything right by adding occlusion, quad rendering and other object thinning methods and not get a prize in performance, I decided to spend an hour running a battery of daft tests until I saw a big jump in performance.  I finally found one such spike, which happened when I moved the camera to look at the sky but not so far that the terrain and ground objects became invisible. I noticed that the more terrain was rendered, the more frame rate drain occurred.  I then replaced the terrain shader with a single color draw and the frame rate went through the roof.  It seems the single biggest performance killer is my terrain shader, which has the job of painting most of the 100K-200K polygons in a typical scene.

The good news is that I have recruited someone (Dave The Ravey) to help me reduce how much terrain is rendered in the first instance, but now I know the shader is a crucial bottleneck to fast gaming, this is the focus of my performance hunt on Thursday. Unfortunately, I have to take a phone call during daylight hours so have to cut short my development tonight and resume when I wake.  My initial thoughts are that rendering every terrain pixel with my intense terrain shader is just daft, and that if I can render a cascade of terrain textures on the GPU and then feed those textures to the terrain rendering, it will all but eliminate the drain which can take a frame rate from over 300 fps down to 110 fps.  Naturally, whatever I use to build the dynamic terrain texture will cost something, and balance the scale a little, but having experienced almost no drop in performance when rendering LOTS of quad textures, I think I can get away with it.  There are some big holes in this approach however, such as no dynamic shadow information getting to the terrain shader, but I think I can re-channel the shadow to the dynamic terrain texture and get the shadows back.  Using this new technique, I will also be able to introduce 'texture splatting' as a freebie feature, allowing more than four textures per terrain :)  I won't be doing anything on this feature until performance is solved, but it will be a great bonus if this new technique works as I expect it might.

I think you can start to appreciate why some game developers decide to buy a middle-ware engine for $250,000 and skip the whole process of figuring out the best way to do everything :)  I certainly can, but I won't be beaten!!

14 comments:

  1. For the hundredth time, excellent work! As you can see, there was no reason at all that we should have been getting the low framerates of the those first couple of beta releases :)

    ReplyDelete
  2. A hopeful pursuit. I look forward to seeing how this develops over the next few days. If it goes splendidly, performance might just be worth taking a back seat and finally, you can start working on the bits that will let us create detailed, complex games.

    ReplyDelete
  3. T-Ed.. why is it gone from TCG

    ReplyDelete
    Replies
    1. Because it was outdated and no longer updated or supported.

      Delete
  4. Lee, and what about removing water from whole level and rather making water blocks instead. Wouldn't this be great jump in fps?

    ReplyDelete
    Replies
    1. Maybe, but I seriously doubt it. For a start, the performance drop from water is not strongly related to the amount of water there is; i.e., the size of the water plane. Secondly, having blocks of water rather than a single plane would encourage people to use more than one block, and THAT could cause significant performance drops.

      However I do think a single water plane is outdated; most games use custom meshes shaped to the body of the water, with water shader applied.

      Delete
    2. Agree but i doubt that it would animate ppl to place to many water blocks. At the end water is only for decoration and in some cases water planes give the immersion of a bigger level or island but without water blocks its just pointless.
      Thats like telling ppl hey no you cant have a pool on a island..
      Anyways i hope Lee adds something like a water block.

      Delete
    3. When I said the water plane was outdated, it's outdated to have JUST the water plane. They're always useful in their own right, but should be supplemented with other forms of water.

      I actually hope Lee doesn't add a water block. What would be far more useful would be whatever is necessary to allow us to apply a water shader to any geometry (obviously it wouldn't automatically flow, that's a different shader altogether) so we can create water in whatever shape we want.

      Delete
  5. Sounds ok but you would need a few types of water. Plane for oceans and the none too bothered about water people or games.
    Box so can swim or immerse at different levels
    And apply water shader. Maybe as a terrain splat technique.

    That would cover water I reckon.
    anyway I want the veg and models and the super new beta first. Hopefully in a week we will have a copy

    ReplyDelete
    Replies
    1. Yeah. Anyway, my comments on water are mostly speculation for future versions of Reloaded.... I don't expect anything on the waterfront (pun intended) for some time.

      Delete
  6. Fear not, my focus on performance right now is almost zealous!

    ReplyDelete
  7. good choice of word. Glad to hear that. The beta calls for us like a siren on the rocks we are the vessels and you are the turbulent sea sending us to our doom of no social life. :)

    ReplyDelete