Project::OSiRiON - Git repositories
Project::OSiRiON
News . About . Screenshots . Downloads . Forum . Wiki . Tracker . Git
summaryrefslogtreecommitdiff
path: root/MODELS
diff options
context:
space:
mode:
Diffstat (limited to 'MODELS')
-rw-r--r--MODELS180
1 files changed, 0 insertions, 180 deletions
diff --git a/MODELS b/MODELS
deleted file mode 100644
index 4ecd03a..0000000
--- a/MODELS
+++ /dev/null
@@ -1,180 +0,0 @@
-
-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.
-