Ferox can finally render again

As one of my first personal projects, Ferox has suffered from a willingness to try new ideas and start over, axing perfectly fine working code in the process.  Of course, this is one of the reasons why I’ve improved my skills so much in the past, because I’ve learned what I like and don’t like. If you don’t want to read the whole thing, here’s the tl;dr http://www.youtube.com/watch?v=yUgzwq9_BpU

I’m proud to say that tonight I made a big step forward and completed enough of the Ferox and Entreri integration to render a scene from an entity system.  Not only did it work with multiple lights and shapes, the performance was around 3X faster than my previous engines.  Comparisons are a little tricky because previous tests had shadow mapping and textures, while this does not.  To make up for that, I had the new engine use ten lights instead of a single light.

I am very pleased with the results, on my slightly aging Mac Book Pro, I was able to render 10,000 entities in three different shapes with 10 attenuated lights at 37 fps. Each frame rendered about 2.8 million polygons for a grand throughput of 103 million triangles per frame.  From some simpler benchmarks, I estimate my laptops optimal throughput at a bit over 200 million triangles per frame.  Obviously a lot of this depends on pixel coverage, effects, and batch sizes, but I feel pretty good about getting 50% of the way there.

I remember when I first started working on Ferox that I was happy to get 12 fps, and sometimes I remember similar test scenes running down into the 5 fps range. There are three major reasons why my new engine is performing so well:

  1. Entreri’s cache locality guarantees make much of the scene processing take very little time compared with previous engines. Generally the scene pre-processing in the test scene of 10,000 objects is done in 10ms or less, whereas before it might have been 15 to 20.
  2. The renderer computes ahead of time all of the different lighting configurations needed, even for fixed function rendering, and batches up the light groups. Previously, each rendered entity had to compute how lighting changed and configure itself entirely. There was no light batching at all.
  3. Ferox has a cleaner threading model now, so the OpenGL rendering occurs in one thread in parallel with the scene preparation for the next frame.  For the test case I’ve been talking about, this netted about 10 extra fps.

I’ve still got a lot of work to do, but it’s a nice feeling to be able to show something on screen again.