Mod Wiki - User contributions [en-gb]

Main Page

2007-11-16T14:01:52Z

192.168.0.129: Added declarations section with material/template/surfacetype info to the Script & Code section

__NOTOC__= '''Tutorials''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA;" |
=== Basics ===
|-
|
* '''[[Taking A Screenshot]]''' - Settings and options for making a great screenshot!
|-
| style="border-bottom: 1px solid #AAAAAA;" |
=== Terrain ===
|-
|
* '''[[Making a Terrain Model]]''' - Create a terrain mesh for your map.
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA;" |
=== Vehicles ===
|-
|
* '''[[Vehicle Tutorial]]''' - The whole thing! Click below for smaller segments.
** '''[[Vehicle Tutorial Part 1|Step 1]]''' - Design considerations, before you do anything else!
** '''[[Vehicle Tutorial Part 2|Step 2]]''' - Initial rough model, rig and basic script.
** '''[[Vehicle Tutorial Part 3|Step 3]]''' - More advanced rig and scripting.
** '''[[Vehicle Tutorial Part 4|Step 4]]''' - Further technical setup ideas.
|-
| style="border-bottom: 1px solid #AAAAAA;" |
=== Models & Textures ===
|-
|
* '''[[Making A Normal Map]]''' - Using Renderbump to generate a bump-map from a high-poly model.
|-
|}
|}

= '''Script & Code''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA;" |
=== Declarations ===
|-
|
* '''[[Materials]]''' - All you need to know about material declarations.
* '''[[Templates]]''' - Setting up templates to save time and effort.
* '''[[Surface Types]]''' - Available surface types for particle & sound effects.
|-
| style="border-bottom: 1px solid #AAAAAA;" |
=== Vehicle Scripting ===
|-
|
* '''[[Vehicle Scripting: Basic_Overview|Basic Overview]]''' - Introduction to vehicle setup.
* '''[[Vehicle Scripting: Entity_Definition|Entity Definition]]''' - One definition to rule them all!
* '''[[Vehicle Scripting: Vehicle_Definition|Vehicle Definition]]''' - Introduction to the ''.vscript'' file.
* '''[[Vehicle Scripting: Positions_&_Views|Positions & Views]]''' - Configuring player positions & camera views.
* '''[[Vehicle Scripting: Components|Components]]''' - Details of various vehicle components.
* '''[[Vehicle Scripting: Weapons|Weapons]]''' - Things that go boom!
* '''[[Vehicle Scripting: IK|IK]]''' - Inverse Kinematics & you...
* '''[[Vehicle Scripting: Cockpits|Cockpits]]''' - Cockpit setup.
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA;" |
=== Entity Scripting ===
|-
|
* '''[[EntityClass:Overview|Classes]]''' - Tree of entity types.
* '''[[ScriptEvent:List|Events]]''' - List of all script events.
* '''[[Scripting:Examples|Examples]]''' - Some example walkthoughs of building up a scripted entity.
* '''[[Script:Files|Script Files]]''' - List of the script files used by the game.
|-
| style="border-bottom: 1px solid #AAAAAA;" |

=== GUIs ===
|-
|
* '''[[GUIs|GUI Overview]]''' - Overview of the GUI system.
* '''[[GUIs: Event Based Scripting|Event Based Scripting]]''' - GUIs are event-based.
* '''[[GUIs: Materials|Materials]]''' - Using materials in GUIs.
* '''[[GUIs: Transitions|Transitions]]''' - Transitions.
* '''[[GUIs: Templates|Templates]]''' - Using templates in GUIs.
* '''[[GUIs: List Enumeration|List Enumeration]]''' - List enumerations.
* '''[[GUIs: Properties|Properties]]''' - Player/Global properties and more.
* '''[[GUIs: Timelines|Timelines]]''' - GUI timelines.
* '''[[GUIs: Layouts|Layouts]]''' - Window layouts.
* '''[[Reference (GUIs)|Reference]]''' - GUI reference.
|-
|}
|}

= '''Design''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA;" |
=== Introduction ===
|-
|
* '''[[Design: New In ETQW|What's new in ETQW]]'''
* '''[[Design: ETQW from WET|Notes for W:ET mappers]]''' - for Wolfenstein: Enemy Territory mappers
* '''[[Design: editWorld from Radiant|Notes for Radiant users]]''' - for experienced Radiant users
* '''[[Design: editWorld from Worldcraft|Notes for Worldcraft users]]''' - for experienced Worldcraft users
|-
| style="border-bottom: 1px solid #AAAAAA;" |
=== The Basics ===
|-
|
* '''[[Design: editWorld Basics|Editor Basics]]''' - start here
* '''[[Design: Brush Basics|Brush Basics]]''' - make your map
* '''[[Design: Entity Basics|Entity Basics]]''' - populate your map
* '''[[Design: Lighting Basics|Lighting Basics]]''' - light your map
* '''[[Design: Portal Basics|Portal Basics]]''' - portalise your map
* '''[[Design: References|Reference Basics]]''' - modularise your map
* '''[[Design: Map files|Map files]]'''
----
* '''[[Design: How do I|How do I ...?]]''' - Common and useful tasks
* '''[[Design: Troubleshooting|Troubleshooting]]''' - Common problems and fixes
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA;" |
=== Advanced Stuff ===
|-
|
* '''[[Design:List of Entities|List of Entities]]''' - Descriptions for all entities
* '''[[Design: Geometry Optimisation|Optimising Geometry]]''' - How to increase performance
|-
| style="border-bottom: 1px solid #AAAAAA;" |

=== Everything Else ===
|-
|
* '''[[Design: editWorld Bugs and Fixes|Bugs and Fixes]]''' - Known and new bugs or issues
* '''[[Design: editWorld Customisation|Customising editWorld]]'''
* '''[[Design: Biscuits|Biscuits]]''' - Biscuits that enhance ETQW mapping
|-
|}
|}

= '''Art''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA;" |
=== Models ===
|-
|
* '''[[In-Game Models]]''' - Making models for use in the engine.
* '''[[High-Poly Models]]''' - Making source models for baking normal maps.
* '''[[Renderbump]]''' - Create normal maps from high-poly geometry.
* '''[[Imposters]]''' - Sprites used for rendering complex models cheaply at a distance.
|-
| style="border-bottom: 1px solid #AAAAAA;" |
=== Animation ===
|-
|
* '''[[MD5 Export Process]]''' - How to export an animated MD5.
* '''[[Vehicle Setup]]''' - How to set up a vehicle.
|-
| style="border-bottom: 1px solid #AAAAAA;" |
=== Textures ===
|-
|
* '''[[Basic Texture Overview]]''' - Supported texture types and implementations.
* '''[[Texturesheets]]''' - Overview of what texturesheets are, and when to use them.
* '''[[The Atlas Editor]]''' - Create environment texture sheets to improve performance.
* '''[[RenderBumpFlat]]''' - Create normal-maps from high-poly geometry.
* '''[[Detail Textures]]''' - Add high-frequency detail to your textures.
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA;" |
=== Terrain Editing ===
|-
|
* '''[[Making a Terrain Model]]''' - Create a terrain mesh for your map.
* '''[[Terrain Editor|EditWorld's Terrain Editor]]''' - Set up a Surface Tree for your MegaTexture.
* '''[[MegaBuild]]''' - Render and compile your MegaTexture.
* '''[[Water Surfaces#Water Models|Water Surfaces]]''' - Create water to go with your landscape.
* '''[[STUFF System]]''' - Procedurally distribute models over your terrain mesh.
|-
| style="border-bottom: 1px solid #AAAAAA;" |
=== Atmospheres and Effects ===
|-
|
* '''[[Atmosphere Editor|The Atmosphere Editor]]''' - Create and edit atmospheres for your map.
* '''[[Ambient Light Editor|The Ambient Light Editor]]''' - Create and edit ambient light setups.
* '''[[Environment Maps]]''' - Used for reflection effects.
* '''[[Water Surfaces]]''' - Creating water effects.
* '''[[Effects Editor|The Effects Editor]]''' - Create and edit particle effects.
* '''[[Cheap Decals]]''' - Bulletholes and other collision decals.
|-
|}
|}

Materials

2007-11-16T13:59:46Z

192.168.0.129: Tabulated everything

Material decls are similar to shader files from Quake3, but they are a lot more powerful. Materials have a lot of power, especially when combined with scripts and GL programs.

== Tables ==

In Quake3, you could do all kinds of neat things with sin waves, saw tooth waves, square waves and other types of waves, but you were pretty much screwed if you wanted any kind of non standard wave form. In Doom 3, you can define arbitrary data lookup tables, then reference them in your materials.
The format of a table definiton is:

table <tablename> { [snap] [clamp] { <data>, <data>, ... } }
Where [snap] is an optional key word which means "jump directly from one value to the other (don't blend between values)" and [clamp] is an optional key word which means "don't wrap around if the index is outside the range of table elements, (return the first value if less or the last value if it's more)". Both keywords are optional, and can be used together.
Now, armed with this knowledge, we can easily construct a square wave lookup table:

table squarewave { snap { 0, 1 } }
The sin table is a bit harder, but lucky for you, it's already defined shaderDemo.mtr

== Materials ==

Every material file has a global section, followed by one or more stages. The global section, as the name implies, sets properties that affect all the stages. In Quake3 the stages were pretty easy to understand because the engine rendered them in order: stage 1, then stage 2, then stage 3, etc.. In Doom 3 the order is not quite as simple because of the way the lighting system works, but for the most part, they are still rendered in order.
Let's look at a simple material (some random wall in the alpha labs):

material textures/alphalabs/a_lfwall21b
{
qer_editorimage textures/alphalabs/a_lfwall21b
bumpmap textures/base_wall/lfwall21_local
diffusemap textures/alphalabs/a_lfwall21b
specularmap textures/alphalabs/a_lfwall21b_s
}
The first line is the name of the material (which in this case also happens to be the name of the diffuse map). Notice the use of the 'material' keyword. This is required for all materials, unlike Doom3.

The global section begins right after the open curly brace. The first key word we see is qer_editorimage, which tells Radiant which image to use in the editor. This is the image used in the texture window, as well as in the 3D view. Next we define the bump map (normal map), the diffuse map (colors), and the specular map (gloss). This is about as basic of a material file you can get, while still using the advanced lighting features. Technically all you need is 'diffusemap', in which case the specular map is black, the bump map is blue, and the editorimage is the diffusemap. Creating an entire map with those types of materials will look roughly like Quake 3.
In most cases you won't need to specify the qer_editorimage unless you specifically need something which looks different to the diffusemap.

This material looks like it doesn't have any stages, but in fact it has 3 stages. The 'bumpmap' 'diffusemap' and 'specularmap' keywords are simply shortcuts for stages as we will see later.

== Shaders in Materials ==

ETQW has the ability to use custom GL vertex and fragment programs when rendering a stage of a material. This is mostly seen in the 'heat haze' effects around fire, in the warping effects on glass, and in the warping effects on various projectiles (like the BFG). For documentation on how to write your own renderprograms programs, see the separate [[Render program documentation]]

There is nothing stopping an artist from writing those, but I would really let a programmer handle writing the renderprogram. The main thing an artist or level designer needs to know is how to use the renderprogram in their materials.
This is the material file for the hornet smoke which uses one of the heathaze effects. Using other renderprograms works in a similar way:

material particles/penta/hornetheathaze {
noshadows
translucent
nonsolid
{
program heatHazeWithVertex
deformScroll 0, 0
deformMagnitude 1
bumpMap textures/particles/smoke/smokenormal.tga
maskAlpha
}
}

There is a single stage in this material. It uses a special program, this means it will not render like any other material but that it will use that program to do some special effect. It also means that certain parameters are surrendly read by the engine.
So the heatHazeWithVertex causes the engine to render the stage as a heathaze surface, it also looks at the values of deformScroll and deformMagnitude to define the specific strength of the heathaze effect (how much warping is going on). The engine automatically knows at which parameters to read when you use a certain program, so while you can set these parameters on any material only programs that actually use them will care about their value. Also note how the texture is specified using the bumpMap [bleh] command, altough you use the bumpmap command here it won't render like any other bumpmapped surface since the "program heatHazeWithVertex" told the engine to do special rendering for this surface.

The list of new "commands" that are available when you use a certain program is not fixed, so every new program may define new variables you can set. Most programs tend to use the default values like "map", "bumpMap", "diffuseMap", ... so most of the time you don't need to know about any special variables to use the program.

== Maths and Logic ==

Materials in Doom 3 can contain mathematical and logical expressions. These expressions are evaluated for each material every frame, and are what cause normally boring surfaces to come alive. This is a replacement for the rather limited shader commands in Quake 3 such as tcMod scroll, rgbGen, etc.
Let's take a look at a material to see these features in use:

material models/weapons/soulcube/soulcube3fx
{
noSelfShadow
translucent
noShadows
{
if ( parm7 > 3 )
blend add
map models/weapons/soulcube/soulcube3fx
rgb scTable[ time * .5 ]
}
}
In Doom 3, certain stages of the material can be selectively turned on and off. The 'if' command in this example means "only draw this material if parm7 is greater than 3." There are a few places where parm7 can get set, one of them is in the editor with the 'shaderParm0' to 'shaderParm11' keys. Another place is in the script file (such as with weapons). Of course, it can also get set in the code.

Notice the use of a lookup table in this material. Here we are using 'time' (which is a floating point number that increases forever) to look up a value in 'scTable' (which was defined using a 'table' decl earlier).

