Technical background
StoryInterpreter --> SectorEngine --> B3D_Engine --> S3D_Engine --> Direct 3D
Brief description of the B3D engine underlying X and all sequels.
Importing models
ZBuffer
Material management
Data types
Importing models:
Models are imported from two possible fileformats. Body files (*.b3d) or compressed body
files.
Uncompressed body files are ascii files containing body arrays where each body describes
an individual level od detail of the 3d modell.
Following this scheme:
The B3D engine comes with a tool capable of converting .3DS files into .B3D files. Certain tags in the 3DS fileformat are used to segment a body array into bodies and a body into parts (based on the objects hierachy within 3D Studio MAX). Special keywords are also transfered into part flags. This allows the designer to put special effects on bodies, such as engine glows, or smoke, or define special parts such as laser bays, docking bays, light sources etc.
There are a couple of design restrictions we follow. Almost all these restrictions only exist for performance issues because of hardware acceleration limitations. One such example is the number of vertices one part can have.
One important design decision related to the engine is to use ZBuffering or not. Using
a ZBuffer makes designing models a whole lot easier, because the 3D designer does not have
to think about visibility problems that otherwise are solved with seperation into parts
(parts are depth sorted, but NOT polygons inside parts). The downside to this is slightly
slower performace on some accelerators, increased memory usage and most importantly
problems with transparent objects such as engine glows or windows. The engine supports
both techniques, X-BTF did NOT use ZBuffering.
Another important decision is how the engine is going to manage materials internally. There are two different approaches possible. Allocating materials dynamically when importing models or defining a static set of materials and remapping materials to those statically defined. The advantage of the second approach is that the number of different materials is fixed, and there is no need to pre-load bodies to find out about the material requirements. Approach number one requires that all bodies are pre-loaded in a first step, then the material cache is locked and if further models are imported their materials are only remapped to the already existing materials. X uses a set of about 250 fixed materials. This way materials and textures can be hand tuned for maximum performance.
Communication with the B3D engine uses the following data types:
BodyArray3D | One 3D Object typically imported from 3DSMax including its LODs |
Body3D | A single LOD |
Material | Imported with 3D models / mapped to static materials See material management |
Scene3D | A scene is similar to a what is called a viewport in Direct 3D. It describes the
output device and window and has its own set range of coordinates. In XBTF for example a
normal game scene has up to four scenes all displayed on top of one another:
Every scene has its own set of lightsources! |
Inst3D | One instance of a body used in the game or for a scene playback. This is the core structure containing object specific information like its position. |
J3D_Cut | A structure used to play back entire animations. Cuts can be imported from 3DSMax
similar to bodies. A cut is defined by multiple paths. Cuts can be used to play back entire animations (like the intro and credits of X-BTF) or parts of an otherwise interactive environment (e.g: In XBTF every factory has its own cut animating multiple body arrays. Also some ships are made up from several body arrays to allow animations within a ship. Another example are menu animations which are defined in imported cuts as well). |
J3D_Path | A path describes the motion of one inst3d inside a cut |
J3D_Take | A take is one instance of a cut. |