Home | News | How the Library is Built – Part 1

Here’s the first part of a mini-series on how the OpenSceneryX library is built, covering the whole process from the initial contribution of an object all the way through to the moment it appears on the end user’s machine.

This post will cover the first part of this process – The initial contribution of the object.

Stage 1: Arrival

The object (or much more often, collection of objects) arrives as a zip file.  The contents of this zip can vary hugely – some contributors send in stuff that is almost release-ready, i.e. every object in a separate folder, every object with a screen-shot, even sometimes with an info file. Sometimes it’s just a collection of objects and textures in a single folder.  Whatever it contains, every object is examined, doing the next stages. Obviously the time taken by the whole process varies depending on how much work the contributor has already done.

Stage 2: Quality Assurance

All objects are examined with a quality-control eye.  This involves assessing the overall ‘look’ of the object, making sure it’s good enough quality to be added. The complexity of the model is also assessed (number of polygons) and the size of the texture.  Obviously the size and nature of the object is taken into account in this assessment – I won’t accept a car with 40000 polys but equally a static aircraft that only has 10 isn’t going to be very pleasing.  Texture efficiency is more strictly monitored nowadays, unnecessarily huge textures will fail QA (although if this is the only problem with the object, I’ll do the texture re-scaling at stage 3).  If any object fails at this stage, I’ll feed back to the contributor with some positive suggestions on improving it.

Stage 3: Copyright

If the contributor hasn’t supplied copyright information about the contribution(s), the next thing that happens is they get an email back asking for this information.  Nothing further will happen until copyright information has been received for both the object model and the texture – the author of every contribution must be supplied or it gets deleted.  If the contributor hasn’t already obtained permission from the author(s) then every one of them gets an email asking whether they will allow their work to be included in the library.  Usually I ask for blanket permission for all of their work, to save time later if someone else contributes something from the same author.  (Incidentally, all these communications are archived).

Stage 4: Corrections – Origin, Alignment, Scale, Texture

If the object has a definable ‘front’ (e.g. aircraft, buildings) then this is aligned North.  In the case of objects that have a ‘nose’ (e.g. vehicles) then this is aligned to the origin (0, 0) otherwise the origin is typically set to be the centre of the object. The object scale is checked as it’s amazing how many objects need to be dramatically scaled to the correct size. All the geometry work is done in Blender, and care is taken to alter all levels of detail (LOD) if provided.  Finally the texture is scaled if necessary, using either The Gimp or GraphicConverter.

Typically the screen-shot will be taken at this stage if one hasn’t been provided.

Stage 5: Primary Categorisation

This involves deciding on the main place that the object is going to appear in the library and simply creating a folder for it on disk. This is getting easier and easier to decide as the library has taken shape.

Stage 6: The info.txt File

The info.txt file contains all the information about the object – The title, copyright owners, whether it is animated, as well as any secondary categories that it should be published to.  This file is read automatically by the script that packages up the library, so it uses a standard layout that can be easily read by both humans and machines.

Stage 7: Commit to the Version Control System

At this stage all the new files are committed to the version control system. We used to use Subversion which was kindly hosted by Indi, but nowadays it’s all on GitHub. Without using a system like this it would be impossible to manage the large number of files in the library.

In the next episode I’ll talk about what happens next – the building of the library.