The engine supports loading of Quake 3 style .map files with custom osirion entities. While it might look like a weird choice for a file format it has been a well-considered pragmatic choice.
First of all, creating commercial grade graphics has never been my goal. Polished high-quality models demand a lot of time, skill and effort.
The same goes for 3D modelling packages like Blender or 3D Studio Max. They are capable of producing awesome results, but the learning curve is quite steep and the number of available 3D artists is rather limited.
GtkRadiant on the other hand has been my personal tool for some time now. An experienced mapper can create a LEGO-style model in a matter of hours and without having the usual technical difficulties of creating a map for a shoot'em'up.
Creating game content is usually a chicken-and-egg in a small game project. I hope to solve this by choosing a widely available and easy to master format.
The rest of this document contains information specific to creating models for The Osirion Project. Even if you can handle GtkRadiant, it is still worth a read.
All the models for the game were created with GtkRadiant 1.5, in theory any editor capable of exporting Quake 2 .map files could be used. Support for files for GtkRadiant 1.5 are included in the data distribution. Refer to the file INSTALL on where to find them and how to install them. No map compiler is necessary, the engine reads the .map files directly.
If you are using a linux-based operating system, you can also use the GtkRadiant distribution from http://ingar.satgnu.net/gtkradiant. Note that it does not include the Osirion support files by default.
This document will not explain how to use the editor. Consult google for numerous tutorials on this subject. All basic brush editing techniques for any Quake-engine based game can be used.
The main difference with other games is that you are not creating a map for a 3d-shoot'em'up but, obviously, an object that has to be loaded into a space game.
Because there is no map compile involved, and the engine is fundamentally different, some points should be take under consideration.
The engine supports brushes only. Patches will be ignored. A large number of complex brushes is supported, but I advise not to go below grid size 1. As with any engine it is still possible to create brushwork that gets messed up.
When the model is loaded, the bounding box is calculated. The model will be automaticly centered around the center of the geometry. All visible faces will be converted to triangles. At the moment the practical triangle count limit for a model is between 20,000 and 30,000 brushes. The engine is capable of handling a lot more, but think about the fact that a large station might be placed in a system filled with player ships and other objects.
The limits of map coordinates are placed on +/-16384 map units. Placing brushes outside these bounds will have unpredictable results. The map will be scaled down to make 1024 units in radiant correspond to 1 game unit. One game unit corresponds to 100m in-game. 16 units in radiant will therefor correspond to 1.5625 meters in-game.
The front of a model points along the positive X-axis, the positive Z-axis is up, the positive Y-axis is left. In GtkRadiant, the nose of the spacesip or the front of a spacestation should point to the right.
Any brush face that has the common/caulk texture will be ignored on load.
Any brush face that has the common/clip texture will be ignored on load. Clip is reserved for future use.
As with other engines, Osirion supports the use of detail brushes, but with a twist: detail brushes will only be rendered if the model is within detail range, close enough to the camera. When it is further away, only structural brushes will be rendered. The actual detail range depends on the size of the model.
This means that any object that could only been seen from close by should be made from detail brushes.
This has one improtant implication: if you show the structural brushes only (with the CTRL+D filter in Gtkradiant) there should be no obvious gaps of caulk that were previously hidden behind detail brushes.
The engine can use tga, jpg and tng images as textures and uses a simple script based materials system similar to Quake 3 Arena shader files. Materials make it possible use special textures like player and engine color, or to apply certain effects to a texture.
The file materials/shaderlist.txt contains a list of shader files that can be used by the engine. Each shader file can contain several materials.
The default shaderlist.txt looks like this:
common colors glass
On startup, the engine will read materials from the files materials/common.shader and materials/colors.shader. When loading a .map or .ase file the engine will check if a texture name matches a known material. If a match is found, the engine will use the settings found in the material script.
In radiant, the materials can be used as normal textures, like you can with Quake 3 Arena shaders. A number of default materials are already defined and can be used out of the box.
The materials in the colors/ directory can be used to draw brush faces with a specified color. The actual RGB color is defined by the material script. Examples are red, green and blue.
The default set of colors is rather limited, more colors can be added by using the common/ family of materials. The actual in-game color information for these faces will be provided by the engine.
The common/entity material represents an object's primary color. In-game the faces with this texture will be drawn with the primary color of the entity that uses the model. For example, a player's ship will have its owner's color. Similar, the material common/entity_second represents the secondary color of an entity. common/entity_third will be a mix of the primary and secondary color. Each of these materials also has a _dark variant.
There are two special material that will cause the brush faces to be ignored by the engine: as explained above, the common/caulk material can be used on hidden faces. The common/clip material is reserved for future use brush faces using this texture will be ignored as well.
TODO: write a section on shader files.
// material name
textures/common/clip
{
// image used by the map editor
qer_editorimage textures/common/clip.tga
// image transparency in the map editor
qer_trans 0.20
// polygons using this material are ignored
ignore
}
// material name
textures/common/entity_dark_bright
{
// image used by the map editor
qer_editorimage textures/common/entity_dark.tga
// use entity color
entity
// material color
color 0.5 0.5 0.5
// polygons using this material are rendered fullbright
bright
}
// material name
textures/ship/stripes
{
// use entity color
entity
// use a texture, texture name and material name don't have to be the same
texture textures/ship/stripes
}
Unlike quake, light entities are not used to add lighting information to the level but to add point lights to a model. Adding a light will render a light flare texture in the corresponding location.
The flare value indicates what texture will be used to draw the light. The flare value is translated to a texture name, bitmaps/fx/flare??. The default flare texture is flare00.
The light value is used to determine the size of the flare. The engine default is 100, resulting in rather large flares.
The default _color is white, but the color can be set through radiant's color menu (K key). If the entity option (spawnflag 2) is set, the color value will be ignored and the light will be rendered with the color of the entity it is attached to.
The strobe option (spawnflag 1) will create a blinking light. A number of options can be set to manipulate the flashing behaviour. By default a strobe light will be half a second on, half a second off.
The frequency value changes the number of flashes per second.
The offset value changes the moment the light will be on. Offset is measured in seconds.
The time value sets the fraction of time the light will be on. The default is 0.5.
Lights will only be rendered if the model is within detail range.
I also came across this usefull information: http://en.wikipedia.org/wiki/Starboard
In short, the green light should be on the right side, the red light on the left side.
The default light entity creates omnidirectional lights. To create a directional flare, use the fx_flare entity. Values for a fx_flare are the same as those for a default light, with one small diference: the size of the flare is set through the radius value. The default flare radius is 100. Rotate the entity or set the angle value to point the flare in a different direction.
Setting the entity option (spawnflag 2) will assign the entities primary colour as flare colour.
Use the engine option (spawnflag 4) to create a flare that lights up depending on engine power.
The direction of the flare can be set with the direction, pitch and roll keys. angle is an alias for direction.
Flares will only be rendered if the entity is within detail range.
Add a fx_particles entity to attach a particle system to the model. They can be used to add effects like trails and smoke. A particle system must be defined in particles.ini before it can be used.
The script value must be set to the label of the particles script.
Setting the entity option (spawnflag 2) will assign the entities primary colour as particle system colour.
Use the engine option (spawnflag 4) will assign the models engine colour as particle system colour.
The direction of the particle system can be set with the direction, pitch and roll keys. angle is an alias for direction.
Particles will only be rendered if the entity is within detail range.
Brushes can be grouped together into funcion groups. These groups can be used to create moving parts in a model.
func_door will be used to create animated doors (not implemented)
func_group an editor utility to group brushes together.
func_rotate will create a rotating set of brushes. The center of the rotation is automaticly calculated as the geometrical center of the group. The rotation axis can be set with the direction, pitch and roll keys. angle is an alias for direction.
location_cockpit, location_dock, location_turret and location_cannon are reserved but have not yet been implemented.
location_cockpit will be used to indicate where the cockpit of a vessel is located and will be used to place the camera in cockpit mode.
location_dock will be used to indicate the location of docking ports.
location_cannon will create an attachment point for a cannon. Cannons are forward shooting guns.
location_turret will create an attachment point for turrets. Turrets point upwards or downwards.