The information in this article is from the Blender website http://www.blender.org/. The original information can be found under the development tab in articles “Blender file Reading” and “Notes on SDNA”. Blender is a 3D Editor/Content Creation Suite licensed under the GNU General Public License.

The source can be consulted for final authority and is available from the svn site at https://svn.blender.org/svnroot/bf-blender/trunk/blender (40MB+). The subdirectory of interest is …/source/blender/makesdna, and …source/blender/blenloader. These directories contain the C code that reads and writes blender formatted files (SDNA) and the structures used to represent Blender objects. The sub-directory …/source/blender/makesdna contains a source for a program that will produce a generated source file to be incorporated into Blender. This source represents the current SDNA version. The sub-directory …/source/blender/blenloader contains the read routines for a SDNA file.

In file …/blender/blenloader/intern/ readfile.c and writefile.c have comments outlining the read/write process. SDNA file format has two advantages for the development of a railroad simulator game. Blender saves the current user editor’s version of SDNA in newly created 3D files. That is, not just a version label where the simulation game could tell the user that he is using the wrong version of a 3rd party tool, but the file layout itself, where the simulator can make adjustments and load the file without burdening the user with requirements outside of railroad simulator’s control. The second advantage is the simulator can fix MSTS2Blender at a particular version of SDNA. The version need only be updated when Blender has a newly added features that the OSRail railroad simulator would like to incorporate into its simulation and graphics.

A key structure used in SDNA is BHead (…/makesdna /DNA_sdna.h) contains an index that ids the structure type, and the blocks original location in memory. The header also contains information on big/little ended and an indicator for 4 or 8 byte pointers. When the file is read the file pointers must be adjusted for the difference between the original block location and the new memory location and any links to this block must also be modified.

The file itself starts as a series of pointers, object counts and section sizes pointing to the blocks themselves, descriptions and names of each type and structures used in the file. The file and its objects must be aligned on a 4 or 8 byte boundary with pointers taking up 4 or 8 bytes.

The MSTS2Blender utility should read the file into memory as is, and adjust and convert the pointers for its new memory location, little ended, and pointer size. Blender maintains and edits 3D scenes and the Ogre 3D window must display individual meshes or an entire scene. The initial extension to MSTS2Blender should read a dummy “.blender” file and display in tabs in a similar manner to the current reader for MSTS (Microsoft Train Simulator) files.