diff options
Diffstat (limited to 'doc/MODELS')
| -rw-r--r-- | doc/MODELS | 180 |
1 files changed, 180 insertions, 0 deletions
diff --git a/doc/MODELS b/doc/MODELS new file mode 100644 index 0000000..4ecd03a --- /dev/null +++ b/doc/MODELS @@ -0,0 +1,180 @@ + +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. + |