4.9.2 Components of a World

This section describes the objects used to build a world. This is useful to understand the format of the Crystal Space map file (see section Format of Map File (XML)). To understand this you should know the basics of the Portal Engine. This section describes the components of the world independent from the file format, so it is also useful if you want to build a world from within your program.

The world is built up from the following objects:

• Sectors (iSector). For details, see the portal engine discussion (see section Portal Engine). Basically sectors define an area that can contain several geometrical objects. As opposed to earlier versions of Crystal Space, a sector does not itself represent geometry. Instead all geometry in a sector is made from Mesh Objects. Theoretically a sector is infinite although in practice it is usually logically bounded by sector walls or a sky object.
• Mesh Objects (iMeshWrapper, iMeshObject). See the mesh object section for more specific information about them (see section Mesh Object Plug-In System). Mesh objects represent geometry in some sector. Everything you can see (walls, actors, particle systems, ...) is represented by some kind of mesh object. This is a very important concept in the Crystal Space engine. Mesh objects can also be hierarchical. A mesh object can have several children which in turn can also have children and so on. The children of a mesh object are positioned relative to the parent. So when you move the parent the children will automatically move with the parent.
• Mesh Object Factories (iMeshFactoryWrapper, iMeshObjectFactory). Mesh object factories are objects that can be used to create mesh objects that inherit characteristics from their mesh factory. Basically a mesh object factory is like a blue-print for creating a mesh object. Mesh factories can also be hierarchical like mesh objects.
• Portals (iPortal, iPortalContainer). Again see the portal discussion (see section Portal Engine) but the idea is that sectors are normally totally independent areas unless you connect them through portals.
• Light Sources (iLight). There are different ways how light is applied to objects to increase performance. See section Lighting.
• Collection Objects (iCollection). These are simply groups of other objects. Do not confuse them with hierarchical objects.
• Regions (iRegion). A region is also a collection of objects but the purpose is different (as opposed to collections). A region can contain textures, materials, mesh objects, mesh factories, lights, collections, sectors, sequences, triggers, shared variables, .... Regions are useful when you want to load/unload big parts of a world dynamically. This can be used in cases where the world is too big to fit in memory and you want to use dynamic loading.
• Key/value Pairs (iKeyValuePair). A key/value pair is a {key,value} tuple describing some game specific concept. Key/value tuples are represented by a pair of strings. If you have built levels for Quake before, you are probably familiar with this concept from Quake's Entities. Almost all objects in the Crystal Space engine support these key/value pairs so you can attach this kind of information to anything. Crystal Space itself will not use this information but your game can query it and perform the appropriate actions. In theory it is up to your program as to how these key-value tuples are interpreted. However, Crystal Space has set some standards to make life easier for level designers and also to make levels as portable as possible between different Crystal Space games. Note that key value pairs actually allow multiple named values for a single key. See Keylist Standards.
• Nodes (iMapNode). A node represents a point in space. The engine itself will not use nodes but a game can use them to represent game specific data.

The Thing Mesh Object is probably the most important mesh object as it can be used to define how the basic structure of your world looks like. Here is a list of concepts that are related to Things:

• Polygons. Things are made from polygons. To define such an object you enumerate all polygons that make up the geometry of such thing.
• Texture Planes. Polygons in a thing are texture mapped using a transformation from object to texture space. A texture plane describes this transformation. You can directly specify texture planes but more usually you use uv mapping coordinates to do this.

Keylist Standards

This section describes some guidelines for key/value tuples.

The most important key is the `classname' key. It tells the program the type of an object. All the following guidelines are set for special object classes. If you don't agree with them, you should use different classnames.

The following classnames are standardized:

@@@FIXME: Write this.

This document was generated using texi2html 1.76.