«

»

Tech Diary #1

sahara_engine_rocks

It can often be hard to decide what exactly to write in your blog. All indie-devs blog their own way. At first we strived to feature only the most significant updates in the blog entries, never without screenshots or trailers which could be regarded as being almost at the final quality stage.

Having still once realized that we have lots of “draft” thoughts, we made up our mind to reveal them. We have reconsidered our attitudes to blogging and now believe that sharing these ideas to get your feedback is not only possible but vital.

I will devote this update to the recent technical changes.

First of all I ought to mention the change in renderer’s architecture – that is the most significant decision made by me in the technical aspect of the game.

Once when playing a game based on Chrome Engine (Call of Juares, Sniper Ghost Warrior) and rethinking the engine features, the features we use in our engine, and 3D in general – those are typical activities for me when I play any game :-) – I managed to figure out what was wrong about our Sahara Engine and how to correct it.

That was a beginning of the new architecture in my head. The idea was developing with time and  finally became so powerful that we had to refuse from the old-engine-version-based demo release.

Sahara Engine was meant to evolve…

 

1. Materials system is heart of graphics

The new approach contrasts with the old system where the number of materials was restricted.  Earlier, to add new materials I had to integrate them to the engine, wasting time for debugging and creating the build anew.  In the new materials system it is possible to create any material as a config file, which doesn’t require recompilation or additional work with the code. An object can have several multipass materials at the same time, the materials can be dynamically assigned to the object and removed from it. What is more, the support of refractions, reflections and cube maps has been improved.  It  has enabled us to freely experiment with materials and observe the most optimized work of the engine.

 

sahara_engine_god_rays

 

2. The LODs system is a key to optimisation

In the old architecture it could be no more than three LODs for the static geometry: the basic geometry + 2 LODs. The distance to enable LOD was the same for every object. The new system allows to have unlimited number of LODs for each object and set the distance to enable LOD individually. Each LOD can have its own material.

 

sahara_engine_lods_fog

 

3. Instancing – to render more and pay less

The old system allowed instancing only in the vegetation system. Now instancing can be applied to any geometry with the exception of skinning which is done later. This means that when the objects are ready for rendering they are sorted out where the similar objects are gathered together (taking to account  the LODs) and sent to rendering with a single draw call.  Thus, the scene can have a great number of objects avoiding the risk of resembling TBS.

 

sahara_engine_bloom_god_rays

 

The changes above allowed to increase the rendering efficiency by about 40%.  And that was not all! We are presently working on the further optimisation of other algorithms which will enable the game to have the sufficient  FPS and work even on relatively old systems.

I am to continue speaking about Sahara Engine changes in the following updates, so stay tuned!

And it will be my pleasure to answer your questions.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

In an effort to prevent automatic filling, you should perform a task displayed below.