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