Project::OSiRiON - Git repositories
Project::OSiRiON
News . About . Screenshots . Downloads . Forum . Wiki . Tracker . Git
summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
Diffstat (limited to 'doc/models.html')
-rw-r--r--doc/models.html243
1 files changed, 243 insertions, 0 deletions
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 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
+<html lang="en">
+<head>
+ <meta HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=UTF-8">
+ <link rel="stylesheet" type="text/css" href="style.css">
+ <TITLE>The Osirion Project - Creating models</TITLE>
+</head>
+<body>
+<H1>
+ The Osirion Project - Creating models
+</H1>
+<p>
+ 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.
+<p>
+ First of all, creating commercial grade graphics has never been
+ my goal. Polished high-quality models demand a lot of time,
+ skill and effort.
+<p>
+ 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.
+<p>
+ 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.
+<p>
+ 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.
+<p>
+ 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.
+<h2>
+ Content
+</h2>
+<p>
+<ul>
+ <li><a href="#gtkradiant">Creating models with GtkRadiant</a>
+ <li><a href="#brushes_and_sizes">Brushes and sizes</a>
+ <li><a href="#caulk">Caulk</a>
+ <li><a href="#clip">Clip</a>
+ <li><a href="#detail_brushes">Detail brushes</a>
+ <li><a href="#textures">Textures</a>
+ <li><a href="#surface_flags">Surface flags</a>
+ <li><a href="#lights">Lights</a>
+ <li><a href="#flares">Flares</a>
+ <li><a href="#engines">Engines</a>
+ <li><a href="#other_entities">Other entities</a>
+</ul>
+
+<h2 id="gtkradiant">
+ Creating models with GtkRadiant
+</h2>
+<p>
+ 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.
+<p>
+ If you are using a linux-based operating system, you can also use
+ the GtkRadiant distribution from <a href="http://ingar.satgnu.net/gtkradiant">http://ingar.satgnu.net/gtkradiant</a>.
+ Note that it does not include the Osirion support files by default.
+<p>
+ 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.
+<p>
+ 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.
+<p>
+ Because there is no map compile involved, and the engine is fundamentally
+ different, some points should be take under consideration.
+
+<h2 id="brushes_and_sizes">
+ Brushes and sizes
+</h2>
+<p>
+ 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.
+<p>
+ 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.
+<p>
+ 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.
+<p>
+ 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.
+
+<h2 id="caulk">
+ Caulk
+</h2>
+<p>
+ Any brush face that has the <i>common/caulk</i> texture will be ignored on load.
+
+<h2 id="clip">
+ Clip
+</h2>
+<p>
+ Any brush face that has the <i>common/clip</i> texture will be ignored on load.
+ Clip is reserved for future use.
+
+<h2 id="detail_brushes">
+ Detail brushes
+</h2>
+<p>
+ 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.
+<p>
+ This means that any object that could only been seen from close by
+ should be made from detail brushes.
+<p>
+ 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.
+
+<h2 id="textures">
+ Textures
+</h2>
+<p>
+ The engine does not support model textures. Any real texturing information
+ is ignored.
+<p>
+ The textures in the directory <i>/textures/colors</i> 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.
+<p>
+ You can also use two special textures from the <i>/textures/common</i>
+ directory: as explained above, faces with the <i>common/caulk</i> texture
+ will be ignored on load. The <i>common/clip</i> texture is reserved for
+ future use. At the moment they will be ignored as well.
+<p>
+ At the time of writing, texture names are hardcoded
+ in <i>src/model/mapfile.cc</i>.
+
+<h2 id="surface_flags">
+ Surface flags
+</h2>
+<p>
+ 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 <i>common/entity</i> shader.
+
+<h2 id="lights">
+ Lights
+</h2>
+<p>
+ Unlike quake, <i>light</i> 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.
+<p>
+ The flare value indicates what texture will be used to draw the light.
+ The flare value is translated to a texture name, <i>bitmaps/fx/flare??</i>.
+ The default flare textures is <i>flare00</i>.
+<p>
+ The light value is used to determine the size of the flare. The engine
+ default is 100, resulting in rather large flares.
+<p>
+ 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.
+<p>
+ 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.
+<p>
+ The frequency value changes the number of flashes per second.
+<p>
+ The offset value changes the moment the light will be on. Offset is
+ measured in seconds.
+<p>
+ The time value sets the fraction of the time the light will be on.
+ The default is 0.5.
+<p>
+ Lights will only be rendered if the model is withint detail range.
+<p>
+ I also came across this usefull information:<br>
+ <a href="http://en.wikipedia.org/wiki/Starboard">http://en.wikipedia.org/wiki/Starboard</a>
+<p>
+ In short, the green light should be on the right side, the red light
+ on the left side.
+
+<h2 id="flares">
+ Flares
+</h2>
+<p>
+ The default light entity creates omnidirectional lights. To create
+ a directional flare, use the <i>target_flare</i> entity. Values for a
+ <i>target_flare</i> 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.
+<p>
+ <i>target_flare</i> entities can only be rotated in the XY-plane.
+
+<h2 id="engines">
+ Engines
+</h2>
+<p>
+ Add a <i>target_engine</i> entity to add an engine exhaust to a ship model.
+ An engine exhaust always points to the rear (negative X-axis).
+<p>
+ 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.
+<p>
+ A <i>target_engine</i> entity will only be rendered if the model is within detail range.
+
+<h2 id="other_entities">
+ Other entities
+</h2>
+<p>
+ <i>target_cockpit</i>, <i>target_turret</i> and <i>target_cannon</i> are reserved but have not yet been implemented.
+<p>
+ <i>target_cockpit</i> will be used to indicate where the cockpit of a vessel is located
+ and will be used to place the camera in cockpit mode.
+<p>
+ <i>target_cannon</i> will create an attachment point for a cannon. Cannons are forward
+ shooting guns.
+<p>
+ <i>target_turret</i> will create an attachment point for turrets. Turrets point upwards or downwards.
+
+</body>
+</html>