Project::OSiRiON - Git repositories
Project::OSiRiON
News . About . Screenshots . Downloads . Forum . Wiki . Tracker . Git
summaryrefslogtreecommitdiff
blob: a2835aacb2901c20c24e34d640351d578e01a142 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
<!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 depends 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 textured models. Every brush face is drawn 
	using a single color and any real texturing information is ignored.
<p>
	The color 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>
	The fixed set of colors is rather limited, more colors can be added by 
	using the <i>common/entity_*</i> family of textures. The actual in-game
	color information for these faces will be provided by the engine.
<p>
	The special texture <i>common/entity</i> represents an object's primary color. 
	In-game the faces with this texture will be drawn in the color that the entite has
	provided as the object's primary color. For example, for player-controled ships will
	have their owner's color as primary color.
<p>
	Similar, the texture <i>common/entity_second</i> represents on object's secondary
	color. <i>common/entity_third</i> will be a mix of the primary and secondary color.
	Each of these textures also has a <i>_dark</i> variant.
<p>
	You can also use two other special textures: as explained above, 
	faces with the <i>common/caulk</i> texture will be ignored on load. 
<p>	
	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/map.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.

<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 within 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>