From 4b8a6390b1dd6f0a10c2824c34a953832864d5fc Mon Sep 17 00:00:00 2001 From: Stijn Buys Date: Wed, 16 Jul 2008 11:08:10 +0000 Subject: documentation updates --- doc/models.html | 243 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 243 insertions(+) create mode 100644 doc/models.html (limited to 'doc/models.html') diff --git a/doc/models.html b/doc/models.html new file mode 100644 index 0000000..d339ee3 --- /dev/null +++ b/doc/models.html @@ -0,0 +1,243 @@ + + + + + + The Osirion Project - Creating models + + +

+ The Osirion Project - Creating models +

+

+ 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 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. +

+ Content +

+

+

+ +

+ 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.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. 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 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 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. In GtkRadiant, the nose of + the spacesip or the front of a spacestation should point to the right. + +

+ 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 within detail range, close enough to the camera. When it is further away, + only structural brushes will be rendered. The actual detail range 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. + +

+ Textures +

+

+ The engine does not support model 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 common/clip texture 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 and can be used to create light-emiting objects + or windows. 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 is translated to a texture name, bitmaps/fx/flare??. + The default flare textures 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 the time the light will be on. + The default is 0.5. +

+ Lights will only be rendered if the model is withint 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. + +

+ 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_flare entities 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. +

+ A target_engine entity will only be rendered if the model is within detail range. + +

+ Other entities +

+

+ target_cockpit, target_turret and target_cannon are reserved but have not yet been implemented. +

+ target_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. +

+ target_cannon will create an attachment point for a cannon. Cannons are forward + shooting guns. +

+ target_turret will create an attachment point for turrets. Turrets point upwards or downwards. + + + -- cgit v1.2.3