The mathematical operators you can use in a material are %, /, *, -, and +. You can also use the boolean operators <, >, <=, >=, ==, !=, &&, and ||. The meaning of the symbols is the same as in C/C++, Java, PHP, etc. Mathematical expressions should be enclosed in parenthesis (there are cases where they don't have to be, such as when they are used as an index to a lookup table, but it never hurts to have too many. For the operands, you can use a lookup table, any numerical constant, and any of the following variables:

time: Forever increasing floating point value that returns the current time in seconds
parm0-parm11: Parameters that can be set a number of ways (discussed above)
global0-global7: Not used right now
fragmentPrograms: Constant that is 1 if ARB fragment programs are available. This is mostly used for disabling a stage by specifying "if ( fragmentPrograms == 1 )"
sound: The current sound amplitude of the entity using this material. This is used to create light materials that pulse with the sound.

== New backend ==

The new backend slightly changes the way how shaders work, altough internally the system is very different we tried to keep external changes as small as possible. The next few topics are mainly "copy pastable" cases.

=== Alphatested surfaces ===

Unlike doom3 bump/specular/diffuse maps are not treated as separate material stages anymore, so instead of having three stages with one map each you now have one stage with the three maps specified at once. This makes for less stages and a generally more intuitive way of creating shaders.
The biggest change because of this is the alpha testing. While you specified the bump and specular stages like normal stages and specified added the alphatest on the diffuse stage before, now you need one stage with has diffuse+bump+specular maps with alpha testing enabled.
An alpha tested stage now looks like this:

material textures/alphademo {
{
diffusemap textures/decals/fgrill2_d.tga
specularmap textures/decals/fgrill2_s.tga
bumpmap addnormals( textures/decals/fgrill_local.tga , heightmap ( textures/decals/fgrill2_b.tga, 1 ) )

alphaTest 0.5
}
}

=== Clamped textures ===

Clamping was specified in the shader/stage body before, this is not very logical as it is actually an image parameter. Therefore clamping now has to be specified before image names.

material textures/clampdemo {
{
blend add
map clamp textures/decals/blast.tga
}
}

=== Animated texture coordinates ===

Since bump/normal/specular are now part of a single stage( see alphatest information ) the texture matrices can't be specified per stage anymore, therefore there is a new "texturematrix" command you can use to specify the texture matrix of a specific texture.

material textures/matrixdemo {
{
bumpmap textures/base_wall/wire_fence2_local.tga
specularmap textures/base_wall/a_wire_fence2_s.tga
diffusemap textures/base_wall/a_wire_fence2_d.tga
alphaTest 0.5

textureMatrix bumpMatrix {
translate 2, 2
}

textureMatrix specularMatrix {
translate 4, 4
}

textureMatrix diffuseMatrix {
translate 2, 2
}
}

You can still use the old texture matrix system, but this means it will only affect the diffuse map and NOT the specular/normal map. If you are writing a non bumpmapped material you should also use the old way of specifying texture matrices.

= Reference =

== Parameters Key ==
These are all the parameters which can be passed to material functions and values.
{| style="border: 1px solid #AAAAAA;" width="100%"
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | <float>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Any number.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | <int>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | An integer - any number without a fractional part.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | <string>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Any value enclosed in quotes.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | <index>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | An integer number that is an index into an array.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | <map>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | An image map, which may include image programs (below).
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | <prog>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | A vertex / frament program. Written using the GL ARB shader language. These files are stored in the ''glprogs'' directory.
|-
| valign="top" style="background: #F0F0F0;" | <exp>
| valign="top" | An expression that is evaluated every frame.
|}

== Global Keywords for Regular Materials ==
{| style="border: 1px solid #AAAAAA;" width="100%"
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | qer_editorimage <map>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Image to display in the editor
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | description <string>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Just a simple description for people using this material
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | polygonOffset
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | [float] offset the depth buffer to combat z-fighting
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | noShadows
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Don't cast shadows
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | noSelfShadow
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | This material doesn't cast shadows on the model it's on (but it does on other models)
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | forceShadows
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Allows nodraw surfaces to cast shadows
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | noOverlays
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Overlay / Decal suppression
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | forceOverlays
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Force decal overlays for alpha tested or translucent surfaces
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | translucent
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | The engine thinks this is a translucent material (which means no ambient/zfill pass will be done for this material)
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | forceOpaque
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Opposite forces the engine to think this is a nontranslucent material.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | twoSided
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Draw the front and back. Implies no-shadows, because the shadow volume would be coplanar with the surface, giving depth fighting.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | backSided
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Draw only the back. This also implies no-shadows.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | mirror
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Use to make mirrors
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | noFog
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Don't fog this surface
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | guisurf <guifile>
guisurf entity[2|3]
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | This surface has a gui on it. Use "somegui.gui" to specify the gui, or entity, entity2, entity3, etc for the level designer to set it in Radiant.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | sort <type>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Type is one of: subview, opaque, decal, far, medium, close, almostNearest, nearest, postProcess
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | spectrum <int>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Spectrums are used for "invisible writing" that can only be illuminated by a light of matching spectrum
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | deform <type>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Type is one of: sprite, tube, flare, expand, move, turbulent, eyeBall, particle, particle2
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | decalInfo <staySeconds>
<fadeSeconds> [start rgb] [end rgb]
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Used in decal materials to set how long the decal stays, and how it fades out.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | renderbump <args...>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | [[RenderBump]] command options, without "renderbump" at the start
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | diffusemap <map>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | shortcut for
{
blend diffusemap
map <map>
}
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | specularmap <map>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | shortcut for
{
blend specularmap
map <map>
}
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | bumpmap <map>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | shortcut for
{
blend bumpmap
map <map>
}
|-
| valign="top" style="background: #F0F0F0;" | DECAL_MACRO
| valign="top" | shortcut for
polygonOffset 1
discrete
sort decal
noShadows
|}

== Global Keywords for Light Materials ==
{| style="border: 1px solid #AAAAAA;" width="100%"
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | noShadows
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | This light doesn't cast shadows.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | forceShadows
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | fog, blend, and ambient lights don't cast shadows by default. This forces them to cast shadows.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | noPortalFog
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | This fog volume won't ever consider a portal fogged out.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | fogLight
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Option to fill with fog from viewer instead of light from center.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | blendLight
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Perform simple blending of the projection, instead of interacting with bumps and textures.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | ambientLight
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | An ambient light has non-directional bump mapping and no specular.
|-
| valign="top" style="background: #F0F0F0;" | lightFalloffImage <map>
| valign="top" | specifies the image to use for the third axis of projected light volumes.
|}

== Global Surface Parameters ==
{| style="border: 1px solid #AAAAAA;" width="100%"
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | surfacetype "<stp>"
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Sets a surface type for particles and sound effects, where <stp> is one of the [[Surface Types|valid surface types]].
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | solid
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | may need to override a clearSolid
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | water
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | used for water
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | playerclip
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | solid to players
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | monsterclip
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | solid to monsters
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | moveableclip
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | solid to moveable entities
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | ikclip
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | solid to IK
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | blood
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | used to detect blood decals
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | trigger
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | used for triggers
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | aassolid
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | solid for AAS
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | aasobstacle
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | used to compile an obstacle into AAS that can be enabled/disabled
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | flashlight_trigger
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | used for triggers that are activated by the flashlight
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | nonsolid
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | clears the solid flag
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | nullNormal
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | renderbump will draw as 0x80 0x80 0x80, which won't collect light from any angle
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | areaportal
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | divides areas
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | qer_nocarve
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | don't cut brushes in editor
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | discrete
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | surfaces should not be automatically merged together or clipped to the world, because they represent discrete objects like gui shaders mirrors, or autosprites
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | noFragment
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | dmap won't cut surface at each bsp boundary
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | collision
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | collision surface. if a model has no collision surfaces, then all surfaces are considered collision surfaces
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | noimpact
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | don't make impact explosions or marks
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | nodamage
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | no falling damage when hitting
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | ladder
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | player can climb up this surface
|-
| valign="top" style="background: #F0F0F0;" | nosteps
| valign="top" | No footstep sounds.
|}

= Stage Keywords =
blend <type>
blend <src>, <dst>

Blend types: Type Src Dst
blend gl_src_alpha gl_one_minus_src_alpha
add gl_one gl_one
filter gl_dst_color gl_zero
modulate gl_dst_color gl_zero
none gl_zero gl_one
bumpmap Normal map
diffusemap Diffuse map
specularmap Specular map

Source blend modes: gl_one Constant 1
gl_zero Constant 0
gl_dst_color The color currently on the screen
gl_one_minus_dst_color One minus the color currently on the screen
gl_src_alpha The alpha channel of the source image
gl_one_minus_src_alpha One minus the alpha channel of the source image
gl_dst_alpha The alpha channel of the screen image
gl_one_minus_dst_alpha One minus the alpha channel of the screen image
gl_src_alpha_saturate Minimum of the source alpha and one minus screen alpha

Destination blend modes: gl_one Constant 1
gl_zero Constant 0
gl_src_color The color of the source image
gl_one_minus_src_color One minus the color of the source image
gl_src_alpha The alpha channel of the source image
gl_one_minus_src_alpha One minus the alpha channel of the source image
gl_dst_alpha The alpha channel of the screen image
gl_one_minus_dst_alpha One minus the alpha channel of the screen image

{| style="border: 1px solid #AAAAAA;" width="100%"
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | map <map>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | The image program to use for this stage.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | remoteRenderMap <int> <int>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Width and Height of the buffer to render a remote image in to (for cameras). The entity this material is applied to has to support remote render views.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | mirrorRenderMap <int> <int>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Width and Height of the buffer to render a mirror in to. This of course makes this stage a mirror stage, which is different from using the 'mirror' global keyword because that makes the entire material a mirror, rather than just one stage.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | videomap [loop] <file>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | This stage uses a video stream as an image map.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | soundmap [waveform]
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | This stage uses a sound meter from the sound system as an image map. Specify 'waveform' to get a scope rather than bars.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | cubeMap <map>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | This stage uses a cube map as the image map. Looks for _px, _py, _pz, _nx, _ny, _nz for the positive x, y, z, and negative x, y, z sides.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | cameraCubeMap <map>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | This stage uses a cube map in camera space. Looks for _forward, _back, _left, _right, _up, and _down.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | ignoreAlphaTest
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Always use DEPTHFUNC_LEQUAL rather than DEPTHFUNC_EQUAL which is normally used for opaque and alpha tested surfaces.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | nearest
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Use nearest texture filtering.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | linear
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Use linear texture filtering.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | clamp
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Same as the global keywords. Use to override a global clamp for a specific stage.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | zeroclamp
| valign="top" style="border-bottom: 1px solid #AAAAAA;" |
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | alphazeroclamp
| valign="top" style="border-bottom: 1px solid #AAAAAA;" |
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | noclamp
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Use to set texture repeat for a stage when global clamp is set.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | uncompressed
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Do not compress this image in medium quality mode.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | highquality
| valign="top" style="border-bottom: 1px solid #AAAAAA;" |
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | forceHighQuality
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Do not compress this image in low quality mode.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | nopicmip
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Ignore the image_downSize cvar.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | vertexColor
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Multiply the pixel color by the vertex color.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | inverseVertexColor
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Multiply the pixel color by one minus the vertex color.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | privatePolygonOffset <float>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Explicit larger (or negative) polygon offset for this stage.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | texGen <type>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Type is one of: normal, reflect, skybox, wobbleSky <exp> <exp> <exp>.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | scroll <exp>, <exp>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Scroll the texture coordinates.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | translate <exp>, <exp>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" |
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | scale <exp>, <exp>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Just scales without a centering.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | centerScale <exp>, <exp>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Subtracts 0.5, then scales, then adds 0.5.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | shear <exp>, <exp>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Subtracts 0.5, then shears, then adds 0.5.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | rotate <exp>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Subtracts 0.5, then rotates, then adds 0.5.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | maskRed
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Don't write to the red channel.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | maskGreen
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Don't write to the blue channel.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | maskBlue
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Don't write to the green channel.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | maskAlpha
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Don't write to the alpha channel.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | maskColor
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Shortcut for
maskRed
maskGreen
maskBlue
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | maskDepth
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Don't write to the depth buffer.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | alphaTest <exp>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Only write if the alpha value is greater than <exp>.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | red <exp>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Set the red vertex color.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | green <exp>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Set the green vertex color.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | blue <exp>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Set the blue vertex color.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | alpha <exp>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Set the alpha vertex value.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | rgb <exp>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Shortcut for
red <exp>
green <exp>
blue <exp>
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | rgba <exp>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Shortcut for
red <exp>
green <exp>
blue <exp>
alpha <exp>
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | color <exp0>, <exp1>, <exp2>, <exp3>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Shortcut for
red exp0
green exp1
blue exp2
alpha exp3
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | colored
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Shortcut for
color parm0, parm1, parm2, parm3
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | if <exp>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Conditionally disable stages.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | fragmentProgram <prog>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Use an ARB fragment program with this stage.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | vertexProgram <prog>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Use an ARB vertex program with this stage.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | program <prog>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Shortcut for
fragmentProgram <prog>
vertexProgram <prog>
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | vertexParm <index> <exp0> [,exp1] [,exp2] [,exp3]
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Values to pass to the vertex program. One expression gets repeated across all 4 values. Two expressions put 0, 1 in z, w. Three expressions put 1 in w.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | fragmentMap <index> [options] <map>
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | The image map to use for texture unit <index>. [options] can be cubeMap, cameraCubeMap, nearest, linear, clamp, noclamp, zeroclamp, alphazeroclamp, forceHighQuality, uncompressed, highquality, or nopicmip.
|-
| valign="top" style="background: #F0F0F0;" | megaTexture <mega>
| valign="top" | This stage uses a MegaTexture.
|}

== Image Program Functions ==
These can be used anywhere that accepts <map>, and can be nested.

{| style="border: 1px solid #AAAAAA;" width="100%"
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | heightmap(<map>, <float>)
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Turns a grayscale height map into a normal map. <float> determines how "deep" the bump map appears.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | addnormals(<map>, <map>)
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Adds two normal maps together. Result is normalized.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | smoothnormals(<map>)
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Does a box filter on the normal map, and normalizes the result.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | add(<map>, <map>)
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Adds two images without normalizing the result.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | scale(<map>, <float> [,float] [,float] [,float])
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Scales the RGBA by the specified factors. Defaults to 0.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | invertAlpha(<map>)
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Inverts the alpha channel (0 becomes 1, 1 becomes 0).
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | invertColor(<map>)
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Inverts the R, G, and B channels.
|-
| valign="top" style="border-bottom: 1px solid #AAAAAA; background: #F0F0F0;" | makeIntensity(<map>)
| valign="top" style="border-bottom: 1px solid #AAAAAA;" | Copies the red channel to the G, B, and A channels.
|-
| valign="top" style="background: #F0F0F0;" | makeAlpha(<map>)
| valign="top" | Sets the alpha channel to an average of the RGB channels. Sets the RGB channels to white.
|}

[[Category:Scripting]]

Category:Vehicles

2007-10-16T09:42:04Z

192.168.0.129:

Articles relating to vehicle modding.

Models

2007-10-15T17:14:49Z

192.168.0.129: Removed old article link

== In-Game Models ==
{{:In-Game Models}}

== High-Poly Models ==
{{:High-Poly Models}}

== Renderbump ==
{{:Renderbump}}

== MD5 LOD ==
{{:MD5 LOD}}

== Imposters ==
{{:Imposters}}

[[Category:Art]]

Category:Animation

2007-10-15T17:14:21Z

192.168.0.129:

Articles related to animation.

MD5 LOD

2007-10-15T17:14:03Z

192.168.0.129:

MD5 LOD can be used to add lower-poly models which get swapped in as view distance from the object increases.<includeonly>

{{main|MD5 LOD}}</includeonly><noinclude>

Static LOD for MD5 models has been implemented. The code automatically scans for X - 1 LOD files for each .md5mesh file loaded. X is defined by the ''r_MD5MaxLodStages'' cvar, which defaults to 4 at the moment. The code will look for the following files:

mymd5mesh.md5mesh (main model)
mymd5mesh_lod1.md5mesh (1st lod)
mymd5mesh_lod2.md5mesh (2st lod)
mymd5mesh_lod3.md5mesh (3st lod)

To create a MD5 mesh file to be used as a LOD stage, you have to make sure it has the same bone setup as the main mesh. During exporting, ensure to use the same commandline as well, but add -noJoints. Joint are only read from the main mesh file, so there is no need to have them stored in the LODstages as well.

''r_MD5LodScale'' can be used to scale LOD faloff.

[[Category:Art]] [[Category:Animation]] [[Category:Models]]
</noinclude>

Models

2007-10-15T17:13:26Z

192.168.0.129:

== In-Game Models ==
{{:In-Game Models}}

== High-Poly Models ==
{{:High-Poly Models}}

== Renderbump ==
{{:Renderbump}}

== Collision Model Exporting ==
{{:Collision Model Exporting}}

== MD5 LOD ==
{{:MD5 LOD}}

== Imposters ==
{{:Imposters}}

[[Category:Art]]

Vertex Colouring

2007-10-15T17:13:04Z

192.168.0.129:

=== Vertex Texture Blending in Lightwave ===

* First you need to make a vertex color map. Click the '''Map''' tab at the top, then '''New Color Map''' on the left of your screen, and press '''Ok'''.
* Using the surface editor ('''F3''') click the Advanced tab for each of your blends and set the vertex color map to the color map you just created.
* Using '''W''', select your polys with the blend and the polys that they blend to, for example "textures/sand/sand01torock01" and "textures/rock/rock01".
* Cut and paste these 2 sets of polys into a second layer (press '''x''' to cut and '''v''' to paste, or '''CTRL-x''' and '''CTRL-v''' in Lightwave 8).
* Make sure the points of these 2 sets are merged (press '''m''', then '''Ok''')
* Now select the blend polys and hide them by pressing '''-'''.
* Now in point mode select all the remaining points and press Shift+| .
* You should now have all the points of the blend polys selected, click the map tab at the top, then point colour on the left of your screen. In the drop down menu select Vertex Color. Change alpha to 1 and make sure the color is black (should be by default).
* Now unhide everything by pressing '''\'''.
* Cut and paste the second layer back into your first layer.
'''All done! Now repeat steps 3 to 10 for your other blends'''

=== Simple Vertex Colouring in Lightwave (for [[STUFF System|STUFF models]])===

* First you need to make a vertex color map. Click the '''Map''' tab at the top, then '''New Color Map''' on the left of your screen, and press '''Ok'''.
* Using the surface editor ('''F3''') click the Advanced tab for each of your blends and set the vertex color map to the color map you just created.
* Select the points you want to have vertex coloured, click the '''Map''' tab at the top, then '''Point Color''' on the left of your screen. In the drop down menu select Vertex Color. Make sure you set Alpha to 1.0, then set your desired vertex RGB colour:
** Note: With STUFF models, black means it will not animate at all while white will animate as much as possible.<noinclude>

[[Category:Models]]
</noinclude>

Shadow Hulls

2007-10-15T17:12:43Z

192.168.0.129:

=== Overview ===
Shadow hulls are used to improve in-game graphics performance. They should be used on more complex meshes, to keep the shadow count down. This is especially valuable in areas with many shadow-casting lights.

=== Tips ===
* Shadow hulls should be "watertight" meshes wherever possible - open edges will result in lower performance.
* Shadow hulls should always be inside the main visible mesh. Any parts which clip through the visible mesh may produce odd-looking shadow artifacts.<noinclude>

[[Category:Models]]
</noinclude>

Collision Meshes

2007-10-15T17:12:19Z

192.168.0.129:

=== Overview ===
Collision meshes are used to improve in-game physics performance. They can also be used to stop players or vehicles catching on small protrusions from meshes, and generally smoothing out player movement over complex shapes.

=== Tips ===
* Unlike shadow hulls, collision meshes do not have to be "watertight", open edges are allowed. However, bear in mind that things in the game will only collide with front-facing polys, so a single flat plane would only have collision on one side of it.
* Collision meshes are automatically optimised by the game to use polygons rather than triangles. Therefore, co-planar triangles will be optimised down into a single ''n''-sided polygon, for efficiency and performance.<noinclude>

[[Category:Models]]
</noinclude>

UV Unwrap Conventions

2007-10-15T17:12:00Z

192.168.0.129:

* Use a checker pattern image while unwrapping to check for texture stretching.
* Trade off texture stretching with having more continuous UV's between adjoining faces; this will help prevent ugly specular seams.
* Try to keep UV edge breaks along an intended hard edge; again, this helps prevent obvious seams.
* Try to cluster adjacent model components in similar areas in UV space; it makes the texture easier to work with.
* If you can't see both sides of an identical set of faces at the same time, mirror the UVs!
* Try to maintain consistent UV space usage on all '''important''' areas of the model, so that texture scale is consistent.
** With special-case models such as first person weapons or cockpits, if part of the model is always particularly close to the screen then more UV space should be used.
* Where UV space is limited, try tiling textures as much as is possible. In most cases this will mean subdividing the mesh but generally texture space is more precious than polygon count.
* Pack UVs as tightly as possible (while still leaving a 4 or 5 pixel gap around each part, to prevent seams showing up due to mip-mapping).<noinclude>

[[Category:Models]]
</noinclude>

In-Game Models

2007-10-15T17:11:34Z

192.168.0.129:

These are the models that are displayed by the engine.<includeonly>

{{main|In-Game Models}}</includeonly><noinclude>
__NOEDITSECTION__
== Low-Poly Modelling Conventions ==
Tips and techniques for low-poly modelling.

== UVW Unwrapping Conventions ==
{{:UV Unwrap Conventions}}

== Making Collision Models ==
{{:Collision Meshes}}

== Making Shadow Hulls ==
{{:Shadow Hulls}}

== Vertex Colouring ==
{{:Vertex Colouring}}

[[Category:Art]]
[[Category:Models]]
</noinclude>

Animation

2007-10-15T17:11:20Z

192.168.0.129:

Animation overview to go here.

[[Category:Art]]

Category:Models

2007-10-15T17:10:44Z

192.168.0.129:

Articles related to modeling.

High-Poly Models

2007-10-15T17:10:30Z

192.168.0.129:

Source models for creating normal maps.<includeonly>

{{main|High-Poly Models}}</includeonly><noinclude>

=== High-Poly Modelling Conventions ===
Subdivision modelling, sculpting etc.

=== Workflow Tips ===
#Float detail, as the trace for the normal map only cares about the normal of the high poly polygon it hits it doesn't matter if the surface is layered. This works for detailing indents as well protruding geometry.
#Test the model in game/detail visible peices, it's easy to get carried away detailing high poly models. Testing the model in game as soon as possible allows you to run around it and decide where more detail needs to be added and where detail can be very basic. This is mostly dependant on what the player can see, having a solid test model all the way though the asset creation also means if something more important comes up you can easily and quickly finish work on this asset. It will also help you meet deadlines and allow more useful feedback.
#Pixel density defines poly detail, make sure that you have a realistic idea about how your high poly detail will translate to the normal map. Theres no use using more than one high poly polygon per normal map pixel

[[Category:Art]]
[[Category:Models]]
</noinclude>

Vehicle Setup

2007-10-15T17:09:16Z

192.168.0.129:

You can set up breakable vehicles by defining models to be detached when they damaged or destroyed.<includeonly>

{{main|Vehicle Setup}}</includeonly><noinclude>

= Detachable Components =

== Maya Setup ==
The model in Maya needs every detachable component as a separate object with a unique name.

== Detachable Model ==
The detachable model should be exported to a static model (''lwo/obj/ase'') with relative orientation to the closest relevant joint. If the model is far away, problems may arise in game with the parts jittering around, to fix them try adding a closer joint.

This model now needs a collision model, as an easy rule we can use a extruded pentagon deformed to roughly match the render model. If it gets too complicated the game will refuse to load it, if this happens try simplifying it.

== Setup in Vehicle Script ==

=== SimplePart Setup ===
A simple part needs to be set up in the vehicle script (''.vscript''). In ETQW, these scripts are kept in the ''base/vehicles'' folder. Here is an example, this is the right wing-mirror for the Armadillo:

simplePart {
"name" "Right Mirror"
"surface1" "m_right_mirror"
"surface2" "s_right_mirror"
"joint" "base"
"def_brokenPart" "part_vehicle_badger_right_mirror"
"health" "10"
}

This definition should be placed within the main vehicle definition.

* '''name''' is for your own reference.
* '''surface1''' is the first surface of the detachable model which the game detects being hit and hides, in this case it is a render model.
* '''surface2''' is the second surface the game hides. This is a simplified shadow model which has a different material to the render model and so has to be a separate object in maya. This section is unnecessary if there is no separate shadow model.
* '''joint''' is the joint the static model has been exported relative to.
* '''def_brokenPart''' is referencing the part setup shown below in the '''Part entityDef''' section.
* '''health''' is how much health the detachable component has (how much damage it can take before detaching). If this value is set to 0 the component will not detach until the vehicle's total health falls to zero and everything comes off in one go.

=== Part entityDef ===

The part entity defines more parameters of the detachable component, including the most important one, the static model it references.

entityDef part_vehicle_badger_right_mirror {
useTemplate templates/vehicles/destroyedParts <
"models/vehicles/edf_badger/parts/right_mirror.lwo",
"0 -200 700",
"0 0 2",
"vehicles/misc/debris/glass_small",
"0.1"
>
"climate_skin_key" "badger"
"priority" "0"
}

This is placed straight into the ''.vscript'', it is not enclosed in any other definitions.

The first section of this is referencing a template. This template has the parameters, however the defaults are usually ok.

ModelParm,
VelocityParm = "500 0 0",
AngularVelParm = "2 4 10",
SoundBounceParm = "vehicles/misc/debris/metal_medium",
BouncynessParm = "0.25",
FrictionParm = "0.5",
DensityParm = "0.01",
TrailParm = "effects/vehicles/generic_debris",
LifeTimeParm = "10",

The ones you will want to change are the "ModelParm" (to be the static model you exported from Maya) and possibly the "SoundBounceParm" and the "TrailParm".

== General Tips ==
* Try to avoid making long, thin detachable components as the game has trouble handling them.
* Physics calculations are very expensive, try and keep the detachable components as simple and few as possible, particularly when (like in ETQW) there is the possibility of a sudden mass death where multiple vehicles could be instantly destroyed!
* If there are too many detachable components at once the game will remove them! You may end up with the game removing the larger ones.
* Collision models can cope with polygons with more than 3 sides. The game automatically treats co-planar triangles as one polygon. Less polygons in the collision models is much better!
* Components with 0 health will appear when the vehicle is totally destroyed, e.g. the vehicle's main hull or parts that cannot be shot off.

[[Category:Art]][[Category:Models]]
</noinclude>

Imposters

2007-10-15T17:08:58Z

192.168.0.129:

Imposters are a way of more cheaply rendering complex models in the distance. Distant models are replaced by a special sprite, this sprite is rendered using a bump and diffuse map so it can be lit like the real thing. These maps can be automatically generated using the imposter tool. In ETQW, imposters are generally used for rendering trees, bushes and other foliage cheaply in the distance.<includeonly>

{{main|Imposters}}</includeonly><noinclude>
__NOEDITSECTION__
As the imposter has a bumpmap it is independent of the lighting in your map; changing the lighting will also cause the imposters to change. As the bump & diffuse maps are precalculated based on the model you will have to regenerate the imposter if your model or the model's textures change.

= Creating an Imposter =
To create an imposter you first have to make an "imposterGenerator" declaration. This specifies what models to use, the names of the output textures and materials and some extra options. The structure is as follows:
imposterGenerator imposters/myfolder/mymodel {
sourceModel models/myfolder/mymodel.lwo
outputTexture models/myfolder/mymodel.tga
numAngles 8
tileSize 64 128
vertexColored
}

The options are:
* '''sourceModel''' - The model you want to render to the sprites from.
* '''outputTexture''' - The TGA file you want to save the sprites in. Generally keeping this in the same folder as the model makes sense, since it's easy to find.
* '''numAngles''' - The number of angles to generate "sprites" for. More angles will look better, but take more texture memory. Generally, radially similar models need less angles than asymmetrical objects.
* '''tileSize''' - Optional. Specifies the X and Y size in pixels that each sprite rotation should occupy in the destination TGA.
* '''vertexColored''' - Optional. Use this if your source model is rendered in the game using vertex colors.

=== Notes ===
All declarations like this should be saved as '''.imp''' files in the ''base/imposters'' folder. You can have as many "imposterGenerator" declarations in a single .imp file as you want, for example you could keep all imposterGenerator declarations for palm tree models in ''base/imposters/generate_palm.imp''.

= Generating an Imposter =

Run the console command "'''imposter [imposterGenerator name]'''" to (re)create the necessary imposter textures (for the above example, you would type '''imposter imposters/myfolder/mymodel''' in the console). This will do the following:
* Render the model sprites and save them in the specified tga
* Create a new "imposter" declaration in imposters.imp
* Create a new material in imposters.mtr
In theory none of these things should be modified by hand, just re-run the "imposter" command. You can also regenerate all imposters in the game by typing "imposter all" in the console.

= Using Imposters in Your Map =
Any entity can have an "imposter" key, the value of this key should be set to match the ''imposterGenerator'' name. The model of that entity will then be replaced by the imposter based on distance (Note that MaxVisDist is ignored for imposters).
You can also place an imposter in you map using "misc_imposter", in this case the imposter will '''always''' be rendered, never the model. These are more efficient for out of bounds objects than just placing a func_static with an imposter on it (you may still give them a model key so they look similar in Radiant, but the game will only render the imposter).

= Considerations for Imposters =
* They take some texture memory, so don't start doing imposters for every small pebble.
* The "symmetry" of the base model should be along the z-axis, so say you wanted a pillar that has fallen over, it may be better to model it standing upright and then rotate it using the angles key of the entity. That will ensure the least visual distortion is caused by the imposter.

[[Category:Art]] [[Category:Models]] [[Category:Level Design]]
</noinclude>

Category:Tutorials

2007-10-15T17:08:21Z

192.168.0.129:

Tutorial Articles.

Taking A Screenshot

2007-10-15T17:08:07Z

192.168.0.129:

Here are the settings we use when taking promotional screenshots for ETQW:
__NOEDITSECTION__
== Before Loading Map ==
Firstly, make sure you are running the game in a 16:9 widescreen resolution and aspect ratio.
To make sure you are using the highest-resolution textures, set this cvar in the console ''then restart the game'':
* '''image_picmipEnable 0''' - This turns off any "picmip" settings individual materials may use.

When back in the game, set this value in the console:
* '''r_md5usehardwareskinning 0'''

== After Loading Map ==
Set these values in the console (or put them all in a ''.cfg'' file and exec that):
* '''image_anisotropy 8''' - Uses best texture filtering.
* '''r_md5LodBias -9999''' - Draw models at best detail to further distance.
* '''r_stuffFadeEnd 10000''' - STUFF draw distance end (makes grass draw to a further range).
* '''r_stuffFadeStart 9000''' - STUFF draw distance start (makes grass draw to a further range).
* '''r_useMaxVisDist 0''' - Turn off distance culling. ''Beware, this may cause "minVisDist" models to be drawn all the time, which is bad!''
* '''r_visDistMult 1.2''' - Push detail distance back a bit.
* '''r_skipImposters 1''' - Turns off billboard sprite LODs.
* '''g_skipPostProcess 0''' - Make sure post-processing is on.
* '''ui_showGun 0''' - Don’t draw the firstperson weapon models.
* '''g_showHUD 0''' - Don’t draw the HUD.
* '''com_showFPS 0''' - Don’t show frame-rate counter.
* '''con_noPrint 1''' - Don’t show console output on screen.
* '''r_aspectRatio 1''' - Make sure we are in 16:9 aspect ratio.
* '''bind F11 "screenshot 2560 1440 8"''' - Set F11 to take a high-resolution, 8x antialiased screenshot.

== Field of View ==

Lowering the Field of View ('''g_Fov <angle>''' in the console) will help fight camera distortion, but lowering the FOV too far from the default 90 will cause the MegaTexture to look lower resolution. This can be countered to some extent by freezing the MegaTexture tile loading at the point of focus of the shot by entering '''r_skipMegaTexture 1''' into the console and then tracking back to the appropriate camera position.

== Lighting ==

For tweaking the atmosphere settings of the scene you can type '''editAtmos''' while the game is running windowed to launch the [[Atmosphere Editor]]. Here you can select from a predefined list of atmospheres, or tweak an existing one. It is not recommended that you move the sun angle too much from its original location as the predefined lighting on the MegaTexture will start to look wrong. For a specific shot you can play quite a lot with the ambient light tab, to improve the lighting on the intended screenshot subject(s).

== NoClipping ==

To move around the scene it's best to use the free fly mode. Type '''noclip''' in the console. To adjust your movement speed use '''pm_noclipspeed <speed>''' (200 is the default, 100 is slower 300 is faster, etc). You should also be able to hold down the Shift key to temporarily move at a faster speed (which itself can be changed with the '''pm_noclipspeedsprint''' cvar).

[[Category:Art]]
[[Category:Tutorials]]

Main Page

2007-10-15T17:07:34Z

192.168.0.129: /* Making a Terrain Model */ Placeholder link

__NOTOC__= '''Tutorials''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Taking A Screenshot]] ===
|-
|
* '''[[Taking A Screenshot]]''' - Settings and options for making a great screenshot!
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Making a Terrain Model]] ===
|-
|
* '''[[Making a Terrain Model|Step 1]]''' - Create a terrain mesh for your map.
* More to go here, temp for now.
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |

