moved documentation

1 files changed, 0 insertions, 180 deletions

diff --git a/MODELS b/MODELS
deleted file mode 100644
index 4ecd03a..0000000
--- a/MODELS
+++ /dev/null
@@ -1,180 +0,0 @@
- 
-The Osirion Project - MODELS
-
-Creating 3D models for The Osirion Project
-
-Introduction
-
-	The engine supports loading of Quake 2 .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 availble 3D artists is rather limited.
-
-	GtkRadiant on the other hand has been my personal tool for some time
-	now. For an experienced mapper, creating a LEGO-style model is only
-	a matter of hours and without the usual technical difficulties of 
-	creating a map for shoot'em'up.
-
-	Creating game content is usually a chicken-and-egg in a small game
-	project. I hope to solve it 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.
-
-Creating models with GtkRadiant
-
-	All the models for the game were created with GtkRadiant 1.5.0,
-	in theory any editor capable of exporting Quake 2 .map files could
-	be used. Support for files for GtkRadiant 1.5.0 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.soliter.org.
-	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. Any basic brush-creating 
-	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.
-
-Brushes and sizes
-
-	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 center 
-	of the model will be placed at the center of the bounding box.
-
-	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 map units correspond to 1 game unit.
-
-	The front of a model points along the positive X-axis, the positive
-	Z-axis is up, the positive Y-axis is left.
-
-Caulk
-
-	Any brush face that has the common/caulk texture will be ignored on load.
-
-Clip
-	Any brush face that has the common/clip texture will be ignored on load.
-	Clip is reserved for future use.
-
-Detail brushes
-
-	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 close enough to the camera. When it is further away, only structural
-	brushes will be rendered.
-
-	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.
-
-Textures
-	
-	The engine supports no textures. Any real texturing information 
-	is ignored.
-
-	The textures in the directory /textures/colors can be used by 
-	the editor. The engine translates these textures into RGB colors 
-	when the model is loaded. Unknown textures will be colored hot pink.
-
-	You can also use two special textures from the /textures/common
-	directory: as explained above, faces with the common/caulk texture
-	will be ignored on load. The use of common/clip is reserved for
-	future use. At the moment they will be ignored as well.
-
-	At the time of writing, texture names are hardcoded 
-	in src/model/mapfile.cc
-
-Surface flags
-
-	The only supported surface flag is light. This will render
-	the brush face fullbright. The light flag does not work
-	in conjunction with the common/entity shader.
-	
-Lights
-
-	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 maps to bitmaps/fx/flare??.tga. The default flare is 0.
-
-	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 the time the light will be on. 
-	The default is 0.5.
-
-	Lights will only be rendered if the model is close enough.
-
-	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.
-
-Flares
-
-	The default light entity creates omnidirectional lights. To create
-	a directional flare, use the target_flare entity. Values for a 
-	target_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.
-
-	target_flares can only be rotated in the XY-plane.
-
-Engines
-
-	Add a target_engine entity to add an engine exhaust to a ship model.
-	An engine exhaust always points to the rear (negative X-axis).
-
-	An engine is rendered as a pulsating light flare. The size of the flare
-	can be set through the radius value. The default engine radius is 100.
-
-	Engines	will only be rendered if the model is close enough.
-
-Other entities
-
-	target_cockpit, target_turret and target_cannon are not yet implemented.
-