From 821e88a6d147a13e0e4eca1b0c1c770e3bee3a90 Mon Sep 17 00:00:00 2001 From: Stijn Buys Date: Mon, 14 Jul 2008 09:41:27 +0000 Subject: moved documentation --- MODELS | 180 ----------------------------------------------------------------- 1 file changed, 180 deletions(-) delete mode 100644 MODELS (limited to 'MODELS') 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. - -- cgit v1.2.3