=== [[Vehicle Tutorial]] ===
|-
|
* '''[[Vehicle Tutorial Part 1|Step 1]]''' - Design considerations, before you do anything else!
* '''[[Vehicle Tutorial Part 2|Step 2]]''' - Initial rough model, rig and basic script.
* '''[[Vehicle Tutorial Part 3|Step 3]]''' - More advanced rig and scripting.
* '''[[Vehicle Tutorial Part 4|Step 4]]''' - Further technical setup ideas.
|-
|}
|}

= '''Code''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Vehicle Scripting]] ===
|-
|
* '''[[Vehicle Scripting: Basic_Overview|Basic Overview]]''' - Introduction to vehicle setup.
* '''[[Vehicle Scripting: Entity_Definition|Entity Definition]]''' - One definition to rule them all!
* '''[[Vehicle Scripting: Vehicle_Definition|Vehicle Definition]]''' - Introduction to the ''.vscript'' file.
* '''[[Vehicle Scripting: Positions_&_Views|Positions & Views]]''' - Configuring player positions & camera views.
* '''[[Vehicle Scripting: Components|Components]]''' - Details of various vehicle components.
* '''[[Vehicle Scripting: Weapons|Weapons]]''' - Things that go boom!
* '''[[Vehicle Scripting: IK|IK]]''' - Inverse Kinematics & you...
* '''[[Vehicle Scripting: Cockpits|Cockpits]]''' - Cockpit setup.
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Entity Scripting]] ===
|-
|
* '''[[EntityClass:Overview|Classes]]''' - Tree of entity types.
* '''[[ScriptEvent:List|Events]]''' - List of all script events.
* '''[[Scripting:Examples|Examples]]''' - Some example walkthoughs of building up a scripted entity.
* '''[[Script:Files|Script Files]]''' - List of the script files used by the game.
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[GUIs]] ===
|-
|
* '''[[GUIs: Event Based Scripting|Event Based Scripting]]''' - GUIs are event-based.
* '''[[GUIs: Materials|Materials]]''' - Using materials in GUIs.
* '''[[GUIs: Transitions|Transitions]]''' - Transitions.
* '''[[GUIs: Templates|Templates]]''' - Using templates in GUIs.
* '''[[GUIs: List Enumeration|List Enumeration]]''' - List enumerations.
* '''[[GUIs: Properties|Properties]]''' - Player/Global properties and more.
* '''[[GUIs: Timelines|Timelines]]''' - GUI timelines.
* '''[[GUIs: Layouts|Layouts]]''' - Window layouts.
* '''[[Reference (GUIs)|Reference]]''' - GUI reference.
|-
|}
|}

= '''Design''' =

= '''Art''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Models]] ===
|-
|
* '''[[In-Game Models]]''' - Making models for use in the engine.
* '''[[High-Poly Models]]''' - Making source models for baking normal maps.
* '''[[Renderbump]]''' - Create normal maps from high-poly geometry.
* '''[[Imposters]]''' - Sprites used for rendering complex models cheaply at a distance.
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Animation]] ===
|-
|
* '''[[MD5 Export Process]]''' - How to export an animated MD5.
* '''[[Vehicle Setup]]''' - How to set up a vehicle.
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Textures]] ===
|-
|
* '''[[Basic Texture Overview]]''' - Supported texture types and implementations.
* '''[[Texturesheets]]''' - Overview of what texturesheets are, and when to use them.
* '''[[The Atlas Editor]]''' - Create environment texture sheets to improve performance.
* '''[[RenderBumpFlat]]''' - Create normal-maps from high-poly geometry.
* '''[[Detail Textures]]''' - Add high-frequency detail to your textures.
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Terrain Editing]] ===
|-
|
* '''[[Making a Terrain Model]]''' - Create a terrain mesh for your map.
* '''[[Terrain Editor|EditWorld's Terrain Editor]]''' - Set up a Surface Tree for your MegaTexture.
* '''[[MegaBuild]]''' - Render and compile your MegaTexture.
* '''[[Water Surfaces#Water Models|Water Surfaces]]''' - Create water to go with your landscape.
* '''[[STUFF System]]''' - Procedurally distribute models over your terrain mesh.
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Atmospheres and Effects]] ===
|-
|
* '''[[Atmosphere Editor|The Atmosphere Editor]]''' - Create and edit atmospheres for your map.
* '''[[Ambient Light Editor|The Ambient Light Editor]]''' - Create and edit ambient light setups.
* '''[[Environment Maps]]''' - Used for reflection effects.
* '''[[Water Surfaces]]''' - Creating water effects.
* '''[[Effects Editor|The Effects Editor]]''' - Create and edit particle effects.
* '''[[Cheap Decals]]''' - Bulletholes and other collision decals.
|-
|}
|}

Main Page

2007-10-15T17:07:12Z

192.168.0.129: /* Vehicle Tutorial */

__NOTOC__= '''Tutorials''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Taking A Screenshot]] ===
|-
|
* '''[[Taking A Screenshot]]''' - Settings and options for making a great screenshot!
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Making a Terrain Model]] ===
|-
|
* '''[[Step 1]]''' - Create a terrain mesh for your map.
* More to go here, temp for now.
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |

=== [[Vehicle Tutorial]] ===
|-
|
* '''[[Vehicle Tutorial Part 1|Step 1]]''' - Design considerations, before you do anything else!
* '''[[Vehicle Tutorial Part 2|Step 2]]''' - Initial rough model, rig and basic script.
* '''[[Vehicle Tutorial Part 3|Step 3]]''' - More advanced rig and scripting.
* '''[[Vehicle Tutorial Part 4|Step 4]]''' - Further technical setup ideas.
|-
|}
|}

= '''Code''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Vehicle Scripting]] ===
|-
|
* '''[[Vehicle Scripting: Basic_Overview|Basic Overview]]''' - Introduction to vehicle setup.
* '''[[Vehicle Scripting: Entity_Definition|Entity Definition]]''' - One definition to rule them all!
* '''[[Vehicle Scripting: Vehicle_Definition|Vehicle Definition]]''' - Introduction to the ''.vscript'' file.
* '''[[Vehicle Scripting: Positions_&_Views|Positions & Views]]''' - Configuring player positions & camera views.
* '''[[Vehicle Scripting: Components|Components]]''' - Details of various vehicle components.
* '''[[Vehicle Scripting: Weapons|Weapons]]''' - Things that go boom!
* '''[[Vehicle Scripting: IK|IK]]''' - Inverse Kinematics & you...
* '''[[Vehicle Scripting: Cockpits|Cockpits]]''' - Cockpit setup.
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Entity Scripting]] ===
|-
|
* '''[[EntityClass:Overview|Classes]]''' - Tree of entity types.
* '''[[ScriptEvent:List|Events]]''' - List of all script events.
* '''[[Scripting:Examples|Examples]]''' - Some example walkthoughs of building up a scripted entity.
* '''[[Script:Files|Script Files]]''' - List of the script files used by the game.
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[GUIs]] ===
|-
|
* '''[[GUIs: Event Based Scripting|Event Based Scripting]]''' - GUIs are event-based.
* '''[[GUIs: Materials|Materials]]''' - Using materials in GUIs.
* '''[[GUIs: Transitions|Transitions]]''' - Transitions.
* '''[[GUIs: Templates|Templates]]''' - Using templates in GUIs.
* '''[[GUIs: List Enumeration|List Enumeration]]''' - List enumerations.
* '''[[GUIs: Properties|Properties]]''' - Player/Global properties and more.
* '''[[GUIs: Timelines|Timelines]]''' - GUI timelines.
* '''[[GUIs: Layouts|Layouts]]''' - Window layouts.
* '''[[Reference (GUIs)|Reference]]''' - GUI reference.
|-
|}
|}

= '''Design''' =

= '''Art''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Models]] ===
|-
|
* '''[[In-Game Models]]''' - Making models for use in the engine.
* '''[[High-Poly Models]]''' - Making source models for baking normal maps.
* '''[[Renderbump]]''' - Create normal maps from high-poly geometry.
* '''[[Imposters]]''' - Sprites used for rendering complex models cheaply at a distance.
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Animation]] ===
|-
|
* '''[[MD5 Export Process]]''' - How to export an animated MD5.
* '''[[Vehicle Setup]]''' - How to set up a vehicle.
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Textures]] ===
|-
|
* '''[[Basic Texture Overview]]''' - Supported texture types and implementations.
* '''[[Texturesheets]]''' - Overview of what texturesheets are, and when to use them.
* '''[[The Atlas Editor]]''' - Create environment texture sheets to improve performance.
* '''[[RenderBumpFlat]]''' - Create normal-maps from high-poly geometry.
* '''[[Detail Textures]]''' - Add high-frequency detail to your textures.
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Terrain Editing]] ===
|-
|
* '''[[Making a Terrain Model]]''' - Create a terrain mesh for your map.
* '''[[Terrain Editor|EditWorld's Terrain Editor]]''' - Set up a Surface Tree for your MegaTexture.
* '''[[MegaBuild]]''' - Render and compile your MegaTexture.
* '''[[Water Surfaces#Water Models|Water Surfaces]]''' - Create water to go with your landscape.
* '''[[STUFF System]]''' - Procedurally distribute models over your terrain mesh.
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Atmospheres and Effects]] ===
|-
|
* '''[[Atmosphere Editor|The Atmosphere Editor]]''' - Create and edit atmospheres for your map.
* '''[[Ambient Light Editor|The Ambient Light Editor]]''' - Create and edit ambient light setups.
* '''[[Environment Maps]]''' - Used for reflection effects.
* '''[[Water Surfaces]]''' - Creating water effects.
* '''[[Effects Editor|The Effects Editor]]''' - Create and edit particle effects.
* '''[[Cheap Decals]]''' - Bulletholes and other collision decals.
|-
|}
|}

Vehicle Tutorial Part 4

2007-10-15T17:06:44Z

192.168.0.129:

== Advanced Scripting ==

There are a plethora of other things you can do with your vehicle to set it up. I'm going to go into some of them here.

=== Vehicle HUD ===

When you are in a vehicle in ETQW a HUD section is added in the bottom left showing details about the vehicle - health, passengers, etc. These are quite simple to create, as they are all done through templates. The only new asset you need to create is an icon for it - it should be pretty easy from looking at the existing icons. They're made up from a border and a fill image, a couple of examples are <tt>guis/assets/icons/vehicles/gdf_top_husky_border.tga</tt> and <tt>guis/assets/icons/vehicles/gdf_top_husky_fill.tga</tt>.

To make the material you'll need to create a new <tt>.mtr</tt> file and place it in a <tt>materials</tt> directory in your mod directory. I'm calling mine <tt>buggy_tute.mtr</tt>. The material is created using a template, so we'll need to include the template file before we can create the material. Here is the result for mine. Note that I'm reusing the Husky's icon:
<tt>
#include <materials/guis/hud/gdf.include>

material guis/assets/hud/vehicles/buggy_tute
{
_vehicle_icon( "guis/assets/icons/vehicles/gdf_top_husky" )
}
</tt>

Now you can make the GUI. You'll need to make a <tt>.gui</tt> file and place this in a <tt>guis</tt> directory in your mod directory. I'm calling mine <tt>buggy_tute.gui</tt>. Again, we'll need to include a template file first:
<tt>
#include <guis/game/vehicles/gdf/cockpits.include>

gui guis/vehicles/buggy_tute {
properties {
float flags = immediate( flags ) | GUI_FULLSCREEN;
}
materials {
"icon" "guis/assets/hud/vehicles/buggy_tute"
}
_class_icons
_base_icon
_hud_materials
_position( 0, 1.5, 10 )
}
</tt>

Next add the following key to the <tt>entityDef</tt>:
<tt>
"gui_vehicle" "guis/vehicles/buggy_tute"
</tt>

<noinclude>
[[Category:Vehicles]]
[[Category:Tutorials]]</noinclude>

Vehicle Tutorial Part 3

2007-10-15T17:06:16Z

192.168.0.129:

== '''More Advanced Joints''' ==
[[Image:buggy_rough_rig2.jpg|frame|right|More advanced vehicle rig showing the joint positions and names.]]
You can now add extra joints as needed for more passengers, gunners, suspension, effects locations and exit points.
* '''Passengers''' - For each passenger you want to add, you will need a joint for the player location, and a joint for their first-person camera view.
* '''Gunners''' - This can be set up like a passenger, but with more scripting needed, as described in the Scripting section below.
* '''Suspension''' - These joints should be parented to the origin joint, and have the related wheel joint as a child.
* '''Exit points''' - These joints define more places that players may appear when they exit the vehicle.
* '''Effects locations''' - Used as an attachment location for effects such as smoke and fire when the vehicle is damaged.

=== '''Related Files''' ===
----
* [[Media:buggy_tute_step2.max|More advanced rig example (3ds max 8 format)]]
* [[Media:buggy_tute_step2.mb|More advanced rig example (Maya 7 format)]]

== '''More Scripting''' ==

In Part 2 you learnt how to get your vehicle into the game in a very rough state. Here we are going to expand on what we developed last time to improve it

=== Suspension ===
----
Now that we have suspension joints we can hook them up so that we can see the wheels moving up and down, following the ground. To the <tt>text</tt> part of the wheel template add the following line:
<tt>
"suspension" "vehicle_buggy_tute_FrontBackParm_LeftRightParm_suspension"
</tt>

This makes the wheel look for a <tt>stringMap</tt> to describe the suspension. The simplest type is <tt>vertical</tt>, which is the one we are going to use here:
<tt>
stringMap vehicle_buggy_tute_front_right_suspension {
"type" "vertical"
"joint" "front_right_suspension"
}
stringMap vehicle_buggy_tute_front_left_suspension {
"type" "vertical"
"joint" "front_left_suspension"
}
stringMap vehicle_buggy_tute_rear_right_suspension {
"type" "vertical"
"joint" "rear_right_suspension"
}
stringMap vehicle_buggy_tute_rear_left_suspension {
"type" "vertical"
"joint" "rear_left_suspension"
}
</tt>

These can go in the vscript file, outside the <tt>vehicleDef</tt>

=== Shooting it ===
----
At the moment your vehicle will not take damage when people shoot it - this is because it does not fit in any of the target lists used by the bullet damage definitions. To put it into these target lists we need to add the vehicle to some "collections". You'll need to add it to the following collections by adding these keys to the <tt>entityDef</tt>:
<tt>
"collection_antivehicle" "antivehicle"
"collection_vehicles_light" "vehicles_light"
"collection_vehicles_gdf" "vehicles_gdf"
</tt>

The first of these allows it to be targeted by anti-vehicle turrets. The second marks it as being a light vehicle - this means it will take more damage from bullets than if it were markes as a heavy vehicle. The last one allows it to be damaged by various map entities, for example Strogg energy walls.

=== Damage Effects ===
----
You'll probably now notice that your vehicle will have flames/smoke coming from the origin of the model when it gets significantly damaged. This is where your damage effect joint comes in - again, these keys go in the <tt>entityDef</tt>:
<tt>
"joint_damage_smoke" "effects"
"joint_damage_fire" "effects"
</tt>

This will make the damage effects play at the joint named <tt>effects</tt>. You can adjust the effects that play, and when they play, with the following keys:
<tt>
"damage_smoke" "70"
"damage_level1" "50"
"damage_level2" "30"
"damage_level3" "10"

"fx_damage_level_smoke" "effects/vehicles/generic_smoke"
"fx_damage_level1" "effects/vehicles/vehicle_flames_small"
"fx_damage_level2" "effects/vehicles/vehicle_flames_medium"
"fx_damage_level3" "effects/vehicles/vehicle_flames_large"
</tt>

The smoke effect will play at the same time as the damage level 1, 2, or 3 effects. When the vehicle's health drops below the value specified by <tt>"damage_smoke"</tt> etc the corresponding effect will be played. I have given the default values here.

=== Collision Damage ===
----
Your vehicle will not currently do any damage to anything else in a collision. For this you'll need to make a new damage type for the collision:
<tt>
damageDef damage_buggy_tute_collide {
damage "damage_buggy_tute_collide"

team_kill_cvar "g_allowComplaint_vehicles"

tt_obituary "tooltips/killmsgs/vehicles/buggy_tute"
tt_obituary_unknown "tooltips/killmsgs/vehicles/buggy_tute/empty"
tt_obituary_team_kill "tooltips/killmsgs/vehicles/buggy_tute/teamkill"
tt_obituary_self "tooltips/killmsgs/vehicles/driving"
}

damageFilter damage_buggy_tute_collide {
type {
target "target_player_all"
damage 100
}
type {
target "target_veh_all"
damage 100
}
type {
target "target_supply_crate"
damage 200
}
type {
target "target_deployables_all"
damage 100
}
}
</tt>

I put these in the <tt>buggy_tute.def</tt> file, below the vehicle's <tt>entityDef</tt>. This sets up a damage filter listing the target sets that are damaged by the vehicle, and values that scale the damage caused - the damage caused varies with the speed of the collision. The damage definition also specifies a cvar that can be used to enable and disable complaints for team kills by this damage type, and obituary names. I'll describe how to set the obituaries up below.

=== Name ===
----
Anything to be displayed on the HUD needs to be a localized string. Its pretty easy to create new strings, but there are a few files involved. First of all you'll want to create a few directories under your mod directory: <tt>localization</tt>, <tt>localization/locstr</tt>, <tt>localization/english</tt>, and <tt>localization/english/strings</tt>. Now create a couple of files to put your new strings in: <tt>localization/locstr/buggy_tute.locstr</tt>, and <tt>localization/english/strings/buggy_tute.lang</tt>. Into the <tt>locstr</tt> files go <tt>locString</tt> definitions, which are named strings that can have arguments. Into <tt>lang</tt> files go tables of string values. This allows there to be <tt>lang</tt> files for each language, having different strings for each language but with them all looking the same from the rest of the game's code & data.

Into the <tt>locstr</tt> file add:
<tt>
locString game/vec/buggy_tute {
text "#str_10000100"
}
</tt>

The number in the string is used to identify the number of the localized string in the <tt>lang</tt> file. All strings in retail ETQW are numbered less than 10000000, so values over that are safe. I like to set aside a range of values for a category of strings - in this case I'm setting aside the range 10000100 -> 10000200 for this vehicle. This helps prevent the situation where you have to search through all the files to find an unused number.
* '''Note:''' You do not have to use this exact numbering scheme, for example to prevent conflicts you could call your string ''"#str_buggy_001"'' etc. This is slightly easier to remember and less potential string conflicts to worry about.

In the <tt>lang</tt> file all the strings must be between a pair of braces, so add:
<tt>
{
"#str_10000100" "Buggy!"
}
</tt>

Any further strings I add for this car I'll be adding in between the two braces.
You can now hook this up to the vehicle entity by changing the value of its <tt>"info_name"</tt> key to <tt>"game/vec/buggy_tute"</tt>. When you look at the vehicle in the game you should now see "Buggy!" :)

=== Obituaries ===
----
There are three obituaries we need to fill in (we referenced them above when we made a collision damage definition). The strings for these are referenced via a tooltip definition, so we need to make those:
<tt>
tooltip tooltips/killmsgs/vehicles/buggy_tute {
text "game/obit/buggy_tute"
}

tooltip tooltips/killmsgs/vehicles/buggy_tute/empty {
text "game/obit/buggy_tute_empty"
}

tooltip tooltips/killmsgs/vehicles/buggy_tute/teamkill {
text "game/obit/buggy_tute_team"
}
</tt>

I added these at the end of the <tt>buggy_tute.def</tt> file. Next we need to set up the localized string definitions for these:
<tt>
locString game/obit/buggy_tute {
text "#str_10000101"
}

locString game/obit/buggy_tute_empty {
text "#str_10000102"
}

locString game/obit/buggy_tute_team {
text "#str_10000103"
}
</tt>

And finally the actual localized strings:
<tt>
"#str_10000101" "%b^0 &lbrBuggy&rbr %a"
"#str_10000102" "&lbrBuggy&rbr %a"
"#str_10000103" "%b^1 &lbrBuggy&rbr ^0%a"
</tt>

These strings have some interesting escape sequences in them. <tt>%a</tt> and <tt>%b</tt> are replaced with the names of the name of the killer and the killed respectively, <tt>&lbr</tt> and <tt>&rbr</tt> are replaced by left square brackets and right square brackets respectively, and the caret ( <tt>^</tt> ) symbol allows the text colour to be changed.

=== Command Map ===
----
At the moment your vehicle won't be visible on the command map. This is easy fixed:
<tt>
"icon_size_cm" "16"
"mtr_commandmap" "guis/assets/commandmap/icon_vehicle"
"mtr_commandmap_unknown" "guis/assets/commandmap/icon_vehicle"
</tt>

The first key sets the size of the icon and the other two set the material to be used for the icon. The unkown material isn't really important in this case, you should just set it to the same as the normal material as I have done here.

=== Control Binding Context ===
----
In ETQW bindings can be context sensitive, and by using a series of cvars (one for each vehicle type) you can customize the control layout for each vehicle. To set the name of the context cvar your vehicle uses you can add the following key to your vehicle's <tt>entityDef</tt>:
<tt>
"control_context" "g_bind_context_buggy"
</tt>

Note that you can call the cvar whatever you like. To create the cvar you will need to pull the console down and set it by typing something like <tt>set g_bind_context_buggy vehicle</tt>. This can be included in config files with your mod to ensure people have the cvars created.

=== Tuning the Steering ===
----
The default values for the steering tend to be pretty good for most cases. The steering works on the principle that there is a direction in which the player wants to go - by pressing left and right they alter the direction they want to go in. The game then tries to steer towards that direction. When driving a real car you automatically adjust the steering wheel as you go over bumps etc by feel - you do not get any of this feeling from a keyboard, normally by the time you see your car veering to one side from hitting a bump its already too late to correct it neatly. Keyboards are also an on/off input device, so making subtle corrections is very difficult. The game is essentially trying to compensate for your lack of this feeling of the road surface and make all the subtle adjustments you aren't able to make.

There are a number of keys that can be set on the vehicle's <tt>entityDef</tt> to adjust the behaviour of the steering:

{|border="1" cellpadding="4" cellspacing="0"
| style="background:#dfdfdf" | '''Key''' || style="background:#dfdfdf" | '''Default Value''' || style="background:#dfdfdf" | '''Description'''
|-
| <tt>steering_angle</tt> || n/a || The maximum steering angle.
|-
| <tt>simplesteer_forward_speed</tt> || 2 || The speed at which the desired direction of movement will change due to player input while moving forward.
|-
| <tt>simplesteer_reverse_speed</tt> || -4 || The speed at which the desired direction of movement will change due to player input while moving in reverse.
|-
| <tt>simplesteer_centering_speed_min</tt> || 2 || The minimum speed at which the steering will tend to center back towards the current movement direction.
|-
| <tt>simplesteer_centering_speed_max</tt> || 15 || The maximum speed at which the steering will tend to center back towards the current movement direction.
|-
| <tt>simplesteer_centering_ramp_threshold</tt> || 20 || The vehicle speed at which the centering speed will drop to the minimum value (as the vehicle speeds up the steering becomes less twitchy).
|-
| <tt>simplesteer_centering_speed_air</tt> || 0.5 || The speed at which the steering will tend to center back towards the current movement direction while the vehicle is airborne (so it doesn't lose the direction of movement too fast when jumping).
|-
| <tt>simplesteer_reverse_angle_scale</tt> || -0.5 || Scales the amount/direction of steering when moving in reverse.
|}

For example if you wish the player's input to result in the vehicle turning faster you can increase <tt>simplesteer_forward_speed</tt>.

=== Engine Sounds ===
----
One thing thats our vehicle lacks so far is sound. ETQW wheeled vehicles use three looping samples that are cross-faded and pitched with varying speeds and accelerator input values. In addition to this there is an engine start sound and an engine stop sound for when the driver gets in or out. All of these things are defined in the <tt>entityDef</tt>.

Firstly you'll need to set the sound control method:
<tt>
"sound_control" "wheeled"
</tt>

You need to specify the samples to be used. We use an idle sample & a drive sample, where idle is cross-faded with the drive as speed increases, and a "hard acceleration" sample which is faded in and out with speed and input. This is meant to emulate the ferocious exhaust note you hear on a vehicle that is accelerating hard.

<tt>
"snd_engine_start" "sounds/vehicles/badger/engine/start"
"snd_engine_stop" "sounds/vehicles/badger/engine/stop"
"snd_engine_idle" "sounds/vehicles/badger/engine/idle"
"snd_engine_drive" "sounds/vehicles/badger/engine/drive"
"snd_engine_hardaccel" "sounds/vehicles/husky/engine/hardaccel"
</tt>

In my case I'm reusing most of the sounds of the badger, but mixing in the husky acceleration sound to hopefully make it sound a bit more raw.

The first few parameters control the change in pitch of the samples as the vehicle changes pitch:
<tt>
"engine_pitch_low" "1.5"
"engine_pitch_high" "2"
"engine_speed_low" "10"
"engine_speed_high" "150"
</tt>

This sets the high & low levels of the pitch and the speeds at which they occur. At <tt>engine_speed_low</tt> the pitch will be <tt>engine_pitch_low</tt> and similarly for high speed. The pitch is linearly ramped between those two. The original pitch in the sample is 1, so 1.5 is 50% faster, and 0.5% is 50% slower.

The next few parameters control engine "spooling" - this is meant to emulate the fact that an engine does not speed up or slow down instantly:
<tt>
"engine_accel_spool_time" "0.033"
"engine_decel_spool_time" "0.033"
</tt>

This is how long it takes for the "engine speed" to reach the actual speed of movement, in seconds. 0.033 is instant (1 / 30 - ie, one 30fps game frame).

Next are the volume settings for the idle and drive samples:
<tt>
"engine_idle_min_speed" "5.0"
"engine_idle_max_speed" "50.0"
"engine_idle_min_vol" "0.0"
"engine_idle_max_vol" "-50.0"
"engine_idle_power" "1.0"
"engine_idle_fade_time" "0.066"

"engine_drive_min_speed" "20.0"
"engine_drive_max_speed" "80.0"
"engine_drive_min_vol" "-20.0"
"engine_drive_max_vol" "-5.0"
"engine_drive_power" "0.3"
"engine_drive_fade_time" "0.066"
</tt>

At the min speed the sample will be at min volume - at max speed the sample will be at max volume. The sample will change between the two depending on the power value. This adjusts the linearity of the curve - 1 is linear, greater than 1 is exponential (slow change at first, fast change later), and less than 1 (but greater than zero) changes fast at first and slowly later. The fade time governs how long it takes the sound to fade away when the engine is shut off. All volume settings are measured in decibels, with zero being the original sample volume.

Next are the acceleration sound tuning parameters - these are much more complicated. First of all there are parameters to allow the pitch to be adjusted semi-independently of the idle and drive samples:
<tt>
"engine_accel_pitch_mult" "1.0"
"engine_accel_pitch_offset" "0.5"
</tt>

The pitch used for the other samples is subtracted from the minimum pitch, multiplied by the pitch multiplier and added to the offset. This effectively allows the pitch to change over a different range of values, given the same speed range, with the offset value giving the minimum. The pitch and the volume can also be adjusted based on the yaw speed of the vehicle (see the Titan/MCP for examples).

The volume of the acceleration sound has three key points - a min, mid and a max value. Each has a speed and a corresponding volume, and the transition between min & mid and mid & max each have their own power values to adjust the linearity of the transition. It is also increased when going up steep slopes and when the player is accelerating, to emulate the engine straining.
<tt>
"engine_accel_min_speed" "1.0"
"engine_accel_mid_speed" "20.0"
"engine_accel_max_speed" "80.0"
"engine_accel_min_vol" "-5.0"
"engine_accel_mid_vol" "5.0"
"engine_accel_max_vol" "-3.0"
"engine_accel_power_low" "0.1"
"engine_accel_power_high" "5.0"
"engine_accel_fade_time" "0.0"
</tt>

==== Overdrive Sounds ====

There are default overdrive sound settings, but you may want to tweak those. They support pitch shifting much like the engine sounds:
<tt>
"snd_overdrive" "sounds/vehicles/husky/overdrive"
"snd_overdrive_stop" "sounds/vehicles/husky/overdrive/stop"

"overdrive_pitch_low" "0.9"
"overdrive_pitch_high" "1.5"
"overdrive_speed_low" "20"
"overdrive_speed_high" "90"
</tt>

=== Miscellaneous Sounds ===
----
There are a couple of other sounds used by vehicles - the horn, and the low health warning. These are dead easy to configure:
<tt>
"snd_horn_loop" "sounds/vehicles/husky/horn"
"snd_horn_stop" "sounds/vehicles/husky/horn/stop"

"snd_health_warn" "sounds/vehicles/misc/warning/ground/gdf"
</tt>

The keys used should be pretty self-explanatory for these!

<noinclude>'''[[Vehicle Tutorial Part 4|Click here to continue on to Part 4 of the Vehicle Tutorial.]]'''
[[Category:Models]]
[[Category:Vehicles]]
[[Category:Tutorials]]
</noinclude>

Vehicle Tutorial Part 2

2007-10-15T17:06:01Z

192.168.0.129:

I'm going to assume you already know how to make a model in LightWave, Maya, or 3D Studio Max. The following tutorial contains specific things to be aware of when modelling vehicles for ET:QW.

== '''Roughing Out The Model''' ==
[[Image:buggy_rough.jpg|frame|right|A rough vehicle model with GDF players for scale.]]
Firstly, and most importantly, don't rush into anything! Modelling a vehicle is a big project, and you need to consider a number of things before you get busy modelling.
The last thing you want is to get your model all detailed out in high-poly, then realise that you've forgotten to allow the wheels space to move, or the player doesn't fit inside. This will result in wasted time and effort.

Instead, it makes sense to "rough out" your whole vehicle quickly, using basic shapes and without worrying about texturing or optimisation. Just model enough to make sure that your vehicle will drive well in-game, and be able to be used correctly by players. You can worry about fine details and texturing once it's sure that the design of the vehicle will cause no problems in-game.

=== '''Scaling''' ===
* Import an existing ET:QW vehicle and player mesh into your scene to make sure your vehicle is scaled appropriately relative to them.
* Choose a player animation that will suit your vehicle (eg. set up the Badger driver player animation in [[EditWorld]] and export it as an .OBJ file). You can use this to get the size of your seats and position of the steering wheel correct.

=== '''Texturing''' ===
* For the time being your vehicle doesn't need a "proper" texture ... you just need a placeholder [[Materials|material]] to make sure the model will show up in game. Either create your own material and placeholder texture, or use something like ''textures/concrete/concrete10'' for example.

== '''A Basic Vehicle Rig''' ==
Once your model is roughed out, you will be ready to add bones (referred to in ETQW as "joints") and rig up your model to work in the game.

=== '''Joints''' ===
[[Image:buggy_rough_rig.jpg|frame|right|Initial vehicle rig showing the joint positions and names.]]
Here is a list of the major joints you will need, and what they do. This is the absolute minimum needed to get a 4-wheeled vehicle with no suspension working in game. Further info on adding suspension or a second passenger/gunner can be found in Part 3 of this tutorial.
The joint names can be whatever you want, but bear in mind that you will have to refer to them by name in the VScript later, so naming them sensibly can save you a lot of time and avoids confusion.

* '''With this setup, all joints should be parented to the ''origin'' joint.'''

{|border="1" cellpadding="4" cellspacing="0"
| style="background:#dfdfdf" | '''Joint Name''' ||style="background:#dfdfdf"| '''Description'''
|-
| ''origin'' || The root joint of the vehicle, it should be at 0,0,0 in the scene.
|-
| ''cam1'' || Used to position the player's first-person view when sitting inside the vehicle.
|-
| ''driver'' || Used to position the 3D player model within the vehicle.
|-
| ''exit1'' || The location where the player will try to get out of the vehicle.
|-
| ''front_left_wheel'' || The point that the front left wheel will rotate around.
|-
| ''front_right_wheel'' || The point that the front right wheel will rotate around.
|-
| ''rear_left_wheel'' || The point that the rear left wheel will rotate around.
|-
| ''rear_right_wheel'' || The point that the rear right wheel will rotate around.
|}

* '''Important note:''' all joints should be aligned so that they face forward along the world's X axis, and their local Z axis should point upwards. If not, you may find that your wheels or player view are rotated incorrectly in the game.
** In 3DS Max, you can make sure that this is correct by creating Bones in the ''Top'' viewport and dragging them out to the right. Turn on ''Grid Snap'' to make sure the joints are perfectly straight.
** Related tips for Maya, Chris?

=== '''Skinning''' ===
----
Skinning (also known as weighting, or binding) is the process of linking your model to the relevant joints.
In the case of vehicles it is very straightforward, since nearly all parts of the model are only ever influenced by a single joint.
So for example, you would need to bind the whole wheel mesh to the appropriate wheel joint.
How you do this will depend on what modelling package you are using.

==== 3ds max ====
* Apply a ''Skin'' modifier to each of the meshes you want to export (the main body and each of the 4 wheels, for example).
* In the "Bones" list, click ''Add'', and choose the joint you want the selected mesh to be linked to.
** In this way, the main body of the vehicle should be linked to the ''origin'' joint.
** Additionally, each wheel should only be linked to its related wheel joint, not anything else.

==== Maya ====
* Bind your meshes to the relevant joints using the ''Smooth Bind'' option in the ''Skin'' menu.

=== '''Exporting''' ===
----
How you export your model and rig to ''.md5mesh'' and ''.md5anim'' files depends on what modelling package you are using.

==== 3ds max ====
* First of all you will need to get Jonathan "BeRSeRKeR" Garcia's maxscript MD5 Exporter, [http://www.modwiki.net/wiki/MD5_%28file_format%29#Tools which can be found here].
* Go to the ''Maxscript'' menu and select ''Run Script...'' then browse to the location you installed the MD5Exporter.mzp file.
* A new window should pop up, from here you should set these options:
** '''Base frame:''' 0
** '''Start frame:''' 1
** '''End frame:''' 1
** '''Nodes to export:''' Select all of the mesh parts you want to export. You don't need to select the joints, just the meshes (the main body and 4 wheels, for example).
** '''Export options''' should be set to ''Export both'' for now.
** Ignore the '''Camera''' rollout, this is not needed for a vehicle.
* Now click the '''Export''' button and choose a folder to save your MD5 files in - ''models/vehicles/gdf_buggy/buggy.md5mesh'' is where I'll put this file.
* Let the exporter work and save the file (this can take several seconds), soon it will prompt you for a path to save the ''.md5anim'' file - just use the same folder and name as before.

That's it, you should now have a working MD5 file that can be read by ETQW!

==== Maya ====
* See [[MD5 Export Process#The Export File|MD5 Export Process article]].

That's it, you should now have a working MD5 file that can be read by ETQW!

=== '''Related Files''' ===
----
* [[Media:buggy_tute_step1.max|Vehicle tutorial model and rig example (3ds max 8 format)]]
* [[Media:buggy_tute_step1.mb|Vehicle tutorial model and rig example (Maya 7 format)]]

== '''Getting It Into The Game''' ==
Now that you have a rough model and a simple rig you are ready to get the vehicle into the game.

=== Entity Definition ===
For your new vehicle to be spawned in the game it needs an <tt>entityDef</tt> describing it. Start out by creating a new file in the <tt>def/vehicles</tt> subdirectory of your mod. Create the directories if you don't have them already. For this tutorial I am calling the file <tt>buggy_tute.def</tt>.

The first thing needed is a model definition. This links together the model and any animations it may have into one named model to be referenced by the entity:
<tt>
model vehicle_buggy_tute {
mesh models/vehicles/gdf_buggy/buggy.md5mesh

anim base models/vehicles/gdf_buggy/buggy.md5anim
anim ik_pose models/vehicles/gdf_buggy/buggy.md5anim
anim initial models/vehicles/gdf_buggy/buggy.md5anim
anim idle models/vehicles/gdf_buggy/buggy.md5anim
}
</tt>

Now onto the <tt>entityDef</tt>. The name you choose for this is the name you will use to spawn the entity. I am using <tt>vehicle_buggy_tute</tt>:
<tt>
entityDef vehicle_buggy_tute {
</tt>

There are base definitions set up for vehicles in <tt>base/def/vehicles/base.def</tt>, so rather than re-defining all the parameters you might as well just inherit from them. I'm going to use <tt>vehicle_base_gdf</tt>:
<tt>
"inherit" "vehicle_base_gdf"
</tt>

There are a large number of key/value pairs that can be set to adjust vehicle behaviour, so for starters I'll describe the bare minimums.

{|border="1" cellpadding="4" cellspacing="0"
| style="background:#dfdfdf" | '''Key''' ||style="background:#dfdfdf"| '''Description'''
|-
| <tt>spawnclass</tt> || The code class to use - for most vehicles this should be set to <tt>sdVehicle_RigidBody</tt>
|-
| <tt>scriptObject</tt> || The script to use. The essentials are all defined in <tt>vehicle_base</tt>, so we don't need to make a new script just yet.
|-
| <tt>vs_vehicleScript</tt> || The vscript to point to. I'll make one of these later, called <tt>buggy_tute</tt>
|-
| <tt>model</tt> || The model definition to use. This should be the one we created above.
|-
| <tt>health</tt> || The amount of health the vehicle has. I'm using 400 to start with.
|-
| <tt>input_mode</tt> || The joystick input mode to use. This selects which set of input CVARs are used to used to translate joystick input to vehicle actions. In this case it should be <tt>car</tt>
|-
| <tt>vehicle_control</tt> || Selects the mode of vehicle control used - in this case it should be <tt>wheeled</tt>.
|-
| <tt>info_name</tt> || This points to a localized string to present to the player to name the vehicle. We can create one of these later, so for now I'll just use <tt>game/vec/husky</tt>
|-
| <tt>steering_angle</tt> || The maximum angle of steering. I'm using 40 to start with.
|-
| <tt>table_gearforces</tt> || This points to a table defining the amount of force applied at the wheels at each "gear" speed. I'll be making one of these later, called <tt>bugg_tute_gear_forcetable</tt>
|-
| <tt>table_gearspeeds</tt> || This points to a table defining the speeds at which "gear" forces are applied. I'll be making one of these later, called <tt>buggy_tute_gear_speedtable</tt>
|-
| <tt>overdrive_factor</tt> || The multiplier applied to the wheel speed & force when overdrive (boost) is being used. I'm using 1.5 to start with.
|-
| <tt>power_curve_scale</tt> || Adjusts the gear force between gears to act kind of like an engine's torque curve, to help the vehicle go up slopes or maintain speed when hitting a ramp. I'm using 2 to start with.
|}

A few other keys are needed to select some options:
<tt>
"option_combat_model" "1"
"option_selection_combat_model" "1"
"option_task_interface" "1"
</tt>

The first option sets up a combat model, which is used by bullets so they can hit the actual visible model. The second option sets it so it can be "selected" - this allows it to be locked onto by rockets etc. The final option allows the entity to have missions generated due to it being "spotted" by a radar. '''TODO: GORDON PLEASE CHECK THIS IS ACCURATE'''

This leaves us with a very simple, minimal vehicle entityDef. This does not use a lot of features, for example:
* Command map icon
* Collision damage
* Control context CVARs
* Vehicle HUD elements
* Engine sounds
* Climate-based skins
* Horn sounds
* Low health warning sounds
* Tooltip on entering vehicle
* Decoys

Many things (eg effects) will use the default values, which may not be the most suitable. Some other things won't function properly - for example bullets won't damage it yet. However, there is enough information in the entityDef to get us started.

The completed entityDef:
<tt>
entityDef vehicle_buggy_tute {
"inherit" "vehicle_base_gdf"

"option_combat_model" "1"
"option_selection_combat_model" "1"
"option_task_interface" "1"

"spawnclass" "sdVehicle_RigidBody"
"scriptObject" "vehicle_base"
"vs_vehicleScript" "buggy_tute"
"model" "vehicle_buggy_tute"

"input_mode" "car"
"vehicle_control" "wheeled"

"info_name" "game/vec/husky"
"health" "400"

"steering_angle" "40"

"table_gearforces" "buggy_tute_gear_forcetable"
"table_gearspeeds" "buggy_tute_gear_speedtable"

"overdrive_factor" "1.5"
"power_curve_scale" "2"
}
</tt>

=== '''Vehicle Script''' ===
----
The vehicle script file generally contains most of the information to define the behaviour of the vehicle.
Start out by making a directory in your mod's directory called <tt>vehicles</tt> and create a text file in there with the <tt>.vscript</tt> extension. I named mine <tt>buggy_tute.vscript</tt>.

Start out by making the definitions we pointed to in the entityDef. The gear speed table and the gear force table are simple and don't take too much explaining so I'll start with those. While ETQW does not use gears in the true sense of the word, it roughly represents the amount of force that the vehicle can apply at the wheels for various speeds, and the speed the vehicle will aim for. In a real-world vehicle the force the vehicle can drive with reduces with each gear, so we generally set up these tables to ramp down the force as the speed ramps up, but you can mess with these to achieve various effects (eg lots of torque at high speed). Here are the tables I'll start out with:

<tt>
table buggy_tute_gear_speedtable {
clamp

{
20, 30, 50, 80
}
}

table buggy_tute_gear_forcetable {
clamp

{
300000, 200000, 100000, 100000
}
}
</tt>

The <tt>clamp</tt> parameter means that it won't try to extrapolate beyond the range of the table when looking up values.

Now onto the <tt>vehicleDef</tt>. This does the bulk of the definition. First of all it needs to be named:
<tt>
vehicleDef "buggy_tute" {
</tt>

==== Collision Model ====
----
The vehicle needs some sort of physical representation in the world. I've decided that for my model it should weigh somewhere in between the Husky and the Armadillo, so I've chosen 2000kg. Give the vehicle a <tt>part</tt> to define the shape of it - you can measure your model in your modelling package to try to get the bounds perfect straight away, but I just added a part with a random size (<tt>"-100 -100 -100"</tt> & <tt>"100 100 100"</tt>) and then tuned the size in-game. To do this you can use the console to turn on <tt>g_showCollisionModels</tt> and to extend <tt>g_maxShowDistance</tt> - 1024 should be far enough. You can then spawn your vehicle by typing <tt>spawn vehicle_buggy_tute</tt> at the console (or whatever you named the entityDef). Enter <tt>killTransports</tt> to remove all the vehicles in the map, and <tt>reloadDecls</tt> to load the changes you've made to the definitions. By putting ETQW into windowed mode you can have the vehicle script open in another window, edit the sizing, pop back to ETQW, <tt>reloadDecls</tt> and spawn a new vehicle. This way you can rapidly tweak the size of the collision. Make the bottom of the collision end at the underside of the body - this gives it some clearance over the ground. A simple box collision model will be enough to start with, you can experiment with compound collision models later to get the size and shape to your liking.
This is what I ended up with:
<tt>
part {
"mins" "-96 -55 24"
"maxs" "78 55 94"
"mass" "2000"
"friction" "0.4 0.4 0.4"
}
</tt>

I also added some friction, so that if the vehicle flips over it doesn't slide forever.

==== Positions, Views, and Exits ====
----
If you spawn this vehicle in the game you'll notice that you can't get into it! This would be a bit of a problem even if it had wheels, so we had better set up a seat for our would-be-drivers. For this you'll need a <tt>positionDef</tt>. Here is the minimal <tt>positionDef</tt> I started with:

<tt>
positionDef {
data {
"joint_attach" "driver"
"show_player" "1"
"player_anim" "VehicleBadgerDriver"
}

view {
eyeJoint "cam1"
autoCenter

clamp pitch {
min -70
max 20
}

clamp yaw {
min -80
max 80
}
}

view {
eyeJoint "cam1"
type "smooth_locked"
thirdPerson
cameraDistance 240
cameraHeight 50
}
}
</tt>

This provides a very simple position. It attaches the player at the <tt>driver</tt> joint, shows the player, and uses the <tt>VehicleBadgerDriver</tt> animation state machine. It has two views - one is a first person view based on the <tt>cam1</tt> joint, which auto-centers. It has pitch and yaw clamps to keep the view within a reasonable range. The other view is a third person view based around the same joint, set back and up from the joint.
I haven't named the position or given it a stats name - these won't cause any problems just now, although a warning will be printed on the console. This is not a problem, as the stats only do anything in ranked matches. '''TODO: REMOVE THE WARNING?'''

If you spawn your vehicle now you will find that you can get in and look around, but you can't get out - we now need to add an <tt>exitDef</tt> (or multiple <tt>exitDef</tt>s) to give the player somewhere to get out of the vehicle. It will not allow the player to get out if there are no valid (unblocked) exits, so it is always a good idea to have several exits. In this case I have only one exit:

<tt>
exitDef {
joint "exit1"
}
</tt>

==== Wheels ====
----
Ok so now we have a vehicle that has physics, and you can get in and out of. Now we need to make it actually go places. In the case of a wheeled vehicle like this we'd obviously want, well, wheels! To start with I'm going to make all the wheels the same, with identical suspension parameters. Maintaining four copies of near-identical settings when tweaking is very error-prone, so I'm going to write a template to define all the common keys between all the four wheels, one for keys common between the front two wheels, and one for keys common between the rear two wheels. Using the parameters to the first template we can make it include the front/rear template too, and set up the names of the joints and surfaces to use. This makes it as simple as just using the template with appropriate front/rear & left/right parameters to define any one wheel.
Now, suspension tuning is tricky and can take a lot of fiddling to get it just right. I'll outline some of the methods I use when tuning a new vehicle's suspension, but you'll largely have to experiment to get things the way you like them.

Here is my starting point:
<tt>
template templates/vehicles/buggy_tute/wheel_behavior {
parameters< FrontBackParm, LeftRightParm >
text {
"name" "FrontBackParm LeftRightParm Wheel"
"surface1" "FrontBackParm_LeftRightParm_wheels"
"joint" "FrontBackParm_LeftRightParm_wheel"

"slowonLeftRightParm" "1"

"wheelSpinForceThreshhold" "75000"

"brakingForce" "250000"

"drive" "1"

"alternateSuspensionModel" "1"
"suspensionUpTrace" "8"
"suspensionDownTrace" "20"
"suspensionRange" "28"

"suspensionKCompress" "100000"
"suspensionDamping" "0"

"suspensionMaxRestVelocity" "3.5"

"maxSlip" "400"
"contactFriction" "0 0.7 0"

useTemplate templates/vehicles/buggy_tute/wheel_FrontBackParm< "LeftRightParm" >
}
}

template templates/vehicles/buggy_tute/wheel_front {
parameters< LeftRightParm >
text {
"turn" "1"

"radius" "18"
"footprint" "15"
}
}

template templates/vehicles/buggy_tute/wheel_rear {
parameters< LeftRightParm >
text {
"hasHandbrake" "1"

"radius" "20"
"footprint" "15"
}
}
</tt>

These templates must be defined outside of the <tt>vehicleDef</tt> - I placed them at the top of the file. Note how it uses the template parameters to construct the joint, surface, and part names. I've set this one up to use the alternate suspension model, which behaves like a simple linear spring & dampener system, as it is somewhat easier to tune and can provide very entertaining results. Its set up for four wheel drive, with the front wheels steering and the rear wheels handbraking. To use the template to create wheels add the following into the <tt>vehicleDef</tt>:

<tt>
wheel {
useTemplate templates/vehicles/buggy_tute/wheel_behavior< "front", "left" >
}

wheel {
useTemplate templates/vehicles/buggy_tute/wheel_behavior< "front", "right" >
}

wheel {
useTemplate templates/vehicles/buggy_tute/wheel_behavior< "rear", "left" >
}

wheel {
useTemplate templates/vehicles/buggy_tute/wheel_behavior< "rear", "right" >
}
</tt>

If you now spawn your vehicle it should be drive-able! No doubt it will bounce up and down chronically and drive strangely, but its a start.

===== Wheel Geometry =====
----
Firstly you'll want to adjust the amount of suspension travel there is. Start by deciding how far up from the wheel joint you want the bottom of wheel to be able to move, and set <tt>suspensionUpTrace</tt> to this. It is OK for this to be negative, if you modelled your vehicle with the wheels a long way down. This is basically the vertical offset from the joint's original position that the wheel can go up. Similarly, <tt>suspensionDownTrace</tt> is the vertical offset from the joint's original position that the wheel can go down. <tt>suspensionRange</tt> is the distance from the bottom of the movement range over which the suspension will operate - this allows the wheel to still move beyond its range, but the equations used to generate the forces will act as if it had reached the end of its <tt>suspensionRange</tt>. It is fine to start by setting this to <tt>suspensionUpTrace + suspensionDownTrace</tt>.

Next you should out the wheel's size - the <tt>radius</tt> and <tt>footprint</tt> values set this. <tt>radius</tt> is pretty self explanatory - its best to measure this one in your modelling package. <tt>footprint</tt> is the width of the wheel, which should again be measured in your modelling package. In the model I am using the front & rear wheels are different sizes, so I have configured mine to reflect this.

===== Suspension Tuning =====
----
We're almost ready to roughly tune the suspension's spring and dampening constants, but first I'll give a brief explanation of what effect these two have on the vehicle.

The spring compression coefficient, <tt>suspensionKCompress</tt>, causes a force to be applied that opposes the compression/extension of the suspension. The force is proportional to the amount of compression on the spring. Setting a small value for this will result in "squishy" suspension that allows a lot of vertical movement. Setting a large value will result in "stiff" suspension where only a small amount of movement is possible before large forces are applied.

The damping coefficient, <tt>suspensionDamping</tt>, causes a force to be applied that opposes the change in compression/extension of the suspension - ie the velocity of the suspension. The force is proportional to the rate of change of the spring's compression. Setting a small value for this will result in bouncy suspension that only slowly resists suspension movement, allowing oscillation to occur. Setting a large value will result in very static feeling suspension that rapidly resists suspension movement, quickly absorbing bumps. Too large a value can result in an "over-damped" situation where it will tend to drastically overcompensate - an example is a vehicle being dropped to the ground and it bouncing up higher than the height it fell from.

Low coefficient values will typically result in a very bouncy, "squishy" ride. This will tend to handle rough terrain well, without bumping and jostling the vehicle too much, but handle smooth terrain badly - bouncing and wobbling too much. High coefficient values will typically result in a very stiff ride, handling smooth terrain well but having a hard time over rough terrain, giving a bumpy and nasty ride.
Note that these are very general tips - there is no hard-and-fast rule, and you will need to experiment a lot to find values that satisfy you.

Given the above, I tend to start by making it handle the standing still case. I lower the damping coefficient to zero and spawn a vehicle on flat terrain to see how it sits. I adjust the compression coefficient until the vehicle's body tends to sit at about the height I had imagined. With the damping coefficient at zero it will tend to wobble indefinitely, so now I adjust the damping coefficient until it tends to stabilize after a few oscillations. I normally start with a small value, eg 100, and multiply by 10 until the oscillation disappears. Then I look for values in between that and the previous value until I'm satisfied. For my vehicle this ended up with <tt>suspensionKCompress</tt> being 300000, and <tt>suspensionKCompress</tt> being 15000.

I normally find that at this point the vehicle handles pretty decently. Not perfect, but good enough for this stage of development. Depending on the mass of your vehicle you will probably have to adjust the drive force in the force table to get a decent degree of acceleration.

==== Preventing it from rolling ====
----
If your vehicle is anything like mine, you'll probably find that it is all too easy to roll your shiny new car. If you turn on <tt>rb_showMass</tt> using the console you will see a yellow wireframe sphere somewhere in the middle of your vehicle - this shows where its center of mass (some call it the center of gravity) is. This is quite high, which makes it easier for the vehicle to roll over. There are a few ways to deal with this:
* Use a point mass to lower the center of mass to a more reasonable place
* Use several collision parts instead of just one, making the upper one lighter than the lower one - this represents the bulk of the mass of the vehicle being in the lower part of the vehicle (eg the engine, suspension, wheels, the driver, etc)
* Use an antiroll constraint

I like to use a combination of these methods. The disadvantage of lowering the center of gravity is that it allows less dynamic behaviour, like body rolling and pitching. This behaviour looks really cool, so its a shame to lose it. Antiroll constraints make the vehicle tend to resist rolling over too much. These are very easy to use, but they can look a bit artificial if they are made too obvious. With a bit of tweaking a good combination of the methods can usually be achieved.

This is the combination I settled on:
<tt>
part {
"mins" "-96 -55 60"
"maxs" "78 55 94"
"mass" "500"
"friction" "0.4 0.4 0.4"
}

part {
"mins" "-96 -55 24"
"maxs" "78 55 60"
"mass" "1500"
"friction" "0.4 0.4 0.4"
}

antiroll {
"angle_start" "5"
"angle_end" "30"
"strength" "2"
}
</tt>

==== Running people over ====
----
At the moment you can probably go prone and crawl under your vehicle, and running prone people over will not kill them. To solve this there is a part called a <tt>hurtZone</tt>. These are made much the same as a <tt>part</tt>, but they don't have a mass or friction - they just have a shape. They prevent players from moving through them, and they will cause collision damage to players in their way. Make this big enough to cover the underside of the vehicle.

Here is mine:
<tt>
hurtZone {
"mins" "-96 -55 0"
"maxs" "78 55 24"
}
</tt>

<noinclude>
'''[[Vehicle Tutorial Part 3|Click here to continue on to Part 3 of the Vehicle Tutorial]]'''
[[Category:Models]]
[[Category:Vehicles]]
[[Category:Tutorials]]</noinclude>

Vehicle Tutorial Part 1

2007-10-15T17:05:49Z

192.168.0.129:

First off you need a good design. Find some reference photos or drawings that feature elements of what you'd like to include in your vehicle. Then you can create a quick series of sketches and thumbnail drawings to get a decent idea of what overall shape and size your vehicle will be. You don't have to be an amazing artist, just draw a variety of small sketches which explore the design direction you want to go in.

[[Image:buggy_thumbnails.jpg|center|Vehicle design thumbnail sketches]]

=== Driving Considerations ===
It is important to design your vehicle so that it will function well. A vehicle may look really cool, but if it doesn't work well in-game then it's as good as not having a vehicle at all!
Here we'll discuss the things you should take into account when designing a wheeled vehicle. These vehicles are the most difficult to get to function well.

ETQW has a rather exaggerated vertical scale. Whilst this makes for some spectacular scenery and epic feeling, it also means that bumps and potholes in the roads can be enormous - let alone the bumps to tackle when you go offroad! There are often steep slopes that players may wish to traverse, or sharp corners they want to skid through at extremely high G. For these reasons your vehicle should have:
* As much ground clearance as possible (distance between the ground surface and the bottom of the vehicle). This helps prevent the vehicle "bottoming out" on the terrain and losing speed.
* Large suspension travel (distance the suspension can move from top to bottom). This will allow the suspension tuning to be softer, providing a less jarring and bouncy ride, as it has more distance to absorb the bumps in the surface.
* A wide track (distance between the two wheels of an axle). This will provide stability and help prevent the vehicle from tipping over.
* Short front overhang, or upward-slanted front end (for example, see the Trojan). This helps prevent the front end of the vehicle "digging in" to a sudden slope, sapping all of your speed.

<noinclude>
'''[[Vehicle Tutorial Part 2|Click here to continue on to Part 2 of the Vehicle Tutorial]]'''
[[Category:Vehicles]]
[[Category:Tutorials]]</noinclude>

Vehicle Tutorial

2007-10-15T17:05:36Z

192.168.0.129:

This is a step-by-step tutorial on how to model, rig, export and script a custom vehicle. It should cover absolutely everything you need to do to get most types of wheeled vehicle working in Enemy Territory: QUAKE Wars.
We will start out with the simplest form of vehicle and work from there to implement more complicated scripting and vehicle setup.
__NOEDITSECTION__
= Part 1: Design=
{{:Vehicle Tutorial Part 1}}

= Part 2: Rough Model and Basic Vehicle Setup =
{{:Vehicle Tutorial Part 2}}

= Part 3: More Advanced Scripting and Setup =
{{:Vehicle Tutorial Part 3}}

= Part 4: Advanced Scripting and Setup =
{{:Vehicle Tutorial Part 4}}

= Conclusion =
You should now have a good understanding of all the steps required to make a new vehicle for ET:QW from scratch.

[[Category:Animation]]
[[Category:Art]]
[[Category:Vehicles]]
[[Category:Tutorials]]

Main Page

2007-10-15T17:05:05Z

192.168.0.129: /* Making A Terrain Model */ fixed link

__NOTOC__= '''Tutorials''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Taking A Screenshot]] ===
|-
|
* '''[[Taking A Screenshot]]''' - Settings and options for making a great screenshot!
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Making a Terrain Model]] ===
|-
|
* '''[[Step 1]]''' - Create a terrain mesh for your map.
* More to go here, temp for now.
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |

=== [[Vehicle Tutorial]] ===
|-
|
* '''[[Step 1]]''' - Design considerations, before you do anything else!
* '''[[Step 2]]''' - Initial rough model, rig and basic script.
* '''[[Step 3]]''' - More advanced rig and scripting.
* '''[[Step 4]]''' - Further technical setup ideas.
|-
|}
|}

= '''Code''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Vehicle Scripting]] ===
|-
|
* '''[[Vehicle Scripting: Basic_Overview|Basic Overview]]''' - Introduction to vehicle setup.
* '''[[Vehicle Scripting: Entity_Definition|Entity Definition]]''' - One definition to rule them all!
* '''[[Vehicle Scripting: Vehicle_Definition|Vehicle Definition]]''' - Introduction to the ''.vscript'' file.
* '''[[Vehicle Scripting: Positions_&_Views|Positions & Views]]''' - Configuring player positions & camera views.
* '''[[Vehicle Scripting: Components|Components]]''' - Details of various vehicle components.
* '''[[Vehicle Scripting: Weapons|Weapons]]''' - Things that go boom!
* '''[[Vehicle Scripting: IK|IK]]''' - Inverse Kinematics & you...
* '''[[Vehicle Scripting: Cockpits|Cockpits]]''' - Cockpit setup.
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Entity Scripting]] ===
|-
|
* '''[[EntityClass:Overview|Classes]]''' - Tree of entity types.
* '''[[ScriptEvent:List|Events]]''' - List of all script events.
* '''[[Scripting:Examples|Examples]]''' - Some example walkthoughs of building up a scripted entity.
* '''[[Script:Files|Script Files]]''' - List of the script files used by the game.
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[GUIs]] ===
|-
|
* '''[[GUIs: Event Based Scripting|Event Based Scripting]]''' - GUIs are event-based.
* '''[[GUIs: Materials|Materials]]''' - Using materials in GUIs.
* '''[[GUIs: Transitions|Transitions]]''' - Transitions.
* '''[[GUIs: Templates|Templates]]''' - Using templates in GUIs.
* '''[[GUIs: List Enumeration|List Enumeration]]''' - List enumerations.
* '''[[GUIs: Properties|Properties]]''' - Player/Global properties and more.
* '''[[GUIs: Timelines|Timelines]]''' - GUI timelines.
* '''[[GUIs: Layouts|Layouts]]''' - Window layouts.
* '''[[Reference (GUIs)|Reference]]''' - GUI reference.
|-
|}
|}

= '''Design''' =

= '''Art''' =
{| width="100%"
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Models]] ===
|-
|
* '''[[In-Game Models]]''' - Making models for use in the engine.
* '''[[High-Poly Models]]''' - Making source models for baking normal maps.
* '''[[Renderbump]]''' - Create normal maps from high-poly geometry.
* '''[[Imposters]]''' - Sprites used for rendering complex models cheaply at a distance.
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Animation]] ===
|-
|
* '''[[MD5 Export Process]]''' - How to export an animated MD5.
* '''[[Vehicle Setup]]''' - How to set up a vehicle.
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Textures]] ===
|-
|
* '''[[Basic Texture Overview]]''' - Supported texture types and implementations.
* '''[[Texturesheets]]''' - Overview of what texturesheets are, and when to use them.
* '''[[The Atlas Editor]]''' - Create environment texture sheets to improve performance.
* '''[[RenderBumpFlat]]''' - Create normal-maps from high-poly geometry.
* '''[[Detail Textures]]''' - Add high-frequency detail to your textures.
|-
|}
| width="50%" valign="top" |
{| style="border: 1px solid #AAAAAA;" width="100%"
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Terrain Editing]] ===
|-
|
* '''[[Making a Terrain Model]]''' - Create a terrain mesh for your map.
* '''[[Terrain Editor|EditWorld's Terrain Editor]]''' - Set up a Surface Tree for your MegaTexture.
* '''[[MegaBuild]]''' - Render and compile your MegaTexture.
* '''[[Water Surfaces#Water Models|Water Surfaces]]''' - Create water to go with your landscape.
* '''[[STUFF System]]''' - Procedurally distribute models over your terrain mesh.
|-
| style="border-bottom: 1px solid #AAAAAA; background: #F9F9F9;" |
=== [[Atmospheres and Effects]] ===
|-
|
* '''[[Atmosphere Editor|The Atmosphere Editor]]''' - Create and edit atmospheres for your map.
* '''[[Ambient Light Editor|The Ambient Light Editor]]''' - Create and edit ambient light setups.
* '''[[Environment Maps]]''' - Used for reflection effects.
* '''[[Water Surfaces]]''' - Creating water effects.
* '''[[Effects Editor|The Effects Editor]]''' - Create and edit particle effects.
* '''[[Cheap Decals]]''' - Bulletholes and other collision decals.
|-
|}
|}

MD5 Export Process

2007-10-15T17:04:35Z

192.168.0.129:

Exporting animated models into the game is relatively pain free process but is easy to get wrong if not making sure it is done right. So, lets go through right from the start the most common eventualities you'll come across...

= Where To Start? =
=== Model Prepping in Maya ===
Start by taking the freshly made model into Maya. Once there, usually the best place to start is to 'separate' it into all the parts you think should be their own piece (eg. wheels, detachable components) or if you just think it will be easier to skin as a seperate piece of mesh.
Next you will want to assign your materials to the relevant pieces. The material is linked with a diffuse texture of the same name in the same path as the material name, for example the material for the GPMG is ''models/weapons/gdf_gpmg/gpmg_roler'', in Maya you would link the diffuse texture to a file in your ETQW folder, eg. ''/base/models/weapons/gdf_gpmg/gpmg_roler.tga''. This file doesn't have to be referenced in the game.

=== Begin the Rigging Process ===
Now you are ready to begin the rigging process. Add joints to all parts of the mesh you think will needed to deform the mesh nicely and also that you think might be needed to make the model functional in game, and that might be needed for scripting purposes.
These might include:
* An origin joint
* Exit points for vehicles
* Muzzle flash points for weapons
It is a good idea to name your joints (as with anything) at this point, so you or anyone else who has to deal with the model later knows what they are all for.

=== Joint Considerations ===
The main orientation you want for joints is the same as Maya. X = forwards, Z = right, Y = up This is important for joints that will be controlled by the gamecode, ie not just keyframe animated.

Also, for large models, make sure that any joint is never any more than 256 units away from its parent joint, as this can cause problems (If you have unkowingly done so you will get a warning anyway telling you which joint/s need fixing).

=== Bind Meshes to Joints ===
When you have your rig and the joints are all parented the way you want, you should now be ready to bind the mesh/es to the joints (use 'smooth bind' option). Once you have all the meshes weighted to your liking you are ready save the file and move on. ''Note: If any of the meshes or the groups they are in have any history (translations, mesh tweaks etc) make sure to freeze them then delete history.

=== Setting Up a Reference File ===
You won't want to animate in this file, it will be used as a reference file. Create a new Maya file and select File > Create Reference (click the options box for this menu). Under the section name 'Name Clash Options' make sure Use Namespaces is unchecked, and resolve 'all nodes' with 'this string' and in the box type a name that will be a prefix for everything in the reference file. For this example I would type GPMG and then click the reference box at bottom left of this window. This will bring up a file selection window where you select the reference file you made a moment ago. If this has worked, your reference file should be loaded into your new file, but now you will notice everything has the name you just set prefixing everything. Save this as a separate file (think of it as a child of the parent file). You can now animate in this and any subsequent files made from it safe in the knowledge you are not changing anything in your master reference file.

Also, should you need to make any core changes to the master file, such as adding new joints, reskinning or applying different materials for example, these changes will all be present in you child files. So, at this point, you should be ready to start animating the model. Well, go on then... :)

=== Animate! ===
Animate the model as usual in Maya. For those who are new to animation, The Animator’s Survival Kit by Richard Williams is a good place to start. There are also scores of tutorials on the Internet for Maya-specific animation techniques (eg. http://www.highend3d.com).

It is good practice, however, not to spend too long perfecting animations until you know they are working in game, so let's look at the export process that you should now be ready for and get the model into the game!

= The Export File =
Here's a quick example taken from the GPMG first person weapon export file (gpmg.def found in base/def/weapons):

export hauser {
options -prefix GPMG_ -sourcedir models/weapons/gdf_gpmg/dev_sd
-destdir models/weapons/gdf_gpmg/
-keep joint1 joint2 -keepmesh gpmg ammo_cover_lock gpmg_charge_handle

mesh gpmg_base_file.mb -dest view.md5mesh
anim gpmg_idle.mb -dest idle.md5anim -xyzprecision 0.001
anim gpmg_raise.mb -dest raise.md5anim
anim gpmg_lower.mb -dest lower.md5anim
anim gpmg_fire.mb -dest fire.md5anim
anim gpmg_reload.mb -dest reload.md5anim
anim gpmg_idle_zoom.mb -dest idle_zoom.md5anim
anim gpmg_fire_zoom.mb -dest fire_zoom.md5anim
anim gpmg_zoom_out.mb -dest zoom_out.md5anim
anim gpmg_zoom_in.mb -dest zoom_in.md5anim
anim gpmg_start_sprint.mb -dest start_sprint.md5anim
anim gpmg_leave_sprint.mb -dest leave_sprint.md5anim
}

The above example contains options most frequently used when exporting .md5’s:

* '''-prefix''' - When referencing the master file, Maya will ask for a prefix that will be added to the joint names. Specify that prefix here.
* '''-scale''' - You can tweak the scale of the model on export. This can be very handy if a designer decides they want something bigger but it has already been rigged and animated. It is of course better to rescale/rig/animate it in Maya if it is not much work, as it can end up being confusing otherwise.
* '''-align''' - This will align the specified Maya node and all of its children to face the proper direction.
* '''-keep''' - The engine will prune joints that have little or no skin weights attached to them. If such joints are necessary to keep in the .MD5, they must be specified here.
* '''-dest''' - Destination filename. Usage: ''-dest [filename]''

Some additional commands that may be useful:
* '''-rename''' - Renames joints. Usage: ''-rename [joint name] [new name]''
* '''-parent''' - Re-parents a joint. Usage: ''-parent [joint name] [new parent]''
* '''-range''' - Sets a frame range. Usage: ''-range [start frame] [end frame]''
* '''-cycleStart''' - Usage: ''-cycleStart [first frame of cycle]''
* '''-rotate''' - Usage: ''-rotate [yaw]''
* '''-nomesh'''
* '''-clearorigin'''
* '''-clearoriginaxis'''
* '''-ignorescale'''
* '''-xyzprecision''' - Usage: ''-xyzprecision [precision]''
* '''-quatprecision''' - Usage: ''-quatprecision [precision]''
* '''-jointthreshold''' - Usage: ''-jointthreshold [minimum joint weight]''
* '''-skipmesh''' - Usage: ''-skipmesh [name of mesh to skip]''
* '''-keepmesh''' - Usage: ''-keepmesh [name of mesh to keep]''
* '''-keepmeshprefix''' - Usage: ''-keepmeshprefix [prefix of mesh(es) to keep]''
* '''-jointgroup''' - Usage: ''-jointgroup [group name] [joint1] [joint2]...[joint n]''

= Time To Export =
Now you have your Maya files and ''.def'' file ready you can open up the game. For this example you would type the following into the console: '''exportmodels weapons/gpmg.def'''
* '''"exportmodels"''' can be used alone if you wish to export every single ''.def''.
* '''"reexportmodels"''' can be used to force a full export.

If everything has been set up properly you should see the engine run through executing all the export lines. If it shows up with any warnings you will need to assess whether it is something to do with the Maya files or the export file.

If you do get warnings or errors, the most common mistakes/things to check are:

* Spelling mistakes in the .def file.
* Too many, missing or inappropriate double braces.
* Wrong path indicated for where the files are.
* The Maya files' time stamps are checked against the the MD5 files. Maybe your date is incorrectly set, or you have only changed the reference file so the game dosen't check it and realise anything is worth exporting (in this case you should use '''reexportmodels''').
* Export name masks can be used, in this case we have set it to 'export hauser' as shown at the top of the export section above. In game if the 'g_exportmask' is set to anything other than "hauser" or "" (no mask exports all ''.def''s)then the export won't work.

= Viewing The Model In ETQW =
The game can't read an ''MD5mesh'' file without a matching ''MD5anim'' file. The only way for the game to know which ''MD5anim''s go with the ''MD5mesh'' is for us to define them in the ''.def'' file. Lets take a look at the GPMG model definition section.

model viewmodel_gpmg {
mesh models/weapons/gdf_gpmg/view.md5mesh

anim idle models/weapons/gdf_gpmg/idle.md5anim {
}

anim fire models/weapons/gdf_gpmg/fire.md5anim {
}

anim reload models/weapons/gdf_gpmg/reload.md5anim {
frame 1 sound_channel snd_weapon_reload snd_reload
}
anim raise models/weapons/gdf_gpmg/raise.md5anim {
frame 1 sound_channel snd_weapon_raise snd_raise
}

anim putaway models/weapons/gdf_gpmg/lower.md5anim {
}
}

* '''model <modelname>''' - the model name of the combined md5mesh and md5anims. This can be tested in the game using the '''testmodel''' console command, or can be referenced from other ''.def'' files.
* '''mesh <md5mesh path>''' - the path of the md5mesh you want to use (most likely you have just exported it).
* '''anim <animation name> <md5anim path>''' - once the model has been loaded, the animations can be played using the '''testanim''' console command.
** After each anim name definition there is a section for frame commands. In this example the reload and raise animations will play sound effects.

= Notes =
The MD5 files are in plain text, so if anything is going wrong you can open them in a text editor to try and see what's happening more clearly.

Example of a camera export def;
export frankie{
camera models/newcams/democam.mb -dest models/newcams/demovalley
}

[[Category:Art]]
[[Category:Animation]]

Category:Textures

2007-10-15T17:04:00Z

192.168.0.129:

Articles relating to texturing.

Texturesheets

2007-10-15T17:03:42Z

192.168.0.129: Fixed atlas editor links

Texturesheets are larger sheets of separate textures combined into a single image to reduce draw calls and improve performance. Texturesheets can easily be created and controlled using [[the Atlas Editor]].<includeonly>

{{main|Texturesheets}}</includeonly><noinclude>
__NOEDITSECTION__
= Texturesheet Example =
[[image:texturesheet_example_d.jpg|right|thumb|An example of a texturesheet (Click for full-size)]]
On the right you can see an example of a 256x1024 pixel texturesheet. Note that the borders of each texture fall on 32-pixel grid lines, for ease of applying to brushwork in a level.

= Texturesheet Considerations =
The aim of using texturesheets is to improve performance by reducing batches. If you have a single building textured with 4 regular tiling textures, the building will be drawn using at least 4 batches (one per material used). Therefore it makes sense to try and compile all of those textures onto a single sheet, which should mean the whole building will be drawn with 1 batch, leading to faster rendering.

One of the downsides of texturesheets is that you can only tile the textures on a single axis. A regular tiling concrete texture could be tiled indefinitely across a brush or model, while the same texture included in a texturesheet could only be tiled on one axis. The solution then is to split up geometry and apply the same texture to each set of faces. This will still result in a single batch.

To this end, it is worth considering before you texture a level, which textures it's better to use in a texturesheet, and which it is better to leave as a tiling texture. If you have areas of the level which require textures tiling a lot in both X and Y direction, it's probably better to leave these as square tiling textures (for example, floors and ceilings, or large expanses of concrete and stone), but for more specific detail like the walls of houses, pavements and brushwork with lots of trims, it's definitely advantageous to set up a good texturesheet before you texture the level.

= Creating Texturesheets =
The easiest way to create a texture sheet is to piece together existing tiling textures in [[the Atlas Editor]].

However, if you plan it well, you could create one large texture which contains several different surface types (wood, concrete, brick, metal) in a manner that makes sense, so that the texturesheet can be used as efficiently as possible. This way, the textures would all "make sense" when viewed as a whole, yet still be able to be used as trims or surfaces on their own.

[[Category:Art]] [[Category:Textures]] [[Category:Level Design]]
</noinclude>

Texturesheets

2007-10-15T17:03:25Z

192.168.0.129:

Texturesheets are larger sheets of separate textures combined into a single image to reduce draw calls and improve performance. Texturesheets can easily be created and controlled using [[the Atlas Editor]].<includeonly>

{{main|Texturesheets}}</includeonly><noinclude>
__NOEDITSECTION__
= Texturesheet Example =
[[image:texturesheet_example_d.jpg|right|thumb|An example of a texturesheet (Click for full-size)]]
On the right you can see an example of a 256x1024 pixel texturesheet. Note that the borders of each texture fall on 32-pixel grid lines, for ease of applying to brushwork in a level.

= Texturesheet Considerations =
The aim of using texturesheets is to improve performance by reducing batches. If you have a single building textured with 4 regular tiling textures, the building will be drawn using at least 4 batches (one per material used). Therefore it makes sense to try and compile all of those textures onto a single sheet, which should mean the whole building will be drawn with 1 batch, leading to faster rendering.

One of the downsides of texturesheets is that you can only tile the textures on a single axis. A regular tiling concrete texture could be tiled indefinitely across a brush or model, while the same texture included in a texturesheet could only be tiled on one axis. The solution then is to split up geometry and apply the same texture to each set of faces. This will still result in a single batch.

To this end, it is worth considering before you texture a level, which textures it's better to use in a texturesheet, and which it is better to leave as a tiling texture. If you have areas of the level which require textures tiling a lot in both X and Y direction, it's probably better to leave these as square tiling textures (for example, floors and ceilings, or large expanses of concrete and stone), but for more specific detail like the walls of houses, pavements and brushwork with lots of trims, it's definitely advantageous to set up a good texturesheet before you texture the level.

= Creating Texturesheets =
The easiest way to create a texture sheet is to piece together existing tiling textures in the [[Atlas Editor]].

However, if you plan it well, you could create one large texture which contains several different surface types (wood, concrete, brick, metal) in a manner that makes sense, so that the texturesheet can be used as efficiently as possible. This way, the textures would all "make sense" when viewed as a whole, yet still be able to be used as trims or surfaces on their own.

[[Category:Art]] [[Category:Textures]] [[Category:Level Design]]
</noinclude>

Textures

2007-10-15T17:02:58Z

192.168.0.129:

== Basic Texture Overview ==
{{:Basic Texture Overview}}

== Texturesheets ==
{{:Texturesheets}}

== The Atlas Editor (editSheets) ==
{{:The Atlas Editor}}

== RenderBumpFlat ==
RenderBumpFlat is a console command that generates normal maps from generally flat 3D models, and is usually used to create normal maps for tiling environment textures.

{{main|RenderBumpFlat}}

== Detail Textures ==
{{:Detail Textures}}

== Picmip & Related Issues ==
Picmip is a method of loading only lower mip-map levels, to save memory at runtime.

[[Category:Art]]

Textures

2007-10-15T17:02:15Z

192.168.0.129:

== Basic Texture Overview ==
{{:Basic Texture Overview}}

== Texturesheets ==
{{:Texturesheets}}

== The Atlas Editor (editSheets) ==
{{:Atlas Editor}}

== RenderBumpFlat ==
RenderBumpFlat is a console command that generates normal maps from generally flat 3D models, and is usually used to create normal maps for tiling environment textures.

{{main|RenderBumpFlat}}

== Detail Textures ==
{{:Detail Textures}}

== Picmip & Related Issues ==
Picmip is a method of loading only lower mip-map levels, to save memory at runtime.

[[Category:Art]]

Special Map Types

2007-10-15T17:01:11Z

192.168.0.129:

__NOEDITSECTION__
=== Glow Maps ===
[[Image:glow_map.jpg|right|frame|An example of a glow map.]]
Glow maps, also known as self-illumination maps, are used to make surfaces appear like they are emitting light.<includeonly>

{{main|Special Map Types}}</includeonly><noinclude>

[[Category:Art]] [[Category:Textures]]
</noinclude>

Specular Maps

2007-10-15T17:00:49Z

192.168.0.129:

[[Image:door_spec.jpg|right|frame|A specular map of a door.]]
Specular maps are the maps you use to define a surface's shininess and highlight colour.

The higher the value of a pixel (from black to white), the shinier the surface will appear in-game. Therefore, surfaces such as dry stone or cotton fabric would tend to have a very dark specular map, while surfaces like polished chrome or plastic would tend to have lighter specular maps.

The colour of a pixel is also used, to calculate the resulting colour of the surface. A very saturated specular map will have a very different visual effect than a grey specular map. If you need a more "neutral" highlight on a surface, your specular map should use the inverse of the diffuse map's colour. Using the same colour on the specular as on the diffuse will result in a more saturated highlight when viewed in the game.<includeonly>

{{main|Specular Maps}}</includeonly><noinclude>

You can use contrasts in specular to make a surface appear more visually interesting in the game - for example, this door has a very dark specular for the wood while the metal parts are much lighter, which will make the metal stand out more as a shinier surface when light hits it. This sort of contrast can help make surfaces in the game appear more realistic too.

[[Category:Art]] [[Category:Textures]]
</noinclude>

Bump Maps

2007-10-15T17:00:03Z

192.168.0.129:

[[Image:door_local.jpg|right|frame|A local map of a door.]]
Virtually all geometric surface detail should be represented in bump maps instead of drawn into the diffuse maps in the conventional style. This allows a single texture to take on different characteristics based on its interaction with lights.

Ideally, local (or tangent-space) normal maps should be generated from high-poly geometry for the best consistency and surface detail. However, it is often necessary to create normal maps from source photography and textures. This can be done in Photoshop by using the [http://developer.nvidia.com/object/photoshop_dds_plugins.html NVidia Tools NormalMap Filter], or using a 3rd-party application such as [http://www.crazybump.com/ Crazybump].

Two types of images can be used for bump mapping in ETQW; height maps and normal maps.<includeonly>

{{main|Bump Maps}}</includeonly><noinclude>__NOEDITSECTION__

== Height Maps ==
[[Image:rock_01_h.jpg|right|thumb|A greyscale height map for a tiling rock texture.]]
A height map is a gray scale image, with black being the farthest distance away and white being the closest. An addition scale parameter is required when using height maps to determine how deep the image is supposed to be. You can’t properly cut and paste image fragments between height maps with different scale values without distorting the shading. You can add, subtract, airbrush, or smooth gray values by hand on a height map with predictable results.

== Local Normal Maps ==
[[Image:rock_01_local.jpg|right|thumb|An RGB local normal-map for a tiling rock texture.]]
A local normal map encodes the actual perturbation angle of the surface at each point in the RGB color, so it is complete by itself without any scaling parameters. You can cut and paste between any normal maps without problems, but you can’t reasonably modify the angles of normal map surfaces by hand, or create one from scratch. Smoothing a normal map works reasonably well in practice, although it does result in denormalized pixel values.

The normal vector is encoded as ( ( R-128 ) / 128, ( G-128 ) / 128, ( B-128 ) / 128 ), so a normal pointing straight up ( 0, 0, 1 ) would be encoded as ( 128, 128, 255 ) in the image. Most local normal maps will be primarily bluish, because most of the vectors will be pointing up more strongly than any other direction.

[[Renderbump]] is also capable of generating "global normal maps", which encode an absolute direction in object space, instead of in local surface space, but global maps cannot be deformed or used on different wall orientations in the same object. They have some minor quality and performance benefits.

Height maps must be converted to normal maps at load time, so it is usually superior to use normal maps unless you need to manually create or manipulate the image in a way that is easier with height maps.

You can’t make a perfectly smooth slope in a height map because of the limited precision in the gray scale image. This results in shaded streaks along the slope, especially with higher resolution height maps. You may be able to hide that by adding some waviness to the surface manually.

== Using Bump Maps ==

Every surface that interacts with light will have a normal map.If one isn’t specified, it will default to "_flat", an internally generated normal map with no changes. There is currently no speed benefit to not having a normal map, although it might be possible to add a fast path for that in the future.

Most materials can be specified in the "shortcut" form, where you specify the diffusemap, specularmap, and bumpmap, and let the engine generate the full stages for it.

material textures/cc/techpanel
{
diffusemap textures/cc/techpanel_d.tga
specularmap textures/cc/techpanel_s.tga
bumpmap textures/cc/techpanel_local.tga
}

If diffusemap is not specified, it defaults to a solid white image. If specularmap is not specified, specular lighting will be disabled for that surface, giving a speedup.

You can modify the lighting calculations to examine the bump mapping under different conditions:

'''r_skipSpecular <0/1>'''

'''r_skipDiffuse <0/1/2>'''

== Renderbump ==
{{:Renderbump}}

== Editing Normal Maps ==
{{:Editing Normal Maps}}

[[Category:Art]] [[Category:Textures]]
</noinclude>

Diffuse Maps

2007-10-15T16:59:41Z

192.168.0.129:

[[Image:door_diff.jpg|right|frame|A diffuse map of a door.]]
A diffuse map is a texture you use to define a surface's main colour.

In order to work well with a normal map and a specular map, a good diffuse texture should not have any directional lighting included, it should only have generic "ambient occlusion" - ie. the surface gets darker in deep cracks and around embossed details. If you are generating your normal maps from high-poly geometry, you should bake a matching ambient occlusion pass from the geometry and multiply this on top of your diffuse texture to make sure that the lighting matches the normal map.<includeonly>

{{main|Diffuse Maps}}</includeonly><noinclude>

[[Category:Art]] [[Category:Textures]]
</noinclude>

Basic Texture Overview

2007-10-15T16:59:30Z

192.168.0.129:

Generic texture info here.

== Diffuse Maps ==
{{:Diffuse Maps}}

== Local Normal Maps ==
{{:Bump Maps}}

== Specular Maps ==
{{:Specular Maps}}

== Special Map Types ==
{{:Special Map Types}}

<noinclude>[[Category:Art]][[Category:Textures]]</noinclude>

Texturesheets

2007-10-15T16:58:55Z

192.168.0.129:

Texturesheets are larger sheets of separate textures combined into a single image to reduce draw calls and improve performance. Texturesheets can easily be created and controlled using the [[Atlas Editor]].<includeonly>

{{main|Texturesheets}}</includeonly><noinclude>
__NOEDITSECTION__
= Texturesheet Example =
[[image:texturesheet_example_d.jpg|right|thumb|An example of a texturesheet (Click for full-size)]]
On the right you can see an example of a 256x1024 pixel texturesheet. Note that the borders of each texture fall on 32-pixel grid lines, for ease of applying to brushwork in a level.

= Texturesheet Considerations =
The aim of using texturesheets is to improve performance by reducing batches. If you have a single building textured with 4 regular tiling textures, the building will be drawn using at least 4 batches (one per material used). Therefore it makes sense to try and compile all of those textures onto a single sheet, which should mean the whole building will be drawn with 1 batch, leading to faster rendering.

One of the downsides of texturesheets is that you can only tile the textures on a single axis. A regular tiling concrete texture could be tiled indefinitely across a brush or model, while the same texture included in a texturesheet could only be tiled on one axis. The solution then is to split up geometry and apply the same texture to each set of faces. This will still result in a single batch.

To this end, it is worth considering before you texture a level, which textures it's better to use in a texturesheet, and which it is better to leave as a tiling texture. If you have areas of the level which require textures tiling a lot in both X and Y direction, it's probably better to leave these as square tiling textures (for example, floors and ceilings, or large expanses of concrete and stone), but for more specific detail like the walls of houses, pavements and brushwork with lots of trims, it's definitely advantageous to set up a good texturesheet before you texture the level.

= Creating Texturesheets =
The easiest way to create a texture sheet is to piece together existing tiling textures in the [[Atlas Editor]].

However, if you plan it well, you could create one large texture which contains several different surface types (wood, concrete, brick, metal) in a manner that makes sense, so that the texturesheet can be used as efficiently as possible. This way, the textures would all "make sense" when viewed as a whole, yet still be able to be used as trims or surfaces on their own.

[[Category:Art]] [[Category:Textures]] [[Category:Level Design]]
</noinclude>

The Atlas Editor

2007-10-15T16:58:45Z

192.168.0.129:

The Atlas Editor (editSheets) is used to group multiple source textures together into one larger texture, known as a [[Texturesheets|texture sheet]]. This texture sheet can then be used for multiple models, allowing them to share a single large texture and reducing the overall number of batches sent to the graphics card.

The Atlas Editor solves the problem of having to manually update the atlas map whenever one of its source maps is changed. A recompile of the atlas map is all that is necessary to incorporate any source map changes. It also lets you draw out areas of specific surface types, and automatically outputs these areas for the game to load.<includeonly>

{{main|Atlas Editor}}</includeonly><noinclude>
__NOEDITSECTION__
= Overview =
The Atlas Editor can be started from the console with the '''editSheets''' command.
The atlas source used to compile the atlas map is stored as a ''.atlas'' file in the folder ''base/atlas''.

= Terms =
* '''Atlas Map''' - This is the large texture sheet that is a combination of several smaller textures, known as
* '''Source Maps''' - Tiling textures that are generally used on brush-based world geometry.
* '''SurfaceType Map''' - This is a way to specify material types within a texture. These allow for more accurate vehicle physics, sound and particle effects.

= Using The Atlas Editor =
Most of the commands are available in the menu along with shortcut keys. The mouse interface is as follows:

==Editing==
* '''Left-click/drag''' - Move the current selection around the grid.
* '''Shift-left click''' - Select the item currently under the cursor.
* '''Alt-left click/drag''' - Marquee-select points.
* '''Ctrl-left click/drag''' - Slice any shapes that the slice line crosses. This only affects Surface Type areas; images will not be affected.
* '''Enter''' - Creates a new image source. Also available by pressing the [[Image:editsheets_icon_new_image.png|New Image]] icon.
* '''Ctrl+Enter''' - Creates a new Surface Type area. Also available by pressing the [[Image:editsheets_icon_new_surfacetype.png|New Surface Type]] icon.

===The Grid===
The Atlas Editor uses a grid system for snapping the edges of textures and surfacetype areas. You can change the grid density by choosing one of the ''Units'' values in the ''Grid'' menu of the Atlas Editor, or by pressing the hotkeys '''1 - 6''' (smallest to largest grid sizes). The default grid size is 4 units; setting this value higher will result in more obvious and easy snapping of large components. Setting this value lower will allow more precise editing, if needed.

==Viewing==
* '''Right click/drag''' - Pan the image around within the viewport.
* '''Mouse wheel up/down''' - Zoom in and out.

==Preferences==
* Selecting ''Edit -> Preferences'' will bring up the option to Close Engine on Exit. If left un-checked, this can be useful to go back to the game once you have finished editing your texture sheets.

==Document Properties==
Pressing '''ALT+Enter''' or clicking the [[Image:editsheets_icon_document_properties.png|Document]] icon will open the Document Properties in the Property Editor.

[[Image:editsheets_document_properties.png|right|editSheets' Document Properties window]]

===Display===
* '''Grid Background''' - The background colour of the texturesheet preview window.
* '''Grid Major''' - The colour of major grid lines in the preview window.
* '''Grid Minor''' - The colour of minor grid lines in the preview window.
* '''Grid Text''' - The colour of text displayed in the preview window.

===Document===
* '''Output Dimension''' - The horizontal and vertical size in pixels of the texturesheet (defaults to 1024x1024).
* '''Output File''' - The base name of the texturesheet and surfaceType map.

===Image Output===
* '''Alpha''' - Outputs an alpha channel with your texturesheet's diffuse map. This is on by default, remember to disable it if your texturesheet doesn't require any transparency, otherwise your texturesheet will use more memory in game than necessary.
* '''Diffuse''' - Outputs a diffuse map to the path specified in the Output File field, with appended ''_d.tga''.
* '''Heightmap''' - Outputs a height map to the path specified in the Output File field, with appended ''_h.tga''.
* '''Local''' - Outputs a local normal map to the path specified in the Output File field, with appended ''_local.tga''.
* '''Specular''' - Outputs a specular map to the path specified in the Output File field, with appended ''_s.tga''.

==Image Properties==
Selecting an Image rectangle in the preview window will bring up the Image Properties for the selected texture.

[[Image:editsheets_image_properties.png|right|editSheets' Image Properties window]]

===Object===
* '''Diffuse Image''' - Path to the diffuse source texture, relative to the game's base path. Alpha channels in the diffuse texture will be honoured if the "Alpha" image output type is enabled in Document Properties (see above).
* '''Heightmap Image''' - Path to a heightmap source texture, relative to the game's base path.
* '''Local Image''' - Path to a local normal-map source texture, relative to the game's base path.
* '''Specular Image''' - Path to a specular source texture, relative to the game's base path.
* '''Surface Type''' - This determines the particles, sound and physics effects produced when things in the game collide with this surface. You can find a [[Surface Types|full list of valid Surface Types here]].
* '''Surface Type Color''' - The colour tint of particles produced when colliding with this surface. This will only be used if the particle effects are set up in such a way that allows tinting.

=====Notes=====
* File type extensions can be specified, but are not required. References to ''textures/concrete01_d'' and ''textures/concrete01_d.tga'' will both produce the same effect.
* The Atlas Editor will automatically look for heightmap, local and specular images that match the path provided in the '''Diffuse Image''' section. For example, if ''textures/concrete_d'' is specified, ''textures/concrete_h.tga'', ''textures/concrete_local.tga'' and ''textures/concrete_s.tga'' will automatically be used if they exist, unless different textures are explicitly specified in each field.

===View===
* '''Sort''' - This value is used to determine where the selected item will draw. A texture with a sort of "1" will always draw on top of a texture with a sort of "0", if the textures overlap.

==Surface Type Properties==
Selecting a Surface Type area in the preview window will bring up the Surface Type Properties for the selected area.

[[Image:editsheets_surfacetype_properties.png|right|editSheets' Surface Type Properties window]]

===Object===
* '''Surface Type''' - This denotes the type of physics, sounds and particle effects produced when interacting with the surface in-game. You can find a [[Surface Types|full list of valid Surface Types here]].
* '''Surface Type Color''' - The colour tint of particles produced when colliding with this surface. This will only be used if the particle effects are set up in such a way that allows tinting.

===View===
* '''Sort''' - This value is used to determine where the selected item will draw. A Surface Type with a sort of "1" will override a Surface Type with a sort of "0", if their areas overlap.

==Compiling==
When you want to bake your source maps down to a texturesheet, either choose ''Tools -> Compile'', press '''F5''', or press the [[Image:editsheets_icon_compile_all.png|Compile]] icon. This will generate a full set of atlas textures and a matching surface type map, or remind you to choose a base name for your map if one is not already defined.

If you want to regenerate the surface types without overwriting the textures themselves, either choose ''Tools -> Compile SurfaceTypes'', press '''CTRL+F5''', or press the [[Image:editsheets_icon_compile_surfacetypes.png|Compile SurfaceTypes]] icon.

If your atlas map's base name is "texturesheets/example", a compile with default settings will produce the following files:

base/texturesheets/example_d.tga
base/texturesheets/example_local.tga
base/texturesheets/example_s.tga
base/surfacetypes/texturesheets/example.stm

To use this sample atlas map you would create the following material:

material textures/example
{
surfaceTypeMap "texturesheets/example"
diffusemap texturesheets/example_d.tga
bumpmap texturesheets/example_local.tga
specularmap texturesheets/example_s.tga
}

[[Category:Art]]
[[Category:Textures]]
[[Category:Level Design]]
</noinclude>

RenderBumpFlat

2007-10-15T16:58:20Z

192.168.0.129:

This version of [[renderBump]] generates normal maps suitable for mapping on surfaces like standard textures. The model file should contain geometry which forms a generally 2D surface. The model file does not need to have texture coordinates, but you should save it with normals if you don’t want the entire thing to be smooth shaded.
The generated normal map will be saved to "<modelFile>_local.tga". To use the following command should be run in the console:

RenderBumpFlat [OPTION] modelFile

Options
-size <width> <height>
-heightmap
-floatHeightmap

* '''-size''' sets output resolution, (defaults to 256 by 256 if not specified).
* '''-heightmap''' writes out a grayscale heightmap TGA.
* '''-floatHeightmap''' writes out a 32-bit floating point RAW heightmap file (more accurate than a TGA).

For example, to render a 1024x1024 normal map, you would use this command:
'''renderbumpFlat -size 1024 1024 models/mymodel.lwo'''
This would output to ''ETQW base folder/models/mymodel_local.tga''

=====Notes=====
* In Lightwave the Back viewport (XY) is the direction of the renderbump traces.
* In Max it is the Front viewport (pointing in negative Y)
* RenderBumpFlat supports the ability to render at higher resolutions then you would normally be limited to through your screen resolution, so 2048x2048 or 4096x4096 are now possible (depending on video card).
* RenderBumpFlat automatically performs 16x oversampling, so the resulting image should be sufficiently anti-aliased, it also generates a color map by default.

<noinclude>[[Category:Art]] [[Category:Textures]]</noinclude>

Renderbump

2007-10-15T16:57:57Z

192.168.0.129:

The RenderBump tools generate normal maps directly from detailed polygonal geometry.<includeonly>

{{main|Renderbump}}</includeonly><noinclude>

There are two forms, both integrated into the main ETQW executable. These are RenderBump, used for baking high-poly geometry to low-poly UVW-mapped models, and RenderBumpFlat, used for creating normal maps from high-poly geometry with an overall flat surface (such as a tiling environment texture).

== RenderBump ==

This command generates normal maps for arbitrary geometry such as characters or vehicles, not just flat surfaces.

=== Console Commands ===
Renderbump command line parameters typed in at the console:

renderBump [OPTION] <lowPolyModel>

Options
-threads <1-10>
-drawNormals
-overDrawMap
-hashBinsPerAxis <8,16,32,64,128>

The "renderBump" console command is used to generate a normal map for a non-flat surface like the surface of a character model in the game.

'''<lowPolyModel>''' should be the path to the low-detail polygonal model for which the normal maps should be generated.

Optionally the number of threads used by for generating the normal map(s) can be specified after the low detail model. The default number of threads is 2 for use on a dual processor or Hyper Threaded system. Generally the number of threads can be set to the number of logical processors in the system. For instance if the system has two Hyper Threaded processors the number of threads can be set to 4.

'''-drawNormals''' can be used to draw the normal mapped triangles as they are calculated during the renderbump process instead of the simple progress bar. Note however that drawing the normal mapped triangles is slower and increases the total renderbump time.

'''-overDrawMap''' can be used to output an overdraw map, see below for a more detailed description.

A uniform hash grid is used to speed up the renderbump process. For models with many millions of triangles this hash grid may consume a significant amount of memory causing renderbump to run out of memory at load time. The size of the hash grid may be reduced by specifying the number of hash bins per 3D axis with the -hashBinsPerAxis option. The number of hash bins per axis must be a power of two and can be set to 8, 16, 32, 64, 128 or 256. The number of hash bins per axis defaults to 128. Using less hash bins per axis may reduce performance. However, if the smaller hash grid consumes significantly less memory performance may actually improve.

=== Material Options ===

The parameters for renderBump are specified on a per-material basis. When the "renderBump" command is launched, renderBump will analyse the specified low-poly model and take parameters from the materials applied to the surfaces of the low-poly model.

RenderBump [OPTION] <outputLocalMap> <highPolyModel>

Options
-size <width> <height>
-aa <0/1/2>
-trace <0.01 - 1.00>
-renderTriNormals
-perfectMirror
-clampTextureSpace
-drawNormals
-outline <width>
-globalMap
-colorMap
-overdrawMap
-clampOutput <xmin> <ymin> <xmax> <ymax>

'''-size''' The '-size' option followed by a width and height specifies the size of the normal map. The default size is 512 x 512.

'''-aa''' The '-aa' option specifies the level of anti-aliasing to be used on the normal map. 0 = 1x, 1 = 4x, 2 = 16x. The default setting is 4x anti-aliasing.

'''-trace''' The trace setting determines how far off of the low poly surface a ray cast will look for triangles in the high poly surface. It is expressed in fractions of the largest bounding axis of the high poly model. The default setting is 0.05

'''-renderTriNormals''' LWO models without smoothed vertex normals across the triangle surface consume a lot of memory because all vertices will be unique (they have a unique combination of position and normal vector). Models without smoothed vertex normals use unique vertices for each triangle where the vertex normals for one triangle are the same as the triangle normal. As such renderbump really renders triangle normals and not interpolated vertex normals. The '-renderTriNormals' option forces renderbump to render high poly surface triangle normals to the normal map instead of interpolated vertex normals. This allows loading an LWO '''with''' smoothed vertex normals, which consumes significantly less memory, while still rendering the LWO as if it does '''not''' have smoothed vertex normals.

'''-perfectMirror''' Some models have 2X triangles and the second X triangles are the exact mirror of the first X triangles. If the texture is also mirrored onto the model the -perfectMirror option can be used to only render the first X triangles to the normal map. This does not only save time but it also makes sure that the normal map is rendered from only one side of the model. Most noticeable is that the global map will be properly rendered for one side of the model.

'''-clampTextureSpace''' If the option '-clampTextureSpace' is used only low polygonal model triangles that map to the [0,1] texture space are sampled to calculate the normal map.

'''-drawNormals''' Draw the normal mapped triangles onscreen as they are calculated during the renderbump process.

'''-outline''' The normals at the edges of areas in the normal map that map to geometry are duplicated outwards to areas that do not directly map to geometry. The '-outline' option followed by a number specifies the number of normals that are duplicated outwards. The default setting is 8.

'''-globalMap''' If the '-globalMap' option is used a <outputLocalMap>_global.tga is written with normals in global model space (not surface space)

'''-colorMap''' If the '-colorMap' option is used a <outputLocalMap>_color.tga is written with sampled vertex colors.

'''-overdrawMap''' When multiple triangles of the low polygonal model map to the same texture space, these triangles may be rendered in any order by renderbump. Based on the order in which these triangles are rendered the normal map may be different. To get a consistent result from renderbump it is important to avoid such overdraw. When the model is mirrored the -perfectMirror option may be used to avoid overdraw. If individual triangles cause overdraw these triangles should be mapped to outside the [0,1] texture space by adding 1 to the texture coordinates and the option '-clampTextureSpace' should be used. If the '-overdrawMap' option is used a <outputLocalMap>_overdraw.tga is written which shows the renderbump overdraw. In this image the texture space used by triangles is drawn in white and all overdraw is drawn in red.

'''-clampOutput''' Stops renderbump from wrapping texture coordinates around back into the 0 - 1 range. For example, if you have a model that has a texture coordinate max at ( 1.5, 1.50 ) and you specify "-clampOutput 0 0 1 1" (ie, a normal range) anything past ( 1, 1 ) will be thrown away and won't be seen on the final output. This can be handy for renderbumping only a certain part of a terrain mesh, for example.

=== Notes ===
* As a result of the multithreading, renderbump is really sensitive to UV re-use. Make sure there only ever is one UV triangle stacked on a single pixel in the 0,0 to 1,1 space. Anything that re-uses data, move it outside of the region by an offset of 1 (let's standardise by an offset of 1 to the right). Then when renderbumping, use clamped output.
* The tangent space during renderbumping has to be identical to the one in game, do not split meshes in case of mirroring and remove half of the data. This will cause smoothing to be different during renderbumping and give visual artifacts.
* Use the shortest trace distance you can away with without getting renderbump errors. The trace setting determines how far off of the low poly surface that a ray cast will look for triangles in the high poly surface. It is expressed in fractions of the largest bounding axis. Tracing speed goes down rapidly as this is increased, but if your high poly geometry isn’t showing up in the normal map, you may need to increase this to 0.1 or more. The best solution is to try very hard to have the low poly version be a very close match to the high poly version.
* The lowPolyModel must have texture coordinates on it, and care should be taken to make sure the mapping is as good as possible. Before doing a RenderBump, test the model in the game with '''r_showTexturePolarity 1''' and '''r_showEdges 1'''. Make sure that there aren’t any texture seams that aren’t absolutely necessary, and that there are no overlapped texture projections.
* The alpha channel of the normal map will contain a mask if there were areas in the map that did not directly map to geometry. This can be copied to a diffuse map to use with the alphatest material option for per-pixel opacity.
* If you use the normal map as a template for the specular map, you should explicitly clear or remove the alpha channel, because it will prevent more efficient texture compression from being used.
* The generated image will be saved relative to the game's base path.

== RenderBumpFlat ==
{{:RenderBumpFlat}}

[[Category:Art]]
[[Category:Models]]
</noinclude>

Detail Textures

2007-10-15T16:57:23Z

192.168.0.129:

Any texture can have a detail map added to it. This creates an extra layer of detail blended on top of the existing texture and normal map - a pass which is only drawn when the player is very close to the object. It can help to disguise lower-resolution textures (for example when picmips are enabled).<includeonly>

{{main|Detail Textures}}</includeonly><noinclude>
__NOEDITSECTION__
== Adding Detail Textures to a Material ==
Detail textures are controlled on a per-material basis. Example below:

material test/detailmetal
{
surfaceType "metal"
{
diffusemap textures/metal_d.tga
specularmap textures/metal_s.tga
bumpmap textures/metal_local.tga

'''diffuseDetailMap textures/detail/bump/metal_detail_d.tga'''
'''specDetailMap textures/detail/bump/metal_detail_s.tga'''
'''bumpDetailMap textures/detail/bump/metal_detail_local.tga'''
'''detailMult 4,4,0,0'''
}
}
[[Image:detail_texture_example.jpg|right|An example of the visual difference detail textures can make]]
* The ''bumpDetailMap'' section should point to a tiling normal map.
* The ''diffuseDetailMap'' section should point to a tiling diffuse map.
* The ''specDetailMap'' section should point to a tiling specular map.
* The first two numbers of the ''detailMult'' section are used to specify the X and Y tiling amount of the detail normals. Higher numbers make the detail normals tile more, resulting in finer details.
** '''Note:''' For non-square textures (such as texturesheets), the ''detailMult'' values should be the same aspect ratio as the texture. For example, for a 512x2048 texture sheet, use numbers like "2,8,0,0". If you use a different aspect ratio, the detail normals will appear stretched.
* The last two numbers denote the offset of the detail textures. Most of the time this probably won't have much visual impact, but can be used for tweaking the positioning of the details. A value of 1 offsets by a whole UV unit, so only decimal values between 0 and 1 are necessary.

=== Different Renderprograms ===
Sometimes you may have materials that need different render programs in order for detail textures to work properly. Here are some common special cases:
* If you want a material with the "alphatest" keyword to use detail textures, you must add <tt>''program interaction/basic_detail_alphatest''</tt> at the top of the stage.
* If you want a self-illuminated material with a glow map to use detail textures, you must add <tt>''program interaction/selfillum_detail''</tt> at the top of the stage.
* If you want a material with the Strogg "beetle-shell" effect to use detail textures, you must add <tt>''program interaction/strogg_detail''</tt> at the top of the stage.
** Note: The Strogg detail renderprogram looks for a self-illumination map by default, if you are not using a glow map then you must specify <tt>''selfillummap _black''</tt> after the regular diffuse, bump and specular texture declarations.

=== Tips ===
* Every material does not need to have diffuse, specular and bump detail maps - for example, in some cases just using a bump detail map alone can look better than using all three passes.
* To save texture memory, you could use a single texture for both the diffuse and specular detail textures, since in most cases they tend to match up anyway.

== Masking Detail Textures with an Image ==
* In some cases, it can greatly improve visual quality if the detail maps are not applied evenly over a surface. For example, blending a detail normal into very dark shadows looks odd, since it flattens out the overall texture.
* If a texture would benefit from masking the detail textures out in certain areas, a good way of controlling this is by making a greyscale image, preferably as low-resolution as possible (for memory-saving reasons). 1/8 of the base texture size should be more than enough to make a decent mask.
** A quick method of making a mask to remove the detail textures from the shadows is just to open the texture's diffuse image, greyscale it, and tweak the levels (CTRL-L) in Photoshop to make most areas white, and the darkest areas black.
** In the mask texture, pure black will result in no detail textures being shown, pure white will apply the detail textures at full strength.
* Currently, in order to implement this, these lines (in bold) will need to be added to the material:

material test/detailmetal
{
surfaceType "metal"
{
'''program interaction/basic_detailwm'''
diffusemap textures/metal_d.tga
specularmap textures/metal_s.tga
bumpmap textures/metal_local.tga

bumpDetailMap textures/detail/bump/metal_detail_local.tga
detailMult 4,4,0,0
'''detailWeightMap textures/metal_detailmask.tga'''
}
}

* For materials that use the Strogg renderprogram, use <tt>''program interaction/strogg_detailwm''</tt>.
** Note: The Strogg detail renderprogram looks for a self-illumination map by default, if you are not using a glow map then you must specify <tt>''selfillummap _black''</tt> after the regular diffuse, bump and specular texture declarations.

== Toggling Detail Textures in the Game ==

* You can create a toggle bind to turn detail textures on and off by using '''bind ''<key>'' "toggle r_renderProgramLodDistance 1 250"'''.

* If you want to set the range that the detail texture appears in the game, change the value of ''r_renderProgramLodDistance'' (defaults to 250). This is applied globally on the client side and cannot be controlled on a per-material basis - it is more of a graphics quality control setting.

[[Category:Art]] [[Category:Textures]]
</noinclude>

Category:Level Design

2007-10-15T16:57:03Z

192.168.0.129:

Wiki articles relating to Level Design processes and techniques.

Terrain Editing

2007-10-15T16:56:41Z

192.168.0.129:

== Making a Terrain Model ==
[[Making a Terrain Model]]

== EditWorld's Terrain Editor ==
[[Terrain Editor]]

== MegaBuild ==
{{:MegaBuild}}

== STUFF System ==
{{:STUFF System}}

[[Category:Art]]
[[Category:Level Design]]

Making a Terrain Model

2007-10-15T16:54:17Z

192.168.0.129:

Before building a detailed terrain mesh, make sure your gameplay layout works by using a more simplistic terrain model from Max, Maya or Lightwave, and jump to [[#Getting The Terrain Mesh Into Game|Getting The Terrain Mesh Into Game]] to test it in ETQW until you’re happy with the gameplay layout.

= Terrain Model Methods =
If you want to make a terrain mesh only using a standard 3d package, you can do so and skip down to [[#Getting The Terrain Mesh Into Game|Getting The Terrain Mesh Into Game]].

If you do want to add some more natural detail to your terrain, here are the main steps for doing so:
* Build a basic layout in a 3d modelling package, for testing the gameplay layout.
* Convert the gameplay tested mesh to a Heightmap to use in World Machine.
* Add detail to terrain in World Machine (or other heightmap-based terrain editor).
* Create a level perturbate image using the [[renderBumpFlat]] and [[heightToNormal]] commands.

If you want to get your hands even dirtier you can import the heightmap from World Machine into Mudbox or Zbrush and sculpt more detail.

== Creating a Heightmap from a Model ==
This step is needed if you want to import your current terrain mesh into World Machine.

* Firstly, rotate the terrain mesh. In Lightwave, rotate -90° around the X axis. For 3ds Max & Maya, rotate +90° around the X axis.
* Cap any holes in the mesh, and triangulate. Using a machine with an nVidia graphics card, run the following command in the ETQW console to get the heightmap (where [model] is pointing to the relative path of the ''.lwo'', ''.obj'' or ''.ase'' mesh):
''RenderBumpFlat –floatHeightmap -size 2048 2048 [model]''
* [[RenderBumpFlat]] will print out a value called "Height Difference", note down this number as you’ll need it later. An .r32 heightmap will be saved into the same folder as your model, and this heightmap can be used in World Machine.

== World Machine ==
World Machine is a heightmap node based terrain editor, useful for creating a natural erosion look; here are a couple links to help you learn more about it, and get copy for yourself:
[http://www.world-machine.com World Machine] / [http://world-machine.com/blog/ World Machine Blog]
* The Erosion node is the main tool for creating natural-looking terrains, and contains many options to give a variety of results (try adding perlin noise to the heightmap before eroding).
* From the Erosion node, there are 3 extra outputs; Flow, Wear, and Deposition. These outputs are very handy for making distribution masks for the Megatexture. In order to use the 3 images you’ll have to convert them from top-down planar to UV-space via surface sampling in a 3d package.
* For areas that have been eroded so much that it has removed important gameplay geometry, you can use a Choose node that allows you to blend back the original heightmap using a mask.
* Export the heightmap as both a RAW 32 and 16 (image resolutions of 2048x2048 or higher are preferable), as some 3d packages don’t load 32-bit images. A standard TGA file will give a stepped result due to less height levels.

== Optimising to Game Mesh ==
* First we need to convert the heightmap to a mesh. In both Mudbox and Zbrush you can do this by applying the heightmap as a displacement map on a 3d plane (512x512 tessellation should be enough). Also, World Machine Pro has mesh export capabilities.
* Once exported out, scale and move the new mesh so it matches up to your original gameplay tested mesh.
* The next step is to reduce the polygons to around 32K. Good results can be obtained using a Lightwave plug-in called [http://amber.rc.arizona.edu/lw/qemloss3.html qemLOSS3].
** Create a top down greyscale image that’ll represent the polygon distribution. White on the image would make the mesh dense while black will be less dense.
** In Lightwave rename the default material (Press Q to bring up the appropriate window).
** Apply the distribution map using Textured Point under the Map tab, setting VMap Type to Weighted Map, and giving it a name. Texture editor window will pop up, choose Projection: UV, select the UV map, and select your distribution map for the image.
** Set the viewport to Weight Shade and make sure the image's orientation is correct, orange should be in areas where you want dense polygons.
** Run the plug-in qemLOSS3 (plug-in is found under the Utilities tab). Enter in the number of polygons you want to reduce to (around 32K). Go to the WGHT tab, tick Use Weights as Reduction Constraint, and select the multiply value you want (exaggerates the effect of the weight map). Export back to your preferred 3d package (there may be edges that will need there triangulation flipped).
* This extra little step helps smooth out the mesh (re-distributing the polygons) if you’ve noticed your reduction has left sharp angular polygons. Smooth the mesh (one subdivision) keeping mesh border edges how they are. Run the subdivided mesh through the qemLOSS3 plug-in in lightwave again, this time not applying the weightmap distribution. The end result should leave a smoother mesh that’s better for gameplay.
* Small Lightwave tip: If you want to keep your UV’s, apply a texture to the mesh before exporting out of Lightwave.

== UV the Terrain with minimal distortions ==
This process is written for Maya, other 3d packages might have to modify the process.
* To achieve relaxed UV borders use a mel script called worldSpaceUVLine - it can be found on [http://Highend3d.com/maya/downloads/mel_scripts/modeling/poly_tools/4508.html Highend3D]. Copy the .mel into your ''My Documents\maya\#.#\scripts'' folder and run by typing '''''worldSpaceUVLine;''''' in the Maya command line.
* Snap all 4 corners to the UV 0-1 square. Select all the edge uv for one side, and in the worldSpaceUVLine tool select the corresponding UV layout direction (U for horizontal, V for vertical), and press the align UV’s on selected line button. Repeat for each side.
* Make sure all holes in the mesh are capped, and run the Relax UVs tool, with the option ''Edge Weights'' set to ''World Space'', and ''Pin UV Border'' selected. Keep repeating Relax UVs until you see no more UV movement.

== Create Perturbate Image for Whole Megatexture. ==
This step will make a tangent-space normal map of the difference between your World Machine heightmap and your game mesh. This can then be applied to the Megatexture using the [[Terrain Editor|terrain editor]].
* First rotate the terrain mesh (save as a different file to be safe). In Lightwave, rotate -90° around the X axis. For 3ds Max & Maya, rotate +90° around the X axis.
* We need to make a normal map of the game mesh in order to create the tangent space normal map. Cap any holes in the mesh, and triangulate. Using a machine with an nVidia graphics card, run the following line in the console to get the normal map of the game mesh:
''renderBumpFlat –size <width height> [model]''
* To get the Perturbate normal map, run [[heightToNormal]] in the console, using the normal map made in the step above, and the World Machine heightmap (which needs to be a 32-bit ''.R32'' file):
''heightToNormal sourcelsNormal -s <scale> [normalmap] [heightmap]''
* The ''<scale>'' value is the total height of the heightmap. Use your game mesh as a guide. You’ll probably have to change this value (by units of 10) until you get a mostly even normal map.
* Convert the perturbate normal map to UV space. This is done using a surface sampler (Modify/Surface Sampler in Maya). Source being a planar-mapped mesh with the perturbate map applied, Destination mesh being the relaxed UV game mesh. Alternatively you can use the Warp Image tool in Maya using 2 UV sets, or if using 3dsmax, you can use the Render to Texture dialog to resample to correct UV space.

= Getting The Terrain Mesh Into Game =
* Set the terrain mesh material to ''megatextures/'''map_name'''''
* Export the mesh as '''<map_name>.lwo''' to ''base/models/terrain''
* Create a material for the Megatexture using the same name as above:
''material megatextures/'''map_name''' { useTemplate megatextures/default_ambient < "'''map_name'''" > }''
* Load your map (''.world'' file) in [[editWorld|World Editor]], and bring up the [[Terrain Editor]] inspector.
* On the Root node set the model field to your model, and set the ST Model to a version of your mesh with no mesh holes (fill holes where you have cut out for buildings that go into the terrain).
* Compile the map in order to see it in game (the terrain will appear red if no Megatexture ''.mega'' file exists).

= Out of Bounds (OOB) Geometry =
OOB geometry is the terrain outside the main area that gives the look of terrain extending to the horizon. The best way to build this is to have the Megatexture mirrored on the level/OOB border. This is so there are no obvious texture seams. A bit further out grab areas of terrain (like mountain peaks) from the gameplay mesh and merge those in, as this will keep the look of natural features in the oob. Also reduce the polygon count as the mesh gets further from the gameplay area.

Now we break up the mesh into sections:

'''The OOB Ring''' is a close mesh ring around the gameplay terrain (4096 units) that players can still run on, allowing an area of warning the player to turn back. This mesh should be placed in the level as a model_static, with the properties of:
mergecm 1
model models/terrain/''mapname''_oob_ring.lwo

'''Outer OOB sections:''' The rest of the oob mesh should be broken into 4 to 8 sections circling the oob_ring. This helps the engine not draw sections that are out of the camera’s view. These models should be placed in the level as func_static entities, with the properties:
maxVisDist 0
model models/terrain/''mapname''_oob_1.lwo
noclipmodel 1
noscriptobject 1
pushIntoConnectedOutsideAreas 1

[[Category:Art]]
[[Category:Level Design]]
[[Category:Tutorials]]

Terrain Editor

2007-10-15T16:53:59Z

192.168.0.129:

This inspector tab in editworld is mainly used to build the texture layers of the megatexture. To activate the Terrain Editor click the Begin Editing button at the bottom of the page. The terrain Editor works in a parent/child node based system, where nodes at the top of the list get drawn first and nodes further down get drawn last (opposite of photoshop layers).

To create a node right click on the parent and under new you can select the different nodes: Image Source, Projector, Road, Stamp Node, and Group. In the right click menu you can also copy/paste nodes and delete them. To move a node click and drag, releasing on a node that you wish to be it’s new parent (it will by default make it bottom of the child list). Alternatively you can release the node either just above or below a node, placing it respectively.

= Root Node =
At the top of the node hierarquy, this node must be created first.

* '''Detail Texture 0-3''' Choose the texture for each of the 4 detail texture slots.

* '''Model''' Assign a terrain model to be compiled into the map.

* '''ST Model''' Assign a model to be used for calculating the megatexture ST grid (information used to focus the megatexture around the player). This mesh should be the same as the gameplay mesh, only with all holes filled up (there should be no gaps in the mesh).

= Group Node =
This node is useful for keeping your tree nice and tidy, and does what its name suggests.

= Image Source Node =
Used to apply textures and can be distributed in a variety of ways.

== Image Properties ==

Images and procedurals can be assigned to the different inputs using the bottom left section of the Terrain Editor tab.

* '''Diffuse''' The colour image to be used in the blend.

* '''Distribution''' The distribution image for the whole mesh, where white will blend the image and black will mask the image. This layer uses the uv’s of the mesh, unless UV Type has been set to either Parallel projection settings, where the distribution will be projected in the same manner.

* '''Distribution Pattern''' This images blends with the Distribution image allowing you to make a tiled blend images that matches the Diffuse image. White areas on this images will blend through before black areas.

* '''Global Mask''' This image is multiplied on top of the Distribution mask. Useful when wanting to use complex mix of 2 masks in a node. For example you’ve made a mask for where you want rock, but you want to mask that mask for different angles on the mesh (avoiding upside down rock).

* '''Heightmap''' Used to set a heightmap of a layer for when it or another layer uses a HeightMap Blend.

* '''Local''' The normal map to be used in conjunction with the diffuse image (uses the same scale and rotation settings)

* '''Proj. Pattern''' Used when UV Type is set to a parallel projection. Works in the same way as Distribution Pattern, except is projected parallel with the diffuse image (and uses the same scale settings).

To assign an image, select the image type (Diffuse, Distribution Pattern…) and under Image Properties/'''''Source Type''''' (on the left side of the tab) choose the type of image you would like (texture or procedural). With each type, different settings can be entered:

=== Texture ===
* '''Clamp Distribution''' Here you can set if an image tiles or is clamped. Normally can be left to default, as by default the image node is set to tile and a projector node is set to clamp.
* '''File Type''' Choose a texture/image you wish to use. In the Choose an image pop-up, you can add a favourite folder by dragging it into the favourites section. Double click the favourite to enter that folder, and while selected press delete to remove it from the list.

=== Noise, Rocky, and Marble ===
Contain standard procedural settings

=== Geometry Based ===
Builds an image created from terrain attributes, useful for masks (snow caps, rocky cliffs).
* '''Altitude Properties''' Contains settings to mask based on geometry height (Altitude Lower and Upper). To activate an altitude select and tick Enable.
** '''Value''' Assigns a height at which to start the mask (standard editor units).
** '''Fuzziness''' The higher the number the smoother/longer the fade in.
* '''Resolution''' Assign a texture resolution to the procedural image.
* '''Slope Properties''' Contains settings to mask based on geometry angle (Slope Lower and Upper). To activate an altitude select and tick Enable.
** '''Value''' Assigns an angle at which to start the mask.
** '''Fuzziness''' The higher the number the smoother/longer the fade in.

== Properties ==
Contains the settings/values on how to blend the images and nodes together.

=== Blend ===
Here you can choose how you want this node to blend with the previous layers:

* '''Add''' Brightens the previous layers using the image on this node. Note that masks don’t work with this blend mode

* '''Multiply (d*(s*1.6))''' In the source image colours darker thank 160 will darken the previous layers, while colours brighter than 160 will lighten.

* '''Multiply (d*s)''' Darkens the previous layers by using the image in this node.

* '''Heightmap''' Using the heightmap images of all layers, and the first 2 values in blend parameters, this mode blends the node into the deeper parts of the blended heightmaps (darker). The best way to set up a heightmap blend is add a heightmap to the previous layers you want to blend into. Then on the node with the heightmap blend mode, set the heightmap to black. It will now blend into the cracks and lower areas of the previous layers, using the Distribution image as a guide. Adjust the Blend Parameters to bring up the height of the blend and the falloff. Note that this method uses all the heightmaps blended together, so when using more than one heightmap blend it might not work as well.

* '''Perturbate Normals''' This blend method will add the local image onto the previous layers normals. Useful for adding detailed normals from a higher-res terrain. Note the diffuse image is not rendered but all other layers work fine.

=== Blend Parameters ===

* '''Parm 0''' Used in a heightmap blend, this value controls the height as which the blend takes place.

* '''Parm 1''' Used in a heightmap blend, this value controls the sharpness of the falloff in the blend.

* '''Parm 2''' Not used for anything.

* '''Parm 3''' Used to adjust the falloff sharpness when using UV Type set to Parallel (Top Down or Side).

=== Color Properties ===

* '''Alpha''' Transparency of the layer (white is opaque).

* '''Color''' You can tint a layer by choosing a colour here.

* '''Inverse Alpha''' Inverts where the layer is rendered.

* '''Ramp Width''' Controls the sharpness of the falloff (1 is wide, 0 is sharp).

=== Detail Texture Type ===
Sets what detail texture from 0 to 3 to use. Detail textures are defined in the Root node.

=== Distribution Pattern Texture Rotation ===
Sets the Rotation of the Distribution Pattern (counter clockwise).

=== Distribution Pattern Texture Scale ===
Sets how many times the Distribution Pattern tiles.

=== Image Renderer ===
This section is used to set the image node to render as a side or top projection.

* '''Projection Angle''' Used when UV type is set to Parallel Side, it allows you to change the direction at which the side projection takes place. In order to make sure the normals aren’t flipped, check that you aren’t projecting from the opposite side.

* '''UV Type'''' Sets what UV method to use, Mesh UV’s or Planar Projection.
** '''From Mesh''' Renders the node with the mesh UV’s (default).
** '''Parallel Top Down''' Planar projection from Top Down.
** '''Parallel Side''' Planar projection from the side.

=== Propagate Distribution ===
If set to '''true''' the mask of this Node will mask the children nodes also.

=== Surface Type Properties ===
[[#Surface Type|Surface Type]] sets what footstep and impact effects to use.

* '''Threshold''' Allows a [[#Surface Type|Surface Type]] of a Node to bend in sooner (stronger) if set above 0.5, or weaker below 0.5. By default it's at 0.5 and usually doesn't need changing.

* '''Type''' Sets what the [[#Surface Type|Surface Type]] is: ''carpet, concrete, dirt, dusty_road, flesh, forcefeild, glass, grass, gravel, ice, leaves, liquid, metal, metal_thick, moss, mud, paper, pavement, pine, plastic, sand, snow, stone, water, water_interior, wood, wood_thick.''

=== Texture Properties ===

* '''Clamp To Edge''' If set to '''true''' the edge pixels will repeat and the image wont tile. Mainly used for a large image that will cover the whole map, and you don't want the edge pixels to blend through to the other side.

* '''Mask Rotation''' Sets the Rotation of the Distribution image (counter clockwise).

* '''Rotation''' Sets the Rotation of the Diffuse image (counter clockwise).

* '''Scale''' Sets how many times the Diffuse image tiles.

= Projector Node =
This node projects an image from a positional plane onto the terrain mesh (megatexture). Most of the settings from the [[#Image Source Node|Image Source Node]]work the same, except there is an extra section called [[#Projector|Projector]]. By pressing ''v'' (vertex edit mode) you can modify the projector into a different shape.

=== Projector ===
* '''Num Sides''' Usually leave as default, don't set it to 2 or below.
* '''Origin''' Sets the center of the projector, usually best to move the projector in the editor than to type in a value.
* '''Parallel''' Buggy at the moment, leave as '''Parallel'''.
* '''Tex. Coords''' Sets what UV's to use when projecting.
** '''Generated''' Uses projected UV's
** '''From Model''' Uses mesh UV's for Diffuse and Local, and uses the Projected UV's for just the mask (Distribution).

= Road Tool Node =

= Stamping and the Stamp Node =

= Megatexture Preview =

= Detail Textures =

= Surface Type =
<noinclude>
[[Category:Art]]
[[Category:Level Design]]
</noinclude>

MegaBuild

2007-10-15T16:53:03Z

192.168.0.129:

MegaBuild is a small application designed to ease the MegaTexture compile process. It includes options for MegaGen (to render the raw texture tiles), Renderlight (to bake lighting info into the tiles) and MakeMegaTexture (which compiles the tiles into a compressed .mega file). It's a one-stop shop for compiling MegaTextures.<includeonly>

{{main|MegaBuild}}</includeonly><noinclude>
__NOEDITSECTION__

= Overview =
The MegaBuild application can be found in the "Utilities" folder of the main ETQW directory. Look for '''MegaBuild.exe''' and run it.

= Using MegaBuild =
[[Image:megabuild_overview.png|right|MegaBuild main window]]

=== Find ETQW.exe ===
Firstly you need to select a valid game executable to launch the commands from.
* Go to ''File -> Find EXE...'' (or hit '''CTRL-SHIFT-O''').
* Browse to the game directory and select ''ETQW.exe''.

=== Load a Surface Tree ===
Now you will need to load a [[Surface Tree]] (''.sft'') file which contains the texture and surface information you want to render into your MegaTexture.
* Go to ''File -> Open'' (or hit '''CTRL-O''').
* Browse to your ''maps'' directory and select your ''mapname.sft'' file.

=== MegaGen Settings ===
MegaGen is the first stage of making a MegaTexture. The settings are fairly straightforward.
* '''Resolution''' sets the width and height in pixels of your final MegaTexture. For ET:QW we used a ratio of 1 pixel to 1 game unit, so a terrain which is 32,768 units across would use a MegaTexture with a resolution of 32,768.
* '''Video Cache'''. 128 is a good value.
* '''Memory Cache'''. Give it as much as your computer will allow! For a computer with 2GB of RAM, 1536 is a good value here.

=== RenderLight Settings ===
RenderLight bakes atmospheric lighting information into your MegaTexture. Depending on the settings used here, MakeMegaTexture will either output a 3-channel (RGB) or 4-channel (RGBA) MegaTexture.
* '''Bake lighting''' - When checked, this option will bake the atmospheric sunlight into the MegaTexture.
* '''Bake ambient''' - When checked, this option will bake the ambient atmospheric light into the MegaTexture.
* Leaving both '''Bake lighting''' and '''Bake ambient''' un-checked will produce a 4-channel MegaTexture, which is larger size on disk but contains more accurate surface bump information.

=== MegaTexture Settings ===
MakeMegaTexture is the process which compiles the output of the previous processes into a compressed ''.mega'' file.
* '''Best Quality''' denotes, er, using the best quality!
* '''Luminance Error''' denotes the luminance error...
* '''Chrominance Error''' denotes the chrominance error...
* '''Alpha Error''' denotes the alpha error...

=== Run the Processes ===
Once you have set up all of the options for your MegaTexture, you can set the MegaBuild processes going.
* ''Tasks -> Run Checked...'' (or pressing '''F5''') will run all of the selected processes.
* If this is the first time you're compiling a MegaTexture, check all 3 boxes for MegaGen, RenderLight and MegaTexture.
* You can un-check any processes you don't want to run at this time. For example if you want to re-compile some tiles from RenderLight with different MegaTexture settings, un-check MegaGen and RenderLight, leave MegaTexture checked, and then select ''Run Checked'' or hit '''F5'''.
** Alternately, you can just click the ''"Make MegaTexture"'' button in the MegaTexture field.

= Components =
These are the individual processes that MegaBuild calls from the game.

=== MegaGen ===
{{:MegaGen}}

=== RenderLight ===
{{:RenderLight}}

=== MakeMegaTexture ===
{{:MakeMegaTexture}}

[[Category:Art]]
[[Category:Level Design]]
</noinclude>

STUFF System

2007-10-15T16:52:40Z

192.168.0.129:

The STUFF System is a quick and easy way of distributing thousands of models across a terrain. It is mainly used for adding grass, plants, small shrubs, stones and twigs on top of the [[MegaTexture]].<includeonly>

{{main|STUFF System}}</includeonly><noinclude>
__NOEDITSECTION__
= Overview =
[[Image:stuff_grass.jpg|center|frame|A screenshot comparison from Valley showing the difference between the bare terrain and the STUFF distribution.]]
You can place "STUFF" in your map with the DistributeStuff console command. This command takes a single parameter, the filename of a "stuff generation" (''.sg'') file. See the reference section below to find how these scripts are set up.

After running DistributeStuff, a ''stuff.clustb'' file will appear in the ''"/base/stuff/[mapname]"'' directory, this file contains the actual positions of all the scattered objects, so the mask images and the .sg file do not need to distributed with the game.

=== Making It Appear In The Level ===
You need a '''"stuffsystem"''' entity in your map before the STUFF will be visible. The following entity is all you need.
{
"classname" "stuffsystem"
"name" "my_stuff"
"origin" "0 0 0"
}
Compile your map with this entity added before doing any of the following steps, or you may not be able to view your STUFF distribution in-game.

= Working Conventions =
* ''.stuff'' reference files should be stored in the following location: ''"base/stuff/[mapname].stuff''
* ''.sg'' scripts should be stored in the following location: ''"base/stuff/[mapname]/[mapname].sg"''
* Related media (masks, STUFF models and colour maps) should be stored in the same folder as the ''.sg'' file, for ease of access.
** Keep STUFF models unique on a per-map basis so you can easily adjust one map's "STUFF" without affecting any other levels accidentally.

= StuffType (''.stuff'') Reference =
''.stuff'' files specify the different types of model you can scatter around, the declarations in these files are referenced by the STUFF system.
A simple example:

stuffType [mapname]/grass {
Model "stuff/[mapname]/grass_01.ase"
Model "stuff/[mapname]/grass_02.lwo"
}

stuffType [mapname]/plants {
Model "stuff/[mapname]/plant_01.lwo"
Model "stuff/[mapname]/plant_02.lwo"
}

* '''stuffType''' is the declaration name that is referenced by other parts of the STUFF system (''.sg'' and ''.clustb'' files refer to this).
* '''Model''' should contain a path to a valid model (ASE, LWO and OBJ should all work). This model is scattered by this stuff declaration. If more than one model is specified, each will be randomly chosen and placed when the '''distributeStuff''' command is run.
** More unique models can lead to a more natural-looking distribution, especially in the case of shrubs and plants.
** You can put the same model multiple times in a single declaration, that way the chances of that model being chosen compared to other models are bigger. So if you put 9 times one model and 1 time another, 9 out of 10 models (on average) will be the first model.

= StuffGeneration (''.sg'') reference =
Here is an example script:

version 1
{
model "models/terrain/[mapname].lwo"
}
sdStuffLayer {
Density 10
Distancescale 1
Distribution Area
StuffType "[mapname]/grass"
Mask "stuff/[mapname]/mask_grass.tga"
ColorMap "stuff/[mapname]/grass_colour.tga"
}
sdStuffLayer {
Density 4
Distancescale 2
Distribution Area
StuffType "[mapname]/plants"
Mask "stuff/[mapname]/mask_plants.tga"
ColorMap "stuff/[mapname]/plants_color.tga"
}

* '''version''' should always be set to 1.
* '''model''' should point to your map's terrain mesh.
* '''sdStuffLayer''' is a single layer over the whole terrain mesh that distributes STUFF models based on the following values:
** '''Density''' is a value which behaves differently depending on the Distribution type used. See below for details.
** '''Distribution''' specifies how the STUFF is distributed (positioned) over the terrain, and can be one of the following values:
*** '''Area''' means the STUFF is uniformly distributed over the whole terrain, independent of the underlying geometry. In this case, the '''Density''' value specifies the number of objects "per square unit". You will nearly always want to use this type of distribution.
*** '''Vertex''' places a single STUFF model on every vertex of the terrain mesh. In this case, the '''Density''' value is unused.
*** '''Triangle''' places the same number of STUFF models on every triangle of the terrain mesh. In this case, the '''Density''' value specifies how many objects should be created per triangle.
** '''Distancescale''' will scale all distances used during rendering of this STUFF layer by an arbitrary amount. Setting this value to 1 will render STUFF models to the extent of the ''r_stuffFadeEnd'' cvar. Setting this value to 2 will make the STUFF models fade out twice as close, etc. This value should never be set lower than 1, as this will lead to visual "popping" errors in the distance.
** '''Mask''' specifies a grayscale TGA file that defines the density of STUFF models. White means full density (as specified by the density parameter) gray to black means successively lower densities until there are no objects placed at all. This parameter is optional (but recommended!), as the default is a fully white map.
** '''ColorMap''' specifies an RGB colour TGA file that defines the color of the individual stuff objects. In this way certain areas can have drier brown grass for example. This parameter is optional, the default is a fully white map.
** '''CutOff''' is an integer defining at wich value stuff should stop appearing in your mask. The default value is 16 which means grayscale values in the mask lower than 16 will not spawn any stuff.
** '''Orientation''' will control the orientation of the STUFF models, there are two options:
*** '''local''' orients STUFF models according to the normals of the model used for distribution (default behaviour).
*** '''world''' will always orient STUFF models upwards (ETQW never uses this, since '''local''' looks more natural).

You can define as many sdStuffLayers in a ''.sg'' file as you like, but bear in mind that each one will be an additional rendering batch. Try and use as few layers as possible to achieve the visual effect you want.

= distributeStuff =
Once you have set up your ''.stuff'' and ''.sg'' files, you can generate your STUFF cluster (''.clustb'') file by running the following command in the game console:

distributeStuff stuff/[mapname]/[mapname].sg

Note you can run '''distributeStuff''' with your map loaded in game, then use '''reloadmodels''' to reload the STUFF cluster and see your changes immediately.

= Performance Notes =
As STUFF potentially allows you to have thousands of objects added to the map by just a few parameters you should be careful not to overuse STUFF. Some performance hints:
* Keep the density as low as possible for the effect you want, as this is the parameter that affects the number of objects that get generated. You could in theory have a dark gray mask and a higher density (resulting in the same overall number of objects) but it's a better idea to keep distribution masks "normalized" (ie. the full range from black to white).
* With grass, the actual draw speed is not necessarily related to the total number of grass plants visible, the speed hit is when a lot of alpha-tested grass textures cover the same screen area (causing a high amount of overdraw) so it is better to render sparse grass to a further distance than dense grass that fades fast.
** To this end, it makes sense to have two grass layers - one would be sparse and fade to the distance, the other would fade very close but be more dense. This gives a more pleasing visual result with less performance loss.

[[Category:Art]]
[[Category:Models]]
[[Category:Level Design]]
</noinclude>

Category:Art

2007-10-15T16:52:12Z

192.168.0.129: Category description

Wiki articles relating to Art processes and techniques.