q3rally-team/q3rally
0
0
Fork 0
mirror of https://github.com/Q3Rally-Team/q3rally.git synced 2024-11-21 19:41:36 +00:00
Code Issues Projects Releases Packages Wiki Activity

Added working mapping tools for NetRadiant/GTKRadiant 1.5.0

Browse source
This commit is contained in:
q3rally 2017-12-30 16:29:40 +00:00
parent 24d4683a62
commit 5cba578afd
77 changed files with 7586 additions and 37 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

15
tools/radiant-config/radiant15-netradiant/games/q3rally.game
View file

@ -1,22 +1,21 @@
<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<!-- modify at your own risks -->
<?xml version="1.0"?>
<game
type="q3rally"
type="q3"
index="1"
name="Q3Rally"
enginepath_win32="C:/Program Files/Q3Rally/"
enginepath_linux="/usr/local/games/q3rally/"
enginepath_macos="/Applications/Q3Rally
engine_win32="q3rally.exe"
engine_linux="q3rally.sh"
engine_macos="q3rally.app"
prefix=".q3rally"
engine_linux="q3rally.x86_64"
prefix=".q3r"
basegame="baseq3r"
basegamename="Q3Rally"
knowngame="missionpack"
knowngamename="Q3Rally"
unknowngamename="Custom Q3Rally modification"
shaderpath="scripts"
archivetypes="pk3"
texturetypes="tga jpg png"
texturetypes="tga jpg"
modeltypes="md3 ase lwo obj 3ds picoterrain"
maptypes="mapq3"
shaders="quake3"

13
tools/radiant-config/radiant15-netradiant/q3rally.game/baseq3r/default_shaderlist.txt
View file

@ -1,3 +1,11 @@
//*********************************************************//
// shaderlist.txt modified for GTKRadiant/Netradiant //
// by Perle for use with Q3Rally - 30/12/2017 //
// // // //
// Rev history: // // //
//********************************************************//
// this file lists all the separate shader files
//shaderlist
common
glass
@ -14,7 +22,4 @@ trees
skies
liquids
q3r_lights
break
break

46
tools/radiant-config/radiant15-netradiant/q3rally.game/default_build_menu.xml
View file

@ -1,13 +1,13 @@
<?xml version="1.0"?>
<!--
build commands
[RadiantPath]: path to Radiant .. C:\Program Files\NetRadiant\
[EnginePath]: path to the engine .. C:\Program Files\TurtleArena\ /usr/local/games/turtlearena/
[RadiantPath]: path to Radiant .. C:\Program Files\Gtkradiant
[EnginePath]: path to the engine .. C:\quake3\ C:\Program Files\Quake III Arena\ /usr/local/games/quake3/
-->
<project version="2.0">
<var name="q3map2">"[RadiantPath]q3map2.[ExecutableType]" -v<cond value="[MonitorAddress]"> -connect [MonitorAddress]</cond> -game quake3 -fs_basepath "[EnginePath]"<cond value="[GameName]"> -fs_game [GameName]</cond></var>
<build name="Q3Map2: (single) BSP -meta -custinfoparms -flares -skyfix">
<command>[q3map2] -meta -custinfoparms -flares -skyfix "[MapFile]"</command>
<build name="Q3Map2: (single) BSP -meta">
<command>[q3map2] -meta "[MapFile]"</command>
</build>
<build name="Q3Map2: (single) -vis">
<command>[q3map2] -vis "[MapFile]"</command>
@ -16,42 +16,42 @@ build commands
<command>[q3map2] -vis -fast "[MapFile]"</command>
</build>
<build name="Q3Map2: (single test) -light -faster">
<command>[q3map2] -light -lightmapsize 512 -faster "[MapFile]"</command>
<command>[q3map2] -light -faster "[MapFile]"</command>
</build>
<build name="Q3Map2: (single test) -light -fast">
<command>[q3map2] -light -lightmapsize 512 -fast "[MapFile]"</command>
<command>[q3map2] -light -fast "[MapFile]"</command>
</build>
<build name="Q3Map2: (single) -light -fast -super 2">
<command>[q3map2] -light -lightmapsize 512 -fast -super 2 "[MapFile]"</command>
<command>[q3map2] -light -fast -super 2 "[MapFile]"</command>
</build>
<build name="Q3Map2: (single) -light -fast -super 2 -filter">
<command>[q3map2] -light -lightmapsize 512 -fast -super 2 -filter "[MapFile]"</command>
<command>[q3map2] -light -fast -super 2 -filter "[MapFile]"</command>
</build>
<build name="Q3Map2: (single) -light -fast -super 2 -filter -bounce 8">
<command>[q3map2] -light -lightmapsize 512 -fast -super 2 -filter -bounce 8 "[MapFile]"</command>
<command>[q3map2] -light -fast -super 2 -filter -bounce 8 "[MapFile]"</command>
</build>
<build name="Q3Map2: (test) BSP -meta -custinfoparms, -vis, -light -fast -filter">
<command>[q3map2] -meta -custinfoparms "[MapFile]"</command>
<build name="Q3Map2: (test) BSP -meta, -vis, -light -fast -filter">
<command>[q3map2] -meta "[MapFile]"</command>
<command>[q3map2] -vis -saveprt "[MapFile]"</command>
<command>[q3map2] -light -lightmapsize 512 -fast -filter "[MapFile]"</command>
<command>[q3map2] -light -fast -filter "[MapFile]"</command>
</build>
<build name="Q3Map2: (test) BSP -meta -custinfoparms -flares -skyfix, -vis -fast, -light -fast -super 2 -filter">
<command>[q3map2] -meta -custinfoparms -flares -skyfix "[MapFile]"</command>
<build name="Q3Map2: (test) BSP -meta, -vis -fast, -light -fast -super 2 -filter">
<command>[q3map2] -meta "[MapFile]"</command>
<command>[q3map2] -vis -saveprt -fast "[MapFile]"</command>
<command>[q3map2] -light -lightmapsize 512 -fast -super 2 -filter "[MapFile]"</command>
<command>[q3map2] -light -fast -super 2 -filter "[MapFile]"</command>
</build>
<build name="Q3Map2: (final) BSP -meta -custinfoparms -flares -skyfix, -vis, -light -fast -filter -super 2">
<command>[q3map2] -meta -custinfoparms -flares -skyfix "[MapFile]"</command>
<build name="Q3Map2: (final) BSP -meta, -vis, -light -fast -filter -super 2">
<command>[q3map2] -meta "[MapFile]"</command>
<command>[q3map2] -vis -saveprt "[MapFile]"</command>
<command>[q3map2] -light -lightmapsize 512 -fast -filter -super 2 "[MapFile]"</command>
<command>[q3map2] -light -fast -filter -super 2 "[MapFile]"</command>
</build>
<build name="Q3Map2: (final) BSP -meta -custinfoparms -flares -skyfix, -vis, -light -fast -filter -super 2 -bounce 8">
<command>[q3map2] -meta -custinfoparms -flares -skyfix "[MapFile]"</command>
<build name="Q3Map2: (final) BSP -meta, -vis, -light -fast -filter -super 2 -bounce 8">
<command>[q3map2] -meta "[MapFile]"</command>
<command>[q3map2] -vis -saveprt "[MapFile]"</command>
<command>[q3map2] -light -lightmapsize 512 -fast -super 2 -filter -bounce 8 "[MapFile]"</command>
<command>[q3map2] -light -fast -super 2 -filter -bounce 8 "[MapFile]"</command>
</build>
<build name="Q3Map2: (simulate old style -light -extra) BSP -meta -custinfoparms, -vis, -light -super 2">
<command>[q3map2] -meta -custinfoparms "[MapFile]"</command>
<build name="Q3Map2: (simulate old style -light -extra) BSP -meta, -vis, -light -super 2">
<command>[q3map2] -meta "[MapFile]"</command>
<command>[q3map2] -vis -saveprt "[MapFile]"</command>
<command>[q3map2] -light -super 2 "[MapFile]"</command>
</build>

565
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Compile_Manual/bspc.txt Normal file
View file

@ -0,0 +1,565 @@
Title: BSP Converter
Version: 2.1h
Date: 2001-03-28
Author: Mr. Elusive
Description
-----------
The BSPC tool is used to create AAS files from BSP files.
An AAS file is a file with areas used by the Quake III Arena bot in order
to navigate and understand a map. The Quake III Arena maps are stored in
BSP files.
Usage
-----
bspc [-<switch> [-<switch> ...]]
Example 1: bspc -bsp2aas d:\quake3\baseq3\maps\mymap?.bsp
Example 2: bspc -bsp2aas d:\quake3\baseq3\pak0.pk3\maps/q3dm*.bsp
Switches:
bsp2aas <[pakfilter/]filter.bsp> = convert BSP to AAS
reach <filter.bsp> = compute reachability & clusters
cluster <filter.aas> = compute clusters
aasopt <filter.aas> = optimize aas file
output <output path> = set output path
threads <X> = set number of threads to X
cfg <filename> = use this cfg file
optimize = enable optimization
noverbose = disable verbose output
breadthfirst = breadth first bsp building
nobrushmerge = don't merge brushes
freetree = free the bsp tree
nocsg = disables brush chopping
forcesidesvisible = force all sides to be visible
grapplereach = calculate grapple reachabilities
Several metacharacter may be used in the filter and pakfilter.
* match any string of zero or more characters
? match any single character
[abc...] match any of the enclosed characters; a hyphen can
be used to specify a range (e.g. a-z, A-Z, 0-9)
.pk3 files are accessed as if they are normal folders. For instance
use "d:\quake3\baseq3\pak0.pk3\maps/q3dm1.bsp" to access the
map q3dm1.bsp from the pak0.pk3 file.
Multiple files may be listed after the switches bsp2map, bsp2aas, reach,
cluster and aasopt.
If a BSP file is being converted to an AAS file and no output path
is entered on the command-line then the AAS file will automatically
be stored in the same folder as the BSP file. However if the BSP file
was stored in a .pk3 file then the AAS file will be stored in a folder
with the name 'maps' outside the .pk3 file.
Updating entity lump
--------------------
If an AAS file is already available for a BSP file and you ONLY change
the entities inside this BSP file then you only have to recalculate the
reachabilities. This way you can move items, platforms etc. around
without the need to recalculate the whole AAS file which can save quite
some compile time. You can recalculate the reachabilities as follows:
bspc -reach mymap.bsp
Where mymap.bsp is the BSP file. The mymap.aas file has to be in the
same folder as mymap.bsp or should be in the output folder specified
with the -output option.
Keep in mind that as soon as ANY geometry in the map changes the whole
AAS file HAS to be recalculated in order to play with bots.
NOTE: -reach does not work on optimized .AAS files!
NOTE: don't use -reach when moving the position of doors.
Leaks
-----
Just like there can be vis leaks in a map there can also be clipping
leaks. Two things can be wrong when the BSPC tool outputs that a map
leaks.
1. There are no entities in the map at all, or all entities that are
actually in the map are placed in solid. In this case the BSPC tool
outputs "WARNING: no entities inside". (At least a player start entity
is needed to load a map.)
2. There is a spot in the map where players can go outside the map
into the void. This is bad, players should never be able to fall out
of a level. In this case the BSPC tool outputs "WARNING: entity
reached from outside". The BSPC tool also writes a mymap.lin file
that can be loaded in the Q3Radiant editor to show lines that go
through the actual leak.
Make sure the .lin file is stored in the same folder as where q3radiant
stores the .bsp file. Load the map in q3radiant and use the
menu -> File -> Pointfile... to load the .lin file. A thick red line
will be shown in the map. Follow this line to find the leak.
Map bounds
----------
Currently a map should be within the bounds (-65536, -65536, -65536) -
(65536, 65536, 65536) for the bspc tool to compile. These are the same
limits the q3map tool has.
Physics
-------
The player bounding box is a 30 units by 30 units square with a height
of 56 units. If we assume 1.75 meters being the average height of a human
and a player in Quake III Arena being 56 units high we get 32 units = 1 meter.
Maximum step height of a player is 18 units (just keep steps 16 units or
lower).
The maximum water jump height for bots has been set to 18 units. (height
difference between water surface and the floor jumping onto). If the
waterjump height is made higher human players will have a hard time getting
out of the water.
With normal gravity and without the quad the maximum rocket jump height is
around 280 units (you can sometimes jump a few units higher but this is a
safe value for reference).
The maximum height for barriers the bots will jump on is 32 units.
Some math to calculate some other values of interest:
gravity = 800;
jump velocity = 270;
max vertical rocketjump velocity = 670;
max run velocity = 320;
max step height = 18;
max jump height = 0.5 * gravity * (jumpvelocity/gravity)*(jumpvelocity/gravity);
max jump height = 45 units;
NOTE: even though this is the mathematical maximum jump height always keep
the the 32 units maximum barrier height for bots in mind when building maps.
maximum horizontal jump distance over a gap from one spot to another both
at the same height:
t = sqrt((maxjumpheight + maxstep) / (0.5 * gravity));
t = 0.3986 seconds;
dist = maxrunvelocity * (t + jumpvelocity / gravity);
dist = 235 units;
Because players use a bounding box we can jump a full bounding box width
furter in the ideal case. (15 units at the jump start and 15 at the
landing place).
235 + 15 + 15 = 265 units.
Again this is the mathematical maximum which players can only reach under
ideal circumstances.
Optimizing a map for bspc
-------------------------
Hint brushes have no effect on the bspc tool. Only solid, clip, liquid,
cluster portal and do not enter brushes are used by the bspc tool.
The bspc tool outputs how many areas are created for a map. Less areas
is better. Often the number of areas can be reduced by adding additional
clip brushes. By adding these additional clip brushes the complexity
of the geometry used for collision can be reduced. Do not add clip
brushes in front of the complex geometry but get the complex shaped
geometry contained within these clip brushes. Things that should be
contained within clip brushes are small or complex shaped (often detail)
brushes and complex and twisted curves, but also more regular curves
can be placed within a clip brush. When containing a curve within a
clip brush it's preferred to place the whole curve within the clip
brush (not just part of the curve).
Note: you can make brushes or curves non-solid when they are contained
within *full* clip or *weap* clip brushes to speed up bspc calculations.
Always try to align your geometry to the grids. Always use the largest
grid possible for alignment of your geometry. Also try to align the
back sides of brushes which may not be visible. The more brush sides
are aligned the better. This will also speed up bspc calculations.
Align adjacent brushes as much as possible. Make sure no tiny faces are
created due to badly aligned brushes.
Quite often there are places in a map that are visible to players
but that players can never get to. Players would be able to walk around there
but since players can never reach such places they will never actually
move around there. If players are never able to get to such places
it's better to put a large clip brush which encloses that whole space.
This will also speed up bspc calculations and reduce the number of areas
created by the bspc tool.
Note: the number of areas relative to the map size tells something about
the navigation complexity for players in general (also human players).
Reducing the collision complexity for bots also makes the map easier to
navigate for human players
func_plat and func_bobbing
--------------------------
When func_plat or func_bobbing entities are placed in a map the bots will
use them if possible. The bots assume they can stand on top of the bounding
box of the model used for the func_plat or func_bobbing entity. As a result
creating complex shaped func_plat or func_bobbing models is mostly a bad
idea. You have to make sure the bots (and players) can actually stand
everywhere ontop of the bounding box of the model.
Cluster Portals
---------------
A map is divided into areas. Several of these areas can be grouped together
to create a cluster. The clusters are seperated by cluster portals which are
areas themselves. One of the things the bot uses these clusters for is a
multi-level routing algorithm. When a map is efficiently divided up into
clusters bot calculations will be faster.
several things to take into account:
- The BSPC tool tries to create cluster portals automatically but additional
cluster portals can be created by placing "clusterportal" brushes.
- Cluster portals are manually created by placing "clusterportal" brushes
inside the map.
- Cluster portal brushes are a tool to optimize a map for CPU usage by the
bots. They are not needed for the bots to operate correctly.
- The "clusterportal" brushes should not be used outside the world hull.
- The cluster portals do not have any effect on vis.
- If a door is already sealed with an areaportal brush, a clusterportal is
not necessary there. (area portals are also used as cluster portals).
- Just like the area portals, the cluster portals must seal a space off
entirely from other areas.
- The cluster portal areas should seal off a cluster in a way that the only
path towards another cluster is through a cluster portal area.
- Only create cluster portals where people can walk or swim through.
- Don't create cluster portals in gaps in the floor. (people would fall through)
- If you have two sealed off clusters and you add a teleporter between them
then the two clusters will be merged again because of the teleporter.
- Cluster portals must seperate no more and no less than two (2) clusters.
- Try to create clusters with all the same number of 'reachability' areas.
for instance if the map has 5400 areas try to create 10 clusters with 540
areas each, or 12 clusters with 450 areas each, etc. The BSPC tool lists
the number of reachability areas in each cluster.
With Q3A version 1.25 and up you can use /set bot_testclusters 1 on the
console and the area number and cluster number you're in will be printed
on the screen. These cluster number correspond to the cluster numbers
the BSPC tool prints.
- Minimize the number of clusters with only a few (less than 10) areas.
- When adding "cluster portal" brushes try to place them in places with
minimal geometric complexity. For instance place them inside convex door
openings or small hallways (not infront of door openings). Ideally the shape
of the face through which a player walks or swims into the cluster portal
is the same as the shape of the face through which a player leaves the
cluster portal. Also ideally the open space inside the cluster portal
brush is convex.
- Make cluster portals about 16 or 32 units thick or align them with
adjacent geometry. Don't make them too thick though.
- Minimize the total number of cluster portal areas at all times. The more
cluster portal areas you have the more CPU the bots need.
- Items have no effect at all on the creation of areas or clusters.
The same goes for item_botroam.
Do Not Enter areas
------------------
When bot navigation problems show up or you want to make sure a bot never tries
to go to a certain place "do not enter" brushes can be used.
several things to take into account:
- The "do not enter" brushes should not be used outside the world hull.
- The "do not enter" brush is Not a clip brush for the bot.
- The "do not enter" brush is a tool of last resort. Do not use it unless
there are serious navigation problems.
- The number of "do not enter" brushes should be minimized because these
brushes create additional areas for the bots.
- The "do not enter" brush will create a New area that the bot will try to
avoid. However if the bot somehow ends up in a "do not enter" area or there
is a valid goal inside the "do not enter" area then the bot is allowed to
go into and out of that area. So if the bot somehow gets in a "do not enter"
area the bot will be able to get out.
Bot roaming
-----------
The item_botroam entity can be used when a bot does not roam the whole level
or prefers to go to only specific areas. This (invisible) item can be placed
in a map just like regular items. Nobody can actually pick up the item it's
only used to attract bots to certain places of the map. The item_botroam has
a key "origin". The value is set by Q3Radiant automatically. The item_botroam
also has a key "weight". The value is the weight of the roam item and is
relative to the weight of other items in the map. The bot character specific
item weights are stored with the bot characters in the botfiles/bots/ sub-folder
in the .pk3 file. The value of the weight is a non-zero floating point value,
most often in the range 0 to 400. (Higher values are allowed but keep in mind
that the bot should also still go for normal items, so don't make the
item_botroam weight to high.)
When a bot should never go for a specific item the key "notbot" with value "1"
can be used for that item. This key with value can be used for every available
item in Quake III Arena.
The suspended flag can be used on all items (item_botroam included).
However keep in mind that when a suspended item is not anywhere near the
ground the bot will ONLY try to go for this suspended item using jump pads.
Team based entities
-------------------
You can use the "bot_notteam" entity key with value "1" or "2" on teleporters
(trigger_teleport or trigger_multiple pointing at a target_teleporter),
elevators (func_plat), cyclic movers (func_bobbing), jumppads (trigger_push)
and areas that hurt the player (trigger_hurt).
When "notteam" is set to "1" only bots using the travel flag TFL_NOTTEAM1 will
use the entity or move through the area. When "bot_notteam" is set to "2" only
bots using the travel flag TFL_NOTTEAM2 will use the entity or move through the
area. These travel flags can be used in the game source code. Using this entity
key also only has effect if the mod the map is being made for supports team based
navigation for bots.
Testing AAS files
-----------------
One of the easiest ways to test the AAS file is to load the map in
Quake3 in teamplay mode (type /set g_gametype 3 on the console before
loading the map). Enter a team and add a bot to your team. Use the
team order menu (by default bound to the key F3) to command the bot
to follow you. Walk around the map and see if the bot is able to
follow you everywhere.
Map bugs can sometimes cause certain places in the map to show up
'solid' in the AAS file. The bots cannot travel through these 'solid'
areas. To test for these 'solid' places set the cvar bot_testsolid
to 1 on the console. (type /set bot_testsolid 1) The map has to be
started with devmap instead of map before the cvar bot_testsolid can
be set. When the cvar is set to 1 then either "empty area" or
"SOLID area" will be printed on the screen while traveling through a map.
Several map bugs can cause these 'solid' places in the AAS file.
- Sometimes microscopic brushes are left over after a brush CSG. Search
for such brushes in the problem area and delete them.
- Tiny brush faces (not curves) can also cause problems. Due to vertex
snapping in the q3map tool those tiny brush faces can be snapped out
of existence. Such faces will not show up in Quake3 and you'll see
tiny peek holes or slits where you can view through the geometry.
Allign vertexes of and edges of adjacent brushes to remove and avoid
such tiny faces. Placing a clip brush in front of the face that is
snapped out of existence will also remove the 'solid' area but ofcourse
it's much better to remove the peek holes and slits.
- Another cause could be a brush with a collapsed side. Check how many
sides a brush has and how many sides actually have a surface. Rebuild
brushes with collapsed sides.
- All faces contained within liquid brushes using a shader without
"surfaceparm trans" set will be removed. Those contained surfaces will
not be visible and can cause the liquid to appear "solid" in the AAS file.
If you insist creating an AAS file for a map with bugs then the option
-forcesidesvisible can be used. This should fix all the problems with areas
showing up solid in the AAS file. However creating an AAS file with this
option takes a lot longer (often more than twice the normal compile time).
Clusters can be tested with the cvar bot_testclusters.
(type "/set bot_testclusters 1" on the console)
Jumppads can also be tested. Type the following on the Quake3 console
before loading your map:
/set bot_maxdebugpolys 1024
/set bot_visualizejumppads 1
/set bot_forcereachability 1
Now load the map. A counter will be shown and goes from 0% to 100%.
When the counter has reached 100% type /set bot_debug 1 and
/set r_debugSurface 2 on the console. For every jumppad the
default arch of travel (without using air control) will be visualized.
This only works if your .aas file is not optimized.
Error messages
--------------
Level designers should not worry too much about the following messages and/or warnings. The things reported are non fatal and won't cause any major problems. Some of the messages are just debug left overs.
"AAS_CheckArea: area %d face %d is flipped\n"
"AAS_CheckArea: area %d center is %f %f %f\n"
"AAS_CheckFaceWindingPlane: face %d winding plane unequal to face plane\r\n"
"AAS_CheckFaceWindingPlane: face %d winding reversed\r\n"
"area %d face %d flipped: front area %d, back area %d\n"
"area %d face %d is tiny\r\n"
"face %d and %d, same front and back area but flipped planes\r\n"
"AAS_SplitFace: tiny back face\r\n"
"AAS_SplitFace: tiny back face\r\n"
"AAS_SplitArea: front area without faces\n"
"AAS_SplitArea: back area without faces\n"
"gsubdiv: area %d has a tiny winding\r\n"
"AAS_TestSplitPlane: tried face plane as splitter\n"
"found %d epsilon faces trying to split area %d\r\n"
"AAS_SplitArea: front area without faces\n"
"AAS_GetFace: face %d had degenerate edge %d-%d\r\n"
"AAS_GetFace: face %d was tiny\r\n"
"WARNING: huge winding\n"
"bogus brush after clip"
"split removed brush"
"split not on both sides"
"two tiny brushes\r\n"
"possible portal: %d\r\n"
"portal %d: area %d\r\n"
"WARNING: CM_GridPlane unresolvable\n"
"WARNING: CM_AddFacetBevels... invalid bevel\n"
"WARNING: CM_SetBorderInward: mixed plane sides\n"
"WARNING: bevel plane already used\n"
"trigger_multiple model = \"%s\"\n"
"trigger_teleport model = \"%s\"\n"
"found a trigger_push with velocity %f %f %f\n"
"AAS_TraceBoundingBox: stack overflow\n"
"AAS_TraceAreas: stack overflow\n"
"AAS_LinkEntity: stack overflow\n"
"MergeWindings: degenerate edge on winding %f %f %f\n"
"Warning: MergeWindings: front to back found twice\n"
"FindPlaneSeperatingWindings: winding1 non-convex\r\n"
"FindPlaneSeperatingWindings: winding2 non-convex\r\n"
When one of the following messages, errors or warnings is found then there is often something to be fixed.
"WARNING! HashVec: point %f %f %f outside valid range\n"
"This should never happen!\n"
While storing the AAS file some vertex was found outside the valid map bounds. When this happens some part of the map is likely to have badly aligned brushes or weird shaped curves. Clipping off or rebuilding complex shapes often helps.
"trigger_push start solid\n"
The trigger_push start point is in solid. Try making the trigger_push brush a bit larger or move it around a bit.
"trigger_push without target entity %s\n"
Could not find the target entity of the trigger_push with the target field %s.
"trigger_push without time\n"
trigger_push entity found without "time" field.
"trigger_multiple not in any jump pad area\n"
"trigger_push not in any jump pad area\n"
A trigger_push entity was found not to be in any valid jumppad area. (the message states trigger_multiple but it should have been trigger_push) Try making the trigger_push brush a bit larger or move it around a bit.
"trigger_multiple at %1.0f %1.0f %1.0f without target\n"
A trigger multiple was found at the given coordinates without a "target" field.
"target_teleporter without target\n"
A target_teleporter entity was found without target field.
"trigger_teleport at %1.0f %1.0f %1.0f without target\n"
A trigger_teleport entity was found at the given coordinates without "target" field.
"teleporter without misc_teleporter_dest (%s)\n"
The destination of a teleporter with target field %s could not be found.
"teleporter destination (%s) without origin\n"
A teleporter destination with the target name %s was found without origin field.
"teleporter destination (%s) in solid\n"
A teleporter destination with the targetname %s was found to be in solid.
"teleported into slime or lava at dest %s\n"
A player would be pushed into slime or lave at the teleporter destination with the targetname %s.
"trigger_multiple not in any area\n"
A teleporter trigger was found not to be in any valid area. Try moving the trigger around a bit.
"func_plat without model\n"
A func_plat entity was found without model field.
"func_plat with invalid model number\n"
A func_plat entity was found with the model field set to some invalid number.
"func_bobbing without model\n"
A func_bobbing entity was found without model field.
"func_bobbing with invalid model number\n"
A func_bobbing entity was found with the model field set to some invalid number.
"%s in solid at (%1.1f %1.1f %1.1f)\n"
An item with classname %s was found to be in solid at the given coordinates.
"empty aas link heap\n"
Some part of the map has some rather complex clipping. Reduce the geometric complexity or use clip brushes to reduce the clipping complexity.
"too many entities in BSP file\n"
There are too many entities in the bsp file.
"error opening %s\n"
Could not create a new AAS file. Hard disk might be full.
"error writing lump %s\n"
Could not write an AAS lump to file. Hard disk might be full.
Version Changes
---------------
2.1h (2001-03-28)
- fixed crash bug
2.1g (2001-02-18)
- added bot_notteam support on trigger_hurt entities
2.1f (2001-02-06)
- added some AAS statistics
- don't flood through faces when creating clusters
2.1e (2001-01-10)
- fix map size limitation
2.1d (2000-12-17)
- renamed "notteam" to "bot_notteam"
2.1c (2000-11-02)
- added fs_maxfallheight
- compiled with larger map size bounds
2.1b (2000-09-15)
- fixed cfg file loading
2.1 (2000-06-28)
- added model numbers for AREACONTENTS_MOVER
- added team based func_plat, func_bobbing, trigger_teleport and trigger_push reachabilities
2.0 (2000-06-21)
- fixed swim reachabilities
- fixed some reachabilities through cluster portals
- fixed jump reachabilities
- changed some start travel times
- added travel time settings to cfg
1.9 (2000-03-27)
- fixed func_bobbing entities with origin brush
1.8 (2000-01-14)
- fixed trigger_teleport bug.
- increased max map bounds to (-8192, -8192, -8192)-(8192, 8192, 8192)
- increased max points on winding
- made "HashVec: point x y z outside valid range" non-fatal
- fixed rocket jump reachabilities
- added force sides visible option
- increased simulated stack size for area traces
1.7 (1999-12-22)
- fixed ducked bounding box size
- fixed sv_maxsteepness being zero in aas configuration
- AAS files are now automatically stored in BSP file folder
- fixed crash bug caused by overflow of a simulated stack

78
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Compile_Manual/cfgq3.c Normal file
View file

@ -0,0 +1,78 @@
//===========================================================================
// BSPC configuration file
// Quake3
//===========================================================================
#define PRESENCE_NONE 1
#define PRESENCE_NORMAL 2
#define PRESENCE_CROUCH 4
// more bounding boxes can be added if required
// always minimize the number of bounding boxes listed here to reduce AAS file size
// for instance if players cannot crouch then it's good to remove the bbox definition for it
//bounding box when running/walking
bbox //30x30x56
{
presencetype PRESENCE_NORMAL
flags 0x0000
mins {-15, -15, -24}
maxs {15, 15, 32}
}
// bounding box when crouched
bbox //30x30x40
{
presencetype PRESENCE_CROUCH
flags 0x0001
mins {-15, -15, -24}
maxs {15, 15, 16}
}
// do not forget settings as they might not be defaulted correctly when this cfg is used
settings
{
// physics settings
phys_gravitydirection {0, 0, -1} // direction of gravity
phys_friction 6 // friction
phys_stopspeed 100 // stop speed
phys_gravity 800 // gravity
phys_waterfriction 1 // friction in water
phys_watergravity 400 // gravity in water
phys_maxvelocity 320 // maximum run speed
phys_maxwalkvelocity 320 // maximum walk speed (set for running)
phys_maxcrouchvelocity 100 // maximum crouch speed
phys_maxswimvelocity 150 // maximum swim speed
phys_walkaccelerate 100 // acceleration for walking
phys_airaccelerate 0 // acceleration flying through the air
phys_swimaccelerate 0 // acceleration for swimming
phys_maxstep 18 // maximum step height
phys_maxsteepness 0.7 // maximum floor steepness a player can walk on
phys_maxwaterjump 19 // maximum height for an out of water jump
phys_maxbarrier 33 // maximum barrier a player can jump onto
phys_jumpvel 270 // jump velocity
phys_falldelta5 40 // falling delta for 5 damage ( see PM_CrashLand in game/bg_pmove.c )
phys_falldelta10 60 // falling delta for 5 damage ( see PM_CrashLand in game/bg_pmove.c )
// reachability settings
// the following are all additional travel times added
// for certain reachabilities in 1/100th of a second
rs_waterjump 400
rs_teleport 50
rs_barrierjump 100
rs_startcrouch 300
rs_startgrapple 500
rs_startwalkoffledge 70
rs_startjump 300
rs_rocketjump 500
rs_bfgjump 500
rs_jumppad 250
rs_aircontrolledjumppad 300
rs_funcbob 300
rs_startelevator 50
rs_falldamage5 300 // avoid getting 5 damage
rs_falldamage10 500 // avoid getting 10 damage
// if != 0 then this is the maximum fall height a reachability can be created for
rs_maxfallheight 0
// maximum height a bot may fall down when jumping to some location
rs_maxjumpfallheight 450
}

75
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Compile_Manual/headskins.txt Normal file
View file

@ -0,0 +1,75 @@
search orders with different settings
=====================
NON-TEAMPLAY
=====================
-------------------------------------------------
headmodel = *callisto/lily
models/players/heads/callisto/lily/head_default.skin
models/players/heads/callisto/head_lily.skin
-------------------------------------------------
headmodel = callisto/lily
models/players/callisto/lily/head_default.skin
models/players/callisto/head_lily.skin
models/players/heads/callisto/lily/head_default.skin
models/players/heads/callisto/head_lily.skin
=====================
Q3 TEAMPLAY
=====================
-------------------------------------------------
team_headmodel = *callisto/lily
team = red
models/players/heads/callisto/lily/head_red.skin
models/players/heads/callisto/head_red.skin
-------------------------------------------------
team_headmodel = callisto/lily
team = red
models/players/callisto/lily/head_red.skin
models/players/callisto/head_red.skin
models/players/heads/callisto/lily/head_red.skin
models/players/heads/callisto/head_red.skin
=====================
TA TEAMPLAY
=====================
-------------------------------------------------
team_headmodel = *callisto/lily
team = red
teamName = Stroggs
models/players/heads/callisto/lily/Stroggs/head_red.skin
models/players/heads/callisto/Stroggs/head_red.skin
models/players/heads/callisto/lily/head_red.skin
models/players/heads/callisto/head_red.skin
-------------------------------------------------
team_headmodel = callisto/lily
team = red
teamName = Stroggs
models/players/callisto/lily/Stroggs/head_red.skin
models/players/callisto/Stroggs/head_red.skin
models/players/callisto/lily/head_red.skin
models/players/callisto/head_red.skin
models/players/heads/callisto/lily/Stroggs/head_red.skin
models/players/heads/callisto/Stroggs/head_red.skin
models/players/heads/callisto/lily/head_red.skin
models/players/heads/callisto/head_red.skin

65
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Compile_Manual/index.html Normal file
View file

@ -0,0 +1,65 @@
<!DOCTYPE html PUBLIC "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Compiling Manual</title>
<style TYPE="text/css">
<!--
a:link { color: #9999FF ; text-decoration: none ; }
a:visited { color: #6666AA ; text-decoration: none ; }
a:hover { color: #6666FF ; text-decoration: none ; }
h3 { color: #FFFFFF ; }
b { color: #CCCCCC ; }
i { color: #888888 ; font-size: 10pt ; }
//-->
</style>
</head>
<body bgcolor="#000000" text="#BBBBBB">
<div align="center">
<table width="95%" cellpadding="0" cellspacing="0" border="0"><tr><td>
<div align="center">
<table width="100%" cellpadding="0" cellspacing="0" border="0">
<tr><td bgcolor="#003366" align="center">
<h3>Compiling Manual, q3map &amp; bspc help</h3>
</td></tr>
</table>
</div>
<p>
<b>Table of Contents</b>
<ol>
· <a href="q3map.html">
Q3Map Documentation
</a>
<br>· <a href="bspc.txt">
BSPC Documentation
</a>
<br>. <a href="cfgq3.c">
BSPC Configuration file
</a>
<br>. <a href="modelskins.txt">
modelskins: Q3 and TA search order for model skins
</a>
<br>. <a href="headskins.txt">
headskins: Q3 and TA search order for head skins
</a>
</ol>
</p>
<div align="center">
<table width="100%" cellpadding="1" cellspacing="0" border="0">
<tr><td bgcolor="#003366" align="right">
<i>Last updated: Jan 21, 2002 &nbsp;</i>
</td></tr>
</table>
</div>
</tr></td></table>
</div>
</body>
</html>

73
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Compile_Manual/modelskins.txt Normal file
View file

@ -0,0 +1,73 @@
search orders with different settings
=====================
NON-TEAMPLAY
=====================
-------------------------------------------------
model = hunter/harpy
legs:
models/players/hunter/lower_harpy_default.skin
models/players/hunter/lower_harpy.skin
models/players/characters/james/lower_harpy_default.skin
models/players/characters/james/lower_harpy.skin
torso:
models/players/hunter/upper_harpy_default.skin
models/players/hunter/upper_harpy.skin
models/players/characters/hunter/upper_harpy_default.skin
models/players/characters/hunter/upper_harpy.skin
=====================
Q3 TEAMPLAY
=====================
-------------------------------------------------
team_model = hunter/harpy
team = red
legs:
models/players/hunter/lower_harpy_red.skin
models/players/hunter/lower_red.skin
models/players/characters/hunter/lower_harpy_red.skin
models/players/characters/hunter/lower_red.skin
torso:
models/players/hunter/upper_harpy_red.skin
models/players/hunter/upper_red.skin
models/players/characters/hunter/upper_harpy_red.skin
models/players/characters/hunter/upper_red.skin
=====================
TA TEAMPLAY
=====================
-------------------------------------------------
team_model = james/badass
team = red
teamName = Stroggs
legs:
models/players/james/Stroggs/lower_badass_red.skin
models/players/james/Stroggs/lower_red.skin
models/players/james/lower_badass_red.skin
models/players/james/lower_red.skin
models/players/characters/james/Stroggs/lower_badass_red.skin
models/players/characters/james/Stroggs/lower_red.skin
models/players/characters/james/lower_badass_red.skin
models/players/characters/james/lower_red.skin
torso:
models/players/james/Stroggs/upper_badass_red.skin
models/players/james/Stroggs/upper_red.skin
models/players/james/upper_badass_red.skin
models/players/james/upper_red.skin
models/players/characters/james/Stroggs/upper_badass_red.skin
models/players/characters/james/Stroggs/upper_red.skin
models/players/characters/james/upper_badass_red.skin
models/players/characters/james/upper_red.skin

410
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Compile_Manual/q3map.html Normal file
View file

@ -0,0 +1,410 @@
<!DOCTYPE html PUBLIC "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>Q3Map Manual</title>
<style TYPE="text/css">
<!--
a:link { color: #9999FF ; text-decoration: none ; }
a:visited { color: #6666AA ; text-decoration: none ; }
a:hover { color: #6666FF ; text-decoration: none ; }
h3 { color: #FFFFFF ; }
b { color: #CCCCCC ; }
i { color: #888888 ; font-size: 10pt ; }
//-->
</style>
</head>
<body bgcolor="#000000" text="#BBBBBB">
<p align="center">Q3map Manual</p>
</font>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%">
<p><font size="3">q3map command line switches:</font></p>
<pre>
q3map
-----
-threads &lt;number&gt;
Number of threads used to compile the map. For the fastest compile
times the number of threads is set to the number of system processors.
-glview
Write a .gl file of the bsp tree for debugging.
-v
Output verbose information.
-draw
Enable realtime debug drawing output.
-nowater
Water, slime and lava brushes are not compiled and won't show up when running the map in Quake.
-noopt
unused.
-nofill
unused.
-nodetail
Detail brushes are not compiled and won't show up when running the map in Quake.
-fulldetail
Detail brushes will be treated as normal brushes.
-onlyents
Only change the entities in a .bsp using a .ent file.
-onlytextures
Only change the textures in a .bsp file.
-micro
unused.
-nofog
Visible surfaces that cross fog boundaries will not be split along the bound.
This can cause visually incorrect fog in the map.
-nosubdivide
Visible surfaces are not subdivided as required by shader tesselation.
The shader parameter "tesssize" sets the tesselation of a surface.
-leaktest
Only test the map for leaks. If a leak is found the compilation is stopped.
-verboseentities
Output verbose information about entity sub-models.
-nocurves
Curves are not compiled and won't show up when running the map in Quake.
-notjunc
T-junctions are not fixed. This can cause tiny slits where a surface meets halfway another surface.
-expand
Expands all the brush planes and saves a new map out to allow visual inspection of the clipping bevels
-tmpout
Output files to a folder called "tmp".
-fakemap
Write out a fakemap.map This map will contain a worldspawn entity with all the world brushes.
-samplesize &lt;N&gt;
Set the lightmap pixel size to NxN units. Default 16x16.
-custinfoparms
Will enable custom surface flags (see below)
q3map -vis
----------
-threads &lt;number&gt;
Number of threads used to compile the map. For the fastest compile
times the number of threads is set to the number of system processors.
-fast
Only calculate a very loose visiblity list. It doesn't take much time to
calculate but a lot more polygons will be drawn by the Q3 engine than necesary.
-merge
Merge bsp leaves before calculating the visibility list. This will speed up
the vis calculations but mostly more polygons will be drawn by the Q3 engine
than necesary.
-nopassage
Disable the passage visibility algorithm. The passage vis is faster and a bit more
tight than the old algorithm.
-level
unused.
-v
Output verbose information.
-nosort
Don't sort the portals on complexity. Sorting mostly speeds up visibility calculations
because more complex portals can use information from less complex portals.
-saveprt
Don't delete the .prt file after creating the visibility list.
-tmpin &lt;path&gt;
Input files will be read from a folder called "tmp".
-tmpout &lt;path&gt;
Output files will be written to a folder called "tmp".
q3map -light
------------
-threads &lt;number&gt;
Number of threads used to compile the map. For the fastest compile
times the number of threads is set to the number of system processors.
-bounce &lt;N&gt; [NEW]
Enable radiosity calculation. Rediffuses the light emitted onto surfaces N
times. Will write out the BSP after every pass, so it can be cancelled.
Light reflected is the lightmap/vertex * texture color, subsampled to a certain
granularity across every lit surface. Use q3map_lightimage in a shader
to override the reflected color.
-bouncegrid [NEW]
Radiosity affects lightgrid (entity lighting).
-fast [NEW]
Enables light envelopes for area lights, speeding light up by 50x or more on
some maps. Has the side effect of dimmer maps with large numbers of dim surface
lights.
-fastgrid [NEW]
Same as fast, but only for lightgrid calculation.
-fastbounce [NEW]
Enables fast for radiosity passes only.
-cheap [NEW]
Stop calculating light at a sample when it exceeds (255, 255, 255). This may
produce odd artifacts on maps with lots of saturated colored lighting. Also,
do not use -cheap with radiosity if you wish to preserve all light emitted.
-cheapgrid [NEW]
Same as cheap, but only for lightgrid calculation.
-area &lt;scale&gt;
This scales the light intensity of area lights.
-point &lt;scale&gt;
This scales the light intensity of point lights.
-notrace
No light tracing is performed. As a result no shadows will be casted.
-patchshadows
Enable patches casting shadows.
-novertex
Don't calculate vertex lighting.
-nogrid
Don't calculate light grid for dynamic model lighting.
-smooth [NEW]
Smart version of -extra. Only subsamples lightmap pixels that are shadowed.
Produces results comparable to -extra in roughly 1/3 the time. Can also be
used with -extra or -extrawide for 16- or 48-tap sampling respectively
(smoother shadows).
-extra
Take four samples per lightmap pixel and store the average light value of these
four samples for the actual lightmap pixel.
This super sampling is used for anti-aliasing.
-extrawide
Just like -extra four samples per lightmap pixel are calculated. However the
average of 12 samples is stored per lightmap pixel.
-samplesize &lt;N&gt;
Set the lightmap pixel size to NxN units. Default 16x16.
-border
Create a debugging border around the lightmap.
-v
Output verbose information.
-nosurf
Disables surface tracing (detail brushes and patches) for shadow calculation.
-dump
Dumps prefab files when used with radiosity for each bounce.
q3map -vlight
-------------
-threads &lt;number&gt;
Number of threads used to compile the map. For the fastest compile
times the number of threads is set to the number of system processors.
-area &lt;scale&gt;
This scales the light intensity of area lights.
-point &lt;scale&gt;
This scales the light intensity of point lights.
-novertex
Don't calculate vertex lighting.
-nogrid
Don't calculate light grid for dynamic model lighting.
-nostitching
No polygon stitching before lighting.
-noalphashading
Don't use alpha shading at all.
-nocolorshading
Don't use colored alpha shading. The alpha channel will be used as if it were binary.
The light goes through or not and does not change color.
-tracelight
Use the "-light" light algorithm for all surface unless a surface
uses a shader with the shader option "q3map_vlight".
-samplesize &lt;N&gt;
Set the lightmap pixel size to NxN units. Default 16x16.
-v
Output verbose information.
</pre>
<p><font size="3">The q3map options are a subset of the shader instructions that require
recompiling of the map.</font></p>
<p><font size="3">q3map_bounce &lt;fraction&gt;</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>]
Specify a number between 0 and 1.0 (or higher) to scale the amount of light reflected in radiosity passes.
Default: 1.0</font></p>
<p><font size="3">q3map_nofast</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>]
Surfaces that emit light with this shader parameter will disable -fast optimisation. Useful for
large areas of dim sky where you want all the dim light to reach all surfaces.</font></p>
<p><font size="3">q3map_tracelight</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>] Surfaces using a shader with this option will always be lit with the
original &quot;-light&quot; light algorithm. Patches will not cast shadows on
this surface unless the shader option q3map_patchshadows is used.</font></p>
<p><font size="3">q3map_patchshadows</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>] When this option is used in conjunction with the original (-light)
lighting algorithm, surfaces with textures modified by this option will will
show shadows cast by curve patches (under normal circumstances, curve patches do
not cast shadows).</font></p>
<p><font size="3">q3map_vertexshadows</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>] By default, no shadows are cast on vertex-only lit surfaces (see
surfaceparm pointlight). Also when running Quake III Arena in vertex&nbsp; lighting
mode, no shadows are cast upon any surfaces (shadows are part of the light map).
When using this shader option shadows *will* be cast on the surface when vertex
lit. However sharp shadow edges won't be seen on the surface because light
values are only calculated at the vertexes.</font></p>
<p><font size="3">q3map_novertexshadows</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>] Shaders used for misc_models and terrain can now use
q3map_novertexshadows to disable shadows to be cast at the vertex lit surfaces.
Shadows being cast at small misc_model objects often makes sense. However
shadows on large vertex lit terrain surfaces often look bad. By default no
shadows are cast at forced vertex list surfaces ( shaders with &quot;pointlight&quot;
).</font></p>
<p><font color="#FFFFFF" size="3">q3map_forcesunlight</font></p>
<p><font color="#FFFFFF" size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [</font><font color="#FFFF00" size="3">NEW</font><font color="#FFFFFF" size="3">] No sunlight is cast at vertex lit md3 models and terrain by default.
Using this option sunlight (overbright bits created by q3map_sun option) will be
cast on these surfaces.</font></p>
<p><font size="3">q3map_vertexscale &lt;scale&gt;</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>] The light value at the vertexes of a surface using a shader with this
option is multiplied by the scale value. This is a way to lighten or darken a
vertex light only surface in comparison to other, light-map lit surfaces around
it.</font></p>
<p><font size="3">q3map_notjunc</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>] Surfaces modified by a shader with this option are not used for
tjunction fixing.</font></p>
<p><font size="3">q3map_vlight</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>] Surfaces modified by a shader with this option will always be lit with
the &quot;-vlight&quot; algorithm when q3map is used with the options &quot;-vlight
-tracelight&quot;.</font></p>
<p><font size="3">q3map_lightmapsamplesize &lt;S&gt;</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>] Surfaces using a shader with this shader option will use lightmaps with
pixel size SxS. This option can be used to produce high resolution shadows on
certain surfaces or can be used to reduce the size of lightmap data where high
resolution shadows are not required.</font></p>
<p><font size="3">q3map_lightimage &lt;image&gt;</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Image to use for the light color of a surface light instead of the image(s)
used by the shader. Color is averaged from the texture. Texture must be the same
size as the base image map.</font></p>
<p><font size="3">q3map_surfacelight &lt;value&gt;</font></p>
<p><font size="3">Sets the amount of light this surface emits.</font></p>
<p><font size="3">q3map_lightsubdivide &lt;value&gt;</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A surface light is subdivided into a bunch of point lights for the actual
lighting of the world. This parameter controls the space between those point
lights. Default value is 120.</font></p>
<p><font size="3">q3map_backsplash &lt;percent&gt; &lt;distance&gt;</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A surface light is also lit by itself using back splash point lights with a
lower intensity. The &lt;percent&gt; parameter specifies the intensity
percentage they use from the q3map_surfacelight &lt;value&gt; parameter. The
&lt;distance&gt; parameter controls the distance of these back splash lights
from the surface. You can set the &lt;percent&gt; to zero or a negative value to
disable the back splash lights.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; q3map_globaltexture</font></p>
<p><font size="3">When this option is set the texture is not aligned to the world.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; q3map_backshader &lt;shader&gt;</font></p>
<p><font size="3">&lt;shader&gt; is the path/name of the shader or texture to be used at the
back side of the surface.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; q3map_flare &lt;shader&gt;</font></p>
<p><font size="3">Creates a flare using the specified &lt;shader&gt; at the center of the
surface using a shader with this option.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; light &lt;value&gt;</font></p>
<p><font size="3">Old style flare specification always using the shader &quot;flareshader&quot;.
The &lt;value&gt; parameter is unused.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; q3map_sun &lt;red&gt; &lt;green&gt; &lt;blue&gt; &lt;intensity&gt;
&lt;degrees&gt; &lt;elevation&gt;</font></p>
<p><font size="3">Color will be normalized, so it doesn't matter what range you use. The
intensity falls off with angle but not distance. A value of 100 is a fairly
bright sun.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; degree of 0 = from the east, 90 = north, etc.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; elevation of 0 = sunrise/set, 90 = noon</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; surfaceparm pointlight</font></p>
<p><font size="3">Surfaces using a shader with this parameter will always be vertex lit</font></p>
<p><font size="3">This option can be used to reduce the lightmap data. Often used on surfaces</font></p>
<p><font size="3">that don't need any shadows.</font></p>
<p><font size="3">Surfaceparm dust</font></p>
<p><font size="3">If a player lands (jumps onto) on a surfaces using a shader with this
parameter, a put of dust will appear at the player’s feet. Note that the
worldspawn entity of that map must have an enableDust key set to a value of 1.
Note: This surfaceflag has been replaced by "surfaceparm woodsteps" in
Return to Castle Wolfenstien.</font></p>
<font FACE="Arial" SIZE="5"><b><font SIZE="4">
<p>Custom surfaceparms</p>
</font></b><font SIZE="2">
<p>With the new q3map tool you can add custom surface parameters for mods
without the need to recompile the q3map tool. These custom surfaceparms are
stored in a file called ‘custinfoparms.txt’ in the folder scripts/. An
example of this file with the new surfaceparm treacle and surfaceparm grass is
shown below.</p>
<p>// Custom Infoparms File<br>
// Custom Contentsflags<br>
{<br>
treacle 0x4000<br>
}<br>
// Custom Surfaceflags<br>
{<br>
grass 0x80000<br>
}</p>
<p>&nbsp;</p>
<b>
<p>NOTE:</b> For linux users, when using the -custinfoparms parameter q3map
first looks in your homedir, and only if it doesn't find a custinfoparms.txt
there, it uses the one stored in the</p>
<p>quake3 install dir (usually /usr/local/games).</p>
<p>&nbsp;</p>
</font><b>
<p>Content Flags</p>
</b><font SIZE="2">
<p>Contents flags are flags similar to CONTENTS_FOG in the original Q3A. These
flags define the contents of volumes inside the game (for instance lava, fog,
water, etc.).</p>
<p>If you look in the source file game/surfaceflags.h, it has defines for all
contents flags. The define is split into a name and a hexadecimal value, for
instance CONTENTS_PLAYERCLIP 0x10000. These hexadecimal values are powers of 2
and can be ored together (binary) to form a bit mask. Up to 32 contents flags
can be ored together this way.</p>
<b>
<p>Example</b>: creating a volume with treacle.</p>
<p>The following outlines how a custom contents flag can be added and used in a
mod. First open the ‘custinfoparms.txt’ file and add ‘treacle 0x4000’
to the Custom Contentsflags section as shown in the example file above (0x4000
is one of the unused values available for custom use). Next write a shader
script which uses ‘surfaceparm treacle’. Apply this new shader to all sides
of a brush in a test map. When you compile the map, add the -custinfoparms
parameter to the command line following q3map.</p>
<p>Next, add CONTENTS_TREACLE 0x4000 to the source file game/surfaceflags.h in
your mod. Now you can call the point contents function. If the point is inside
the brush with the shader using the ‘surfaceparm treacle’ then the point
contents call will return a bit mask with CONTENTS_TREACLE set. This can for
instance be used to slow down player movement when a player is inside such a
brush.</p>
<p>&nbsp;</p>
</font><b>
<p>Surface Flags</p>
</b><font SIZE="2">
<p>The surface flags are texture properties that often affect entities in
contact with surfaces using such flags. The ‘surfaceparm metalsteps’
parameter from Q3A is a good example.</p>
<p>If you look in the source file game/surfaceflags.h, it has defines for all
surface flags. The define is split into a name and a hexadecimal value, for
instance SURF_NODAMAGE 0x1. These hexadecimal values are powers of 2 and can be
ored together (binary) to form a bit mask. Up to 32 surface flags can be ored
together this way.</p>
<b>
<p>Example</b>: Making ‘footsteps on grass’ sounds</p>
<p>The following outlines how a custom surface flag can be added and used in a
mod. First open up the ‘custinfoparms.txt’ file and add 'grass 0x80000' to
the Custom Surfaceflags section as shown in the example file above (0x80000 is
the first available unused value in surfaceflags.h for surface flags). Next
write a shader script which uses a grass image and has 'surfaceparm grass’.
Create a test map with the grass shader covering the ground surface. When you
compile the map, add the -custinfoparms parameter to the command line following
q3map.</p>
<p>Next, add SURF_GRASS 0x80000 to the source file game/surfaceflags.h in your
mod. Now you'll be able to execute a trace and the trace information will be
returned in the trace_t structure. If the trace hits a surface with the grass
surfaceparm then the SURF_GRASS flag will be set in trace_t-&gt;surfaceFlags.
Such a trace can be used to trigger playing a sound of a person stepping on
grass. For a reference example, see the existing metal steps in the game code.</p>
<p>&nbsp;</p>
</font>
<p>&nbsp;</p>
</font>
<font FACE="Arial" SIZE="5">
<p>&nbsp;</font></td>
</tr>
</table>
</div>
</b>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p align="center">-27-</p>
</body>
</html>

217
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Model_Manual/model_manual.htm Normal file
View file

@ -0,0 +1,217 @@
<html>
<head>
<meta name="generator" content="HTML Tidy, see www.w3.org" />
<title>Q3A Player Characters: Putting them in the Game</title>
<link rel = "stylesheet" type = "text/css" href = "styles/q3rad.css">
</head>
<body>
<div align = "center">
<h1 class="MsoTitle">Putting New Models in Quake III Arena</h1>
Based on original notes by Paul Steed
<p>Edited by Paul Jaquays<br>
<p>Edited 12/22/99 by ps<br>
<p>QERadiant.com thanks John Hutton for re-formating this manual into a more web friendly version<br>
</div>
<hr>
The purpose of this document is to explain how to set up a model for Quake 3 Arena, create the necessary animation and conversion files, and then export it into the MD3 format required by the game. It is intended to be informative only and not a tutorial on building or animating models.
<p>The player models for Quake III Arena were built using the commercial modeling software, 3D Studio Max R2.5 (3ds Max) by
Kinetix. These models were then animated using Physique and Biped, components of a plugin for 3dsMax called Character Studio
(also by Kinetix). The following instructions assume that you will model and animate with 3dsMax and Character Studio.
<h1>1. Setting up the Files</h1>
Begin in your <i>Quake3</i> directory. If you don't have one already, create a <i>baseq3</i> directory. Inside the <i>baseq3</i> directory, create a <i>models</i> directory. Inside the models directory, create a players directory. Inside the players directory, create a directory with the name of your model (we will use [character] in this document to represent information requiring the name of the model). It is generally a good idea to create a 'work' directory under [character] so that the [character] directory itself remains uncluttered. Place all versions of your model and temp textures here, saving the [character] directory purely for the finished model files.
<h1>2. Building and Naming the Mesh</h1>
The mesh should be built keeping in mind the game engine needs three distinct body part grouping: the head, the upper body, and the lower body. These groupings can consist of different parts or sub-objects, but keep in mind too many sub-objects does impact performance and game play speed. A good rule of thumb is to consolidate your objects (i.e. attach them to each other) as long as they remain a part of a major group. For example, you decide to create a character that has its arms as separate objects for easier animation. Unless the arms or torso has different textures assigned to them go ahead and attach the arms to the torso. It may be more difficult to assign the vertices to the biped skeleton later on, but the efficiency of the model is much better. However, if you must keep the limbs detached for unique shader assignment then keep the following naming conventions in mind:
<h2>2.1 Head Geometry </h2>
All head geometry needs to begin with lower case 'H_' (h_head, h_glasses, h_hat, etc...). Keep in mind that the head has no
animations itself other than to respond to player mouse-look input.
<h2>2.2 Upper Body Geometry</h2>
All upper body geometry needs to begin with lower case 'U_' (u_torso, u_arms, u_abdomen, etc.) This is your model's torso and arms. The individual animations for the upper body are listed below.
<h2>2.3 Lower Body Geometry</h2>
All lower body geometry begins with lower case 'L_' (l_hips, l_legs, l_lfoot, l_rfoot, etc...). This is your model's buttocks, legs and feet. The individual animations for the upper body are listed below.
<h2>2.4 Tags</h2>
Tags are connection points for other model parts and represent the limited hierarchical system of the game. They include links between the three character body parts and the weapons. Keep in mind that these tags are representations of geometry so they can be animated to represent that geometry. For example, tag_head represents the head, tag_torso represents the torso and tag_weapon represents the weapon. This is important to understand since for example, any time the character is performing a locomotive animation, the upper body can and will animate independently of the lower body, using the relative position of the tag as a base or 'home' position. The tags for the body parts and weapons are named tag_weapon, tag_torso and tag_head.
<h1>3. Texturing</h1>
Once you finish building your character go ahead and attach it to your biped and do some basic test animations to make certain the mesh doesn't deform in weird ways. Turn edges, ad faces, whatever you need to do to make sure that while animating, the character retains its mesh integrity. Handing the mesh over to another artist to assign UVW's or assigning and texturing yourself without testing the animation integrity of the mesh is very risky. Major modifications after UV assignment can cost you valuable time resulting in re-assigning not just the UV's, but re-attaching the mesh to your biped as well. Once your model is ready, go ahead and apply the texture to it. Typically the textures used in Q3A consist of one 256 x 256 texture for the body and one 128 x 128 texture for the head. Keep in mind that it's best to consolidate your texture on a single page rather than break it up into smaller pages. Also some video cards cannot process a texture size larger than 256, so making a high-rez 1024 x 512 texture just won't be seen since the card will knock it down to
256 x 128 to digest it.
<h1>4. Set Up for Animation</h1>
Once the character is textured or skinned, bring the mesh back into 3dsMax (2.5) and attach it to an adjusted Biped using the Character Studio plug-in. As a rule of thumb, it's always better to just assign the mesh to the biped using the default
settings and then manually assign vertices to appropriate skeletal 'limbs'.
<h1>5. Animation</h1>
When animating the character, keep all animations in one file. It's crucial that the animations adhere to a specific order that pertains to the separate body parts as this supports our current tag system.
<p>Basically the order of animations goes: full body (animations that combine both upper and lower), upper body, and lower body. Each character file has the following animations in them and for now that's all the modeler is allowed. The division is basically death (all body parts), extraneous upper body, and dedicated locomotive animations. That way all the upper body animations can be performed at any time, separate from whatever it is that that lower body animations may be doing. There is a set number of animation types which are (in order):
<ul><li>death1 (approx. 30 frames)
<li>death2 (approx. 30 frames)
<li>death3 (approx. 30 frames)
<p><li>taunt (approx. 45 frames)
<li>weapon attack (exactly 6 frames)
<li>melee attack (exactly 6 frames)
<li>change weapon (exactly 9 frames)
<li>weapon idle (exactly 1 frame)
<li>melee idle (exactly 1 frame)
<p><li>crouched walk (approx. 10 frames)
<li>walk (approx. 15 frames)
<li>run (approx. 12 frames)
<li>backpedal (approx. 10 frames)
<li>swim (approx. 10 frames)
<li>jump forward (approx. 10 frames)
<li>jump forward-land (approx. 6 frames)
<li>jump backward (approx. 10 frames)
<li>jump backward-land (approx. 6 frames)
<li>standing idle (approx. 10 frames)
<li>crouched idle (approx. 10 frames)
<li>turn in place (approx. 8 frames)</ul>
<p>A good rule of thumb is to create an idle pose at the frame right after the final death frame. Keep this pose for the
entire lower body and center of mass of the biped up through melee idle frame since any animation by the lower body during these frames will not register during the grab process. Similarly, once the animations for the lower body start, copy the pose for the upper body at the weapon idle frame to the first frame of the crouched walk animation and don't animate the upper body at all after that frame. This allows you to more closely approximate what happens during the game where the upper body is basically just along for the ride as the lower body carries it along via the tag_torso.
<p>Keep in mind that an animation.cfg has to be generated for each character that is a direct reflection of your animation file above.
<h1>6. Setting up Tags</h1>
After the modeler is satisfied with the animations for the character, it's time to bring in the tags that up until now, have
kept in a separate file. This is milestone mark that lets the modeler know that the character is nearly complete. 'Merge'
the tags into your scene. Turn off <i>'inherit scale'</i> for the tags under the hierarchy/link command panel in Max. Then,
assign a Physique modifier (Character Studio), linking them to specific areas in the biped:
<p>tag_torso is linked to the Biped 'pelvis'
<br>tag_head is linked to the Biped 'head'.
<br>tag_weapon is linked to the right 'hand'.
<h2>6.1 Animate Body Tags</h2>
Now, go in and actually animate the tag_torso so that it matches the default position (established previously at
approximately the standing idle frame- from the top view it looks like a perfect 90 degree triangle with the base half as wide as the length, pointing forward) when appropriate. "Appropriate" means that as the character goes through the lower body animations, if the triangle is pointing anywhere else but forward, the upper body will point that way as well since to the code the upper body IS the tag. This works out to the modeler's advantage, though because even if the upper body LOOKS crazy in the animation you simply rely on the tag representation to compensate for it.
<h2>6.2 Handling Weapon Tags</h2>
Tag_weapon is a bit different. Basically there is no difference between view model weapons (the weapon as seen by the player when it is in use by his or another player) and the world model weapons (weapons as they are found rotating in the maps) in Quake III Arena. However, for visually clarity and identification, they are doubled in scale when they become seen as world models. They are the same object. This reduces the number of models needed the game and creates an overall more efficient system. Unfortunately a drawback to the system is that there can be only one firing animation for the character. Thusly all weapons need to fit within the grip of the character regardless of size or geometry. This also makes it impossible to see hands on your weapons or otherwise perform vertex animation on the weapons other than barrel rotations vis the tag system (tag_barrel).
<p>Since the placement is always the same for the character's hands on the weapons , create the animations to the point where it begins the weapon attack sequence. Then merge one of the weapon models into the character file as a guide. The weapons have a nested triangle of same dimensions as the tag_head and tag_torso triangles (each weapon in the game has this triangle saved with it. Move the weapon into a horizontal firing position (using the side view) to about where the character would be holding the weapon correctly. Then move the character's hands into the appropriate position and link the weapon to the character's right hand.
<p>When you get to the point where you bring in the tags, make a snapshot of the weapon, hide the original and simply delete all the vertices and faces of the copy of the weapon object except for the nested triangle. Rename it tag_weapon, turn off the 'inherit scale' attributes (very important), and assign Physique to it (linking it to the 'right hand' of the biped) and voila. Ready to export.
<h1>Level of Detail</h1>
Each of the Quake III Arena player characters have a base model and two lower polygon versions of the model (to help with speed issues). For use in the game, the three levels of detail are file formatted as follows:
<p><table>
<tr>
<td>[character].[file extension]</td>
<td width = 60%>This is the highest detail model for close up viewing</td>
</tr>
<tr>
<td>[character]_1.[file extension]</td>
<td width = 60%>This is a slightly lower polygon model for mid distance viewing</td>
</tr>
<tr>
<td>[character]_2.[file extension]</td>
<td width = 60%>This is the lowest polygon model for long distance viewing.</td>
</tr>
</table>
<p>Level of detail means you need to make three versions of your model to get the best performance during gameplay. Each
version needs to have the same textures assigned and same animations assigned to them in order to work in the game. The
numbers you need to shoot for are 800 faces for the highest level, 500 faces for next level and 300 for the lowest level. This works out roughly to be a 60% drop in each LOD, but your numbers will vary in order to maintain mesh integrity. Most LOD's created in Q3A were done with the plugin called MRM (multiple resolution mesh) by Intel. The stock Optimize modifier or manual optimization techniques can be applied.
<h1>8. Exporting</h1>
Once the tags are in place (also with the Physique modifier attached to them) the model is ready to export to an ase(ascii)
file.<b></b> To make the models available for use in Quake III Arena, the model was exported to a native 3dsMax ASCII format
file called an '.ase' file. This export option in Max has several check boxes to tweak and then just exports the character
with its animation data (via Character Studio) to a huge ase/ascii file. Under 'Output Options' make sure the 'Mesh Definition', 'Materials', 'Transform Animation Keys', and 'Animated Mesh' boxes are checked. Under 'Mesh Options' and 'Object Types' make sure 'Mapping Coordinates' and 'Geometric' are the only boxes checked, respectively and let it run. Your 'Time Configuration' must reflect a '0' starting point up through the last frame of your animation. The native Max exporter will rely on the time configuration as a guide on which frames to actually grab during the conversion process. Of course there will be better exporters available in the future&hellip;this is just how it was done for the characters in Q3A.
<h1>9. Animation Config File</h1>
The character's animations are controlled by an 'animation.cfg' file where the model maker specifies reference frames and frame rates. The animation.cfg file is a text file (originally created with MS Excel) which contains the frame and animation sequence data. Place this in the model's directory. Note, when the modeler is testing the model in Quake III Arena, changes to the animation.cfg can be made without having to re-grab the model&hellip;just do a 'vid_restart' at the cvar command line
prompt.
<p>Edit an animation.cfg file which matches the frame/animation sequences and place it in the character's directory. Each animation can have different frame rates that the modeler can tweak, save out in the animation.cfg, hit 'vid_restart' to see the change right away in the game (no need to re-grab the model). The file for visor is shown here below in it's entirety. You may clip this portion of the file out and use it as the basis for your own animation files.
<p><pre class = "type">
////////////////////////////////////////////////////////////////////////////////
// animation config file
sex m
headoffset 0 0 0
footsteps normal
// first frame, num frames, looping frames, frames per second
0 30 0 25 // BOTH_DEATH1
29 1 0 25 // BOTH_DEAD1
30 30 0 25 // BOTH_DEATH2
59 1 0 25 // BOTH_DEAD2
60 30 0 25 // BOTH_DEATH3
89 1 0 25 // BOTH_DEAD3
90 40 0 20 // TORSO_GESTURE
130 6 0 15 // TORSO_ATTACK (MUST NOT CHANGE -- hand animation is synced to this)
136 6 0 15 // TORSO_ATTACK2 (MUST NOT CHANGE -- hand animation is synced to this)
142 5 0 20 // TORSO_DROP (MUST NOT CHANGE -- hand animation is synced to this)
147 4 0 20 // TORSO_RAISE (MUST NOT CHANGE -- hand animation is synced to this)
151 1 0 15 // TORSO_STAND
152 1 0 15 // TORSO_STAND2
153 8 8 20 // LEGS_WALKCR
161 12 12 20 // LEGS_WALK
173 9 9 18 // LEGS_RUN
182 10 10 20 // LEGS_BACK
192 10 10 15 // LEGS_SWIM
202 8 0 15 // LEGS_JUMP
210 1 0 15 // LEGS_LAND
211 8 0 15 // LEGS_JUMPB
219 1 0 15 // LEGS_LANDB
220 10 10 15 // LEGS_IDLE
230 10 10 15 // LEGS_IDLECR
240 7 7 15 // LEGS_TURN
//////////////////////////////////////////////////////////////////</pre>
<h1>10. The Conversion Process</h1>
The models need to be run through id's custom md3 conversion/'grabber' program. The program uses the information in the Quake Data text file ([filename].qdt) to grab and convert the 3dsMax files.
<h2>10.1 The Conversion File</h2>
Create a "Quake Data" text file for the model with the extension ".qdt". The contents for our [character].qdt file would read something like:
<p>$asecanimconvert models/players/[character]/[character].ase -playerparms 92 155
<br>$asecanimconvert models/players/[character]/[character]_1.ase -lod 1 -playerparms 92 155
<br>$asecanimconvert models/players/[character]/[character]_2.ase -lod 2 -playerparms 92 155
<p><div class = "menu">10.1.1 "$asecanimconvert"</div>
This is the grabber program executable.
<p><div class = "menu">10.1.2 "models/players/[character]/[character].ase"</div>
This is the path to the model's .ase file. The program looks for files starting in your Quake3\baseq3 directory.
<p><div class = "menu">10.1.3 "-lod 1" or "-lod 2"</div>
This tells the converter that this is the first level of reduced detail for the model. The value "-lod 2" is for the second,
or lowest level of detail for the model.
<p><div class = "menu">10.1.4 "-playerparms 92 155"</div>
This tells the converter which frame the upper body anims only start (first value) and which frame the lower body only anims start (second value). The numbers here are only used as examples
<h2>10.2 Run the Conversion</i></h2>
When the qdt file is set up correctly, run the grabber by opening MSDOS command prompt, going to the quake3 directory
containing the model files and typing in 'q3data [character].qdt'
<h2>11. Review the Model</h2>
Load up Quake 3 Arena. Go to map Q3DM0 (or any map containing a mirror). Bring down the console and type "\model
[character name]". Hit your Show Score key (default is TAB). You should see your new model here. Tweak the frame rates in
your animation.cfg file and save them. Type in "\vid_restart" on the console and hit enter to see the changes.
</div>
</body>
</html>

23
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Model_Manual/styles/q3rad.css Normal file
View file

@ -0,0 +1,23 @@
body { font: 12pt "Times New Roman";
margin-left: 5mm;
margin-right: 5mm;
text-align: justify;
background: #ffffff;
color: #000000 }
h1 { font: bold 24pt Arial, Helvetica }
h2 { font: bold italic 18pt Arial, Helvetica }
.subheading { font: bold 16pt Arial, Helvetica }
:link {color: blue;
text-decoration: none; }
:visited {color: purple;
text-decoration: none; }
h6 { font: 10pt "Times New Roman" }
.MsoToc2 { font: bold small-caps 12pt "Times New Roman" }
.MsoTitle { text-align:center;
font: bold 24pt "BankGothic Md BT";
letter-spacing:2.5pt }
.heading { font: italic 10pt "Times New Roman" }
.subcontents { font: 10pt "Times New Roman" }
.tip { font: 10pt "Comic Sans MS" }
.type { font: 10pt "Courier New" }
.menu { font: 10pt Arial, Helvetica }

1040
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/New_Teams_For_Q3TA/index.html Normal file
View file

File diff suppressed because it is too large Load diff

60
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Q3AShader_Manual/appendix/appA.html Normal file
View file

@ -0,0 +1,60 @@
<html>
<head>
<title>Quake III Arena Shader Manual: Appendix A</title>
<link rel = "stylesheet" type = "text/css" href = "../styles/q3rad.css">
</head>
<body>
<h1 class = "MsoTitle">Q3Radiant Shader Manual</h1>
<i>
TTimo<br>
2001.31.08<br>
</i>
<hr>
<h1>Appendix A: usage of targetShaderName and targetShaderNewName</h1>
<p>
The targetShaderName and targetShaderNewName keys can be used with any entity
that supports the target key (the entity instance does not actually have to use
the target key for these new keys to work). If both are defined, then when the
entity decides to activate its targets, all shaders/textures in the map that
were originally the same name as the targetShaderName value, will be changed to
the targetShaderNewName value.
</p>
<p>
For example this would make it look like the red light shader is "turning on":
</p>
<p>
"targetShaderName" "textures/proto2/redlight_off"<br>
"targetShaderNewName" "textures/proto2/redlight_on"
</p>
<p>
And this would turn it back off:
</p>
<p>
"targetShaderName" "textures/proto2/redlight_off"<br>
"targetShaderNewName" "textures/proto2/redlight_off"
</p>
<p>
Note that the ORIGINAL shader name is used in both instances, not whatever it
happens to be currently. Also, of course, this will happen globally. If the
mapper wanted to affect only a certain set of red lights, he/she would need to
make a unique shader name to be used with that set.
</p>
<p>
The code that supports these keys is in G_UseTargets in g_utils.c.
</p>
<p>
For more information, see this thread:<br>
<a href="http://www.quake3world.com/ubb/Forum6/HTML/014812.html#9">
http://www.quake3world.com/ubb/Forum6/HTML/014812.html#9
</a>
</p>

126
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Q3AShader_Manual/ch01/pg1_1.htm Normal file
View file

@ -0,0 +1,126 @@
<html>
<head>
<title>Quake III Arena Shader Manual: Introduction</title>
<link rel = "stylesheet" type = "text/css" href = "../styles/q3rad.css">
</head>
<body>
<h1 class = "MsoTitle">Q3Radiant Shader Manual</h1>
<hr>
<h1>1 Preface: Making Your Own Shaders</h1>
The Manual for the Q3Radiant editor program contains a section called <b><i>Creating New Assets</i></b> that has the necessary information for setting up the files to create your own custom Quake III Arena shaders. It is recommended that you study the scripts in this document and in the individual shader scripts. Pay careful attention to syntax and punctuation. This is where you are most likely to make mistakes.
<h1><a name = "intro">2 Introduction</a></h1>
The graphic engine for <i>QuakeIII Arena</i> has taken a step forward by putting much more direct control over the surface
qualities of textures into the hands of designers and artists. In writing this manual, we have tried to define the
concepts and tools that are used to modify textures in a way that, it is hoped, will be graspable by users who already have basic knowledge ofcomputer graphics but are not necessarily computer programmers. It is not a tutorial, nor was it intended to be one.
<h2><a name = "what">2.1 What is a Shader?</a></h2>
Shaders are short text scripts that define the properties of a surface as it appears and functions in a game world (or compatible editing tool). By convention, the documents that contain these scripts usually has the same name as the texture set which contains the textures being modified (e.g; base, hell, castle, etc,). Several specific script documents have also been created to handle special cases, like liquids, sky and special effects.
<p>For <i>Quake III Arena,</i>Shader scripts are located in quake3/baseq3/scripts.
<p> A <i>Quake III Arena</i> shader file consists of a series of surface attribute and rendering instructions formatted
within braces ("{" and "}"). Below you can see a simple example of syntaxand format for a single process, including the
Q3MAP keywords or "SurfaceParameters", which follow the first bracket and a single bracketed "stage":
<p><pre class = "type">textures/liquids/lava
{
deformVertexes wave sin 0 3 0 0.1
tessSize 64
{
map textures/common/lava.tga
}
}
</pre>
<h2><a name = "conventions">2.2 Shader Name &amp; File Conventions</a></h2>
The first line is the shader name. Shader names can be up to 63 characters long. The names are often a mirror of
a pathname to a .tga file without the extension or base dir (/quake3/baseq3 in ourcase), but they do not need to be.
<p>Shaders that are only going to be referenced by the gamecode, not modeling tools, often are just a single world,
like"projectionShadow" or "viewBlood".
<p>Shaders that are used on characters or other polygon models need to mirror a .tga file, which allows the modelers to build with normal textures, then have the special effects show up when the model is loaded into the game.
<p>Shaders that are placed on surfaces in the map editor commonly mirror a .tga file, but the "qer_editorimage" shader parameter canforce the editor to use an arbitrary image for display.
<p>Shader pathnames have a case sensitivity issue - on windows, they <i>aren't</i> case sensitive, but on unix they <i>are</i>. Try to always use lowercase for filenames, and always use forward slashes "/" for directory separators.
<h2><a name = "types">2.3 Shader Types</a></h2>
The keywords that affect shaders are divided into two classes. The first class of keywords are global parameters. Some global parameters (<b>"surfaceparms."</b> And all <b>"q3map_" keywords</b>) are processed by Q3MAP, and change physical attributes of the surface that uses the shader. These attributes can affect the player. To see changes in these
parameters one must re-bsp the map.
<p>The remaining global keywords, and all Stage Specific Keywords are processed by the renderer. They are appearance changes
only and have no effect on game play or game mechanics. Changes to any of these attributes will take effect as soon as the game goes to another level or vid_restarts (type command <b>vid_restart</b> in the game console).
<p>Shader keywords are <i>not</i>case sensitive.
<p><b>IMPORTANT NOTE:</b> some of the shader commands may be order dependent, so it's good practice to place all global shader commands (keywords defined in this section) at the very beginning of the shader and to place shader stages at the end (see various examples).
<h2><a name = "concepts">2.4 Key Concepts</a></h2>
Ideally, a designer or artist who is manipulating textures with shader files has a basic understanding of wave forms and knows about mixing colored light (high school physics sort of stuff). If not, there are some concepts you need to have a
grasp on to make shaders work for you.
<p><div class = "subheading">2.4.1 Surface Effects vs. Content Effects vs. Deformation Effects</div>
Shaders not only modify the visible aspect of textures on a geometry brush, curve, patch or mesh model, but they can also have an effect on both the content, "shape," and apparent movement of those things. A surface effect does nothing to modify
the shape or content of the brush. Surface effects include glows, transparencies and rgb (red, green, blue) value
changes. Content shaders affect the way the brush operates in the game world. Examples include water, fog, nonsolid, and
structural. Deformation effects change the actual shape of the affected brush or curve, and may make it appear to move.
<p><div class = "subheading">2.4.2 Power Has a Price</div>
The shader script gives the designer, artist and programmer a great deal of easily accessible power over the appearance of
and potential special effects that may be applied to surfaces in the gameworld. But it is power that comes with a price tag
attached, and the cost is measured in performance speed. Each shader phase that affects the appearance of a texture causes the <i>Q3:A</i>engine to make another processing pass and redraw the world. Think of it as if you were adding all
the shader-affected triangles to the total r_speed count for each stage in the shader script. A shader-manipulated texture that is seen through another shader-manipulated texture (e.g. a light in fog) has the effect of <i>adding</i> the total number of passes together for the affected triangles. A light that required two passes seen through a fog that requires one pass will be treated as having to redraw that part of the world three times.
<p><div class = "subheading">2.4.3 RGB Color</div>
RGB means "Red, Green, Blue."Mixing red, green and blue light in differing intensities creates the colors in computers and television monitors. This is called <i>additive color</i> (as opposed to the mixing of pigments in paint or colored ink in the printing process, which is subtractive color). In <i>Quake III Arena</i> and most higher-end computer art programs (and the color selector in Windows), the intensities ofthe individual Red, Green and Blue components are expressed as number values. When mixed together on a screen, number values of equal intensity in each component color create a completely neutral (gray) color. The lower the number value (towards 0), the darker the shade. The higher the value, the lighter the shade or the more saturated the color until it reaches a maximum value of 255 (in the art programs). All colors possible on the computer can be expressed as a formula of three numbers. The value for complete black is 0 0 0. The value for complete white is 255 255 255. However, the <i>QuakeIII Arena</i> graphics engine requires that the color range be "normalized" into a range between 0.0 and 1.0.
<p><div class = "subheading">2.4.4 Normalization: a Scale of 0 to 1</div>
The mathematics in <i>Quake III Arena</i> use a scale of 0.0 to 1.0 instead of 0 to 255. Most computer art programs that can express RGB values as numbers use the 0 to 255 scale. To convert numbers, divide each of the artprogram's values for the component colors by 255. The resulting three values are your <i>Quake III Arena</i> formula for that color component. The same holds true for texture coordinates.
<p><div class = "subheading">2.4.5 Texture Sizes</div>
TGA texture files are measured in pixels (picture elements). Textures are measured in powers of 2, with 16 x16 pixels being the smallest (typically) texture in use. Most will be larger. Textures need not be square, so long as both dimensions are powers of 2. Examples include: 32x256, 16x32, 128x16.
<p><div class = "subheading">2.4.6 Color Math</div>
In <i>Quake III Arena</i> , colors are changed by mathematical equations worked on the textures by way ofthe scripts or
"programlets" in the shader file. An equation that adds to or multiplies the number values in atexture causes it to become
darker. Equations that subtract from or modulate number values in a texture cause it to become lighter. Either equation can change the hue and saturation of a color.
<p><div class = "subheading">2.4.7 Measurements</div>
The measurements used in the shaders are in either game units, color units, or texture units.
<p>&middot; <b>Game unit:</b> A game unit is used by deformations to specify sizes relative to the world. Game units are the same scale we have had since way back in the <i>Wolfenstein</i>days - 8 units equals one foot. The default texture scale used by the Q3Radiant map editor results in two texels for each game unit, but that can be freely changed.
<p>&middot; <b>Color units</b>: Colors scale the values generated by the texture units to produce lighting effects. A value of 0.0 will be completely black, and a value of 1.0 will leave the texture unchanged. Colors are sometimes specified with a single value to be used across all red, green,and blue channels, or sometimes as separate values for each channel.
<p>&middot; <b>Texture units:</b> This is the normalized (see above) dimensions of the original texture image (or a previously modified texture at a given stage in the shader pipeline). A full texture, regardless of its original size in texels, has a normalized measurement of 1.0 x 1.0. For normal repeating textures, it is possible to have value greater than 1.0 or less than 0.0, resulting in repeating of the texture. The coordinates are usually assigned by the level editor or
modeling tools, but you still need to be aware of this for scrolling or turbulent movement of the texture at runtime.
<p><div class = "subheading">2.4.8 Waveform Functions</div>
Many of the shader functions use waveforms to modulate measurements over time. Where appropriate, additional information is provided with wave modulated keyword functions to describe the effect of a particular waveform on that process. Currently there are five waveforms in use in <i>Q3A</i> shaders:
<p><b>Sin</b>: Sin standsfor sine wave, a regular smoothly flowing wave ranging from -1 to 1.
<br><b>Triangle:</b> Triangle is a wave with a sharp ascent and a sharp decay, ranging from 0 to 1.It will make a choppy looking wave forms.
<br><b>Square</b>: A squarewave simply switches from -1 to 1 with no in-between.
<br><b>Sawtooth:</b> In the sawtooth wave, the ascent is like a triangle wave from 0 to 1, but the decay cuts off sharply back to 0.
<br><b>Inversesawtooth:</b> This is the reverse of the sawtooth&hellip; instant ascent to the peak value (1), then a triangle wave descent to the valley value (0). The phase on this goes from 1.0 to 0.0 instead of 0.0 to 1.0. This wave is particularly usefulfor additive cross-fades.
<p><b>Waveforms all have thefollowing properties</b>:
<br><b>&lt;base&gt;</b> Where the wave form begins. Amplitude is measured from this base value.
<br><b>&lt;amplitude&gt;</b> This is the height of the wave created, measured from the base<b>.</b> You will probably need to test and tweak this value to get it correct for each new shader stage. The greater the amplitude, the higher the wave peaks and the deeper the valleys.
<br><b>&lt;phase&gt;</b> This is a normalized value between 0.0 and 1.0. Changing phase to a non-zero value affects the point on the wave at which the wave form initially begins to be plotted. Example: In Sin or Triangle wave, a phase of 0.25 means it begins one fourth (25%) of the way along the curve, or more simply put, it begins at the peak of the wave. A phaseof 0.5 would begin at the point the wave re-crosses the base line. A phase of 0.75 would be at the lowest point of the valley. If only one wave form is being used in a shader, a phase shift will probably not be noticed and phase should have a value of zero (0). However, including two or more stages of the same process in a single shader, but with the phases shifted can be used to create interesting visual effects. Example: using rgbGen in two stages with different colors and a 0.5 difference in phase would cause the manipulated texture to modulate between two distinct colors. Phase changes can also be used when you have two uses of the same effect near each other, and you don't want them to be synchronized. You would write a separate shader for each, changing only the phase value.
<br><b>&lt;freq&gt;</b>Frequency. This value is expressed as repetitions or cycles of the wave per second. A value of 1
would cycle once per second. A value of 10 would cycle 10 times per second. A value of 0.1 would cycle once every 10
seconds.
<p align = "center">Back | <a href = "../index.htm">Home</a> | <a href = "../ch02/pg2_1.htm">Next</a>
</body>
</html>

222
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Q3AShader_Manual/ch02/pg2_1.htm Normal file
View file

@ -0,0 +1,222 @@
<html>
<head>
<title>Quake III Arena Shader Manual: General Shader Keywords</title>
<link rel = "stylesheet" type = "text/css" href = "../styles/q3rad.css">
</head>
<body>
<h1 class = "MsoTitle">Q3Radiant Shader Manual</h1>
<hr>
<h1>3 General Shader Keywords</h1>
<b>IMPORTANT NOTE:</b> Once again, be aware that some of the shader commands may be order dependent, so it's good practice to place all global shader commands (keywords defined inthis section) at the very beginning of the shader and to place shader stages at the end (see various examples).
<p>These Keywords are global to a shader and affect all stages. They are also ignored by Q3MAP.
<h2><a name = "skyparms">3.1 skyParms &lt;farbox&gt; &lt;cloudheight&gt; &lt;nearbox&gt;</a></h2>
Specifies how to use the surface as a sky, including an optional far box (stars, moon, etc), optional cloud layers with any shader attributes, and an optional near box (mountains in front of the clouds, etc).
<p><b>&lt;farbox&gt;</b> Specifies a set of files to use as an environment box behind all cloudlayers. Specify "-" for no
farbox, or a file base name. A base name of "env/test" would look for files "env/test_rt.tga", "env/test_lf.tga",
"env/test_ft.tga", "env/test_bk.tga", "env/test_up.tga", "env/test_dn.tga" to use as the right / left / front / back / up /
down sides.
<br><b>&lt;cloudheight&gt;</b> controls apparent curvature of the cloud layers - lower numbers mean more curvature (and thus more distortion at the horizons). Higher height values create "flatter" skies with less horizon distortion. Think of height
as the radius of a sphere on which the clouds are mapped. Good ranges are 64 to 256. The default value is 128.
<br><b>&lt;nearbox&gt;</b> Specified as farbox, to be alpha blended ontop of the clouds. This has not be tested in a long time, so it probably doesn't actually work. Set to "-" to ignore.
<p><div class = "tip"><strong>Design Notes:</strong>
<ul><li>If you are making a map where the sky is seen by looking up most of the time, use a lower cloudheight value. Under those circumstances the tighter curve looks more dynamic. If you are making a map where the sky is seen by looking out windows most of the time or has a map area that is open to the sky on one or more sides, use a higher height to make the clouds seem more natural.
<li>It is possible to create a sky with up to 8 cloudlayers, but that also means 8 processing passes and a potentially large processing hit.
<li>Be aware that the skybox does not wrap around the entire world. The "floor" or bottom face of the skybox is not drawn by the game. If a player in the game can see that face, they will see the "hall of mirrors" effect.</ul></div>
<p align = "center"><strong>Example: Sky script</strong>
<div><pre class = "type">textures/skies/xtoxicsky_dm9
{
qer_editorimage textures/skies/toxicsky.tga
surfaceparm noimpact
surfaceparm nolightmap
q3map_globaltexture
q3map_lightsubdivide 256
q3map_surfacelight 400
surfaceparm sky
q3map_sun 1 1 0.5 150 30 60
skyparms full 512 -
{
map textures/skies/inteldimclouds.tga
tcMod scroll 0.1 0.1
tcMod scale 3 2
}
{
map textures/skies/intelredclouds.tga
blendFunc add
tcMod scroll 0.05 0.05
tcMod scale 3 3
}
}</pre>
</div>
<h2><a name = "cull">3.2 cull &lt;side&gt;</a></h2>
Every surface of a polygon has two sides, a front and a back. Typically, we only see the front or "out" side. For
example, a solid block you only show the front side. In many applications we see both. For example, in water, you can see both front and a back. The same is true for things like grates and screens.
<p>To "cull" means to remove. The value parameter determines the type of face culling to apply. The default value is cull <i>front</i> if this keyword is not specified. However for items that should be inverted then the value <i>back</i> should be used. To disable culling, the value <i>disable</i> or<i>none</i> should be used. Only one cull instruction can be set
for the shader.
<p><div class = "subheading">3.2.1 cull front</div>
The front or "outside" of the polygon is not drawn in the world. This is the default value. It is used if the keyword "<b>cull</b> " appears in the content instructions without a <b>&lt;side&gt;</b>value or if the keyword cull does not appear at all in the shader.
<p><div class = "subheading">3.2.2 cull back</div>
Cull back removes the back or "inside" of a polygon from being drawn in the world.
<p><div class = "subheading">3.2.3 cull disable, cull none</div>
Neither side of the polygon is removed. Both sides are drawn in the game. Very useful for making panels or barriers that
have no depth, such as grates, screens, metal wire fences and so on and for liquid volumes that the player can see from within. Also used for energy fields, sprites, and weapon effects (e.g. plasma).
<p><div class = "tip"><strong>Design Notes:</strong> For things like grates and screens, put the texture with the cull none property on one face only. On the other faces, use a non-drawing texture.</div>
<h2><a name = "deform">3.3 deformVertexes</a></h2>
This function performs a general deformation on the surface's vertexes, changing the actual shape of the surface before drawing the shader passes. You can stack multiple deformVertexes commands to modify positions in more complex ways, making an object move in two dimensions, for instance.
<p><div class = "subheading">3.3.1
deformVertexes wave &lt;div&gt; &lt;func&gt;
&lt;base&gt;&lt;amplitude&gt; &lt;phase&gt; &lt;freq&gt;</div>
Designed for water surfaces, modifying the values differently at each point. It accepts the standard wave functions of the type <b>sin</b>,<b>triangle</b>, <b>square, sawtooth</b> or<b>inversesawtooth</b> . The "div" parameter is used to
control the wave "spread" - a value equal to the tessSizeof the surface is a good default value (tessSize is subdivision size, in game units, used for the shader when seen in the game world).
<p><div class = "subheading">3.3.2
deformVertexes normal &lt;div&gt; &lt;func&gt;
&lt;base&gt;&lt;amplitude ~0.1-~0.5&gt; &lt;frequency
~1.0-~4.0&gt;</div>
This deformation affects the normals of a vertex without actually moving it, which will effect later shader options like
lighting and especially environment mapping. If the shader stages don't use normals in any of their calculations, there will
be novisible effect.
<p><div class = "tip"><strong>Design Notes:</strong> Putting values of 0.1 to 0.5 in Amplitude and 1.0 to 4.0 in the Frequency can produce some satisfying results. Some things that have been done with it: A small fluttering bat, falling leaves, rain, flags.</div>
<p><div class = "subheading">3.3.3
deformVertexes bulge &lt;bulgeWidth&gt;
&lt;bulgeHeight&gt;&lt;bulgeSpeed&gt;</div>
This forces a bulge to move along the given <b>s</b> and <b> t</b> directions. Designed for use on curved pipes.
<p><strong>Specific parameter definitions for deform keywords:</strong>
<br><b>&lt;div&gt;</b> This is roughly defined as the size of the waves that occur. It is measured in game units. Smaller
values create agreater density of smaller wave forms occurring in a given area. Larger values create a lesser density of waves, or otherwise put, the appearance of larger waves. To look correct this value should closely correspond to the value (in pixels) set for tessSize (tessellation size) of the texture. A value of 100.0 is a good default value (which means your tessSize should be close to that for things tolook "wavelike").
<br><b>&lt;func&gt;</b> This is the type of wave form being created. Sin stands for sine wave, a regular smoothly flowing
wave. Triangle is a wave with a sharp ascent and a sharp decay. It will make a choppy looking wave forms. A square
wave is simply on or off for the period of the frequency with no in between. The sawtooth wave has the ascent of a triangle wave, but has the decay cut off sharply like a square wave. An inversesawtooth wave reverses this.
<br><b>&lt;base&gt;</b> This is the distance, in game units that the apparent surface of the texture is displaced from the
actual surface of the brush as placed in the editor. Apositive value appears above the brush surface. A negative value appears below the brush surface. An example of thisis the Quad effect, which essentially is a shell with a positive base value to stand it away from the model surface and a 0 (zero) value for amplitude.
<br><b>&lt;amplitude&gt;</b> The distance that the deformation moves away from the base value. See Wave Forms in the introduction for a description of amplitude.
<br><b>&lt;phase&gt;</b> SeeWave Forms in the introduction for a description of phase)
<br><b>&lt;frequency&gt;</b> See Wave Forms in the introduction for a description of frequency)
<p><div class = "tip"><strong>Design Note:</strong> The div and amplitude parameters, when used in conjunction with liquid volumes like water should take into consideration how much the water will be moving. A large ocean area would have have massive swells (big div values) that rose and fell dramatically (big amplitude values). While a small, quiet pool may move very little.</div>
<p><div class = "subheading">3.3.4 <i>
deformVertexes move&lt;x&gt; &lt;y&gt; &lt;z&gt; &lt;func&gt;
&lt;base&gt; &lt;amplitude&gt; &lt;phase&gt; &lt;freq&gt;</i></div>
This keyword is used to make a brush, curve patch or md3model appear to move together as a unit. The &lt;x&gt; &lt;y&gt;
and &lt;z&gt; values are the distance and direction in game units the object appears to move relative to it's point of origin in the map.
<p>The &lt;func&gt; &lt;base&gt; &lt;amplitude&gt;&lt;phase&gt; and &lt;freq&gt; values are the same as found in other wave
form manipulations.
<p>The product of the function modifies the values x, y, and z.Therefore, if you have an amplitude of 5 and an x value of 2, the object will travel 10 units from its point of origin along the x axis. This results in a total of 20 units of motion along the x axis, since the amplitude is the variation both above and below the base.
<p>It must be noted that an object made with this shader does not actually change position, it only appears to.
<p><div class = "tip"><b>Design Note:</b> If an object is made up of surfaces with different shaders, all must have matching deformVertexes move values or the object will appear to tear itself apart.</div>
<p><div class = "subheading">3.3.5
DeformVertexes autosprite</div>
This function can be used to make any given triangle quad (pair of triangles that form a square rectangle) automatically behave like a sprite without having to make it a separate entity. This means that the "sprite" on which the texture is placed will rotate to always appear at right angles to the player's view as a sprite would. Any four-sided brush side, flat patch, or pair of triangles in an .md3 model can have the <b>autosprite</b> effect on it. <b>The brush face containing a texture with this shader keyword must besquare.</b>
<p><div class = "tip"><b>Design Note</b> :This is best used on objects that would appear the same regardless of viewing angle. An example might be a glowing light flare.</div>
<p><div class = "subheading">3.3.6
DeformVertexes autosprite2</div>
Is a slightly modified "sprite" that only rotates around the middle of its longest axis. This allows you to make a
pillar of fire that you can walk around, or an energy beam stretched across the room.
<h2><a name = "fogparms">3.4 fogparms &lt;red
value&gt; &lt;green value&gt; &lt;bluevalue&gt; &lt;distance to
Opaque&gt;</a></h2>
<p>Note: you must also specify "surfaceparm fog" to cause q3map to identify the surfaces inside the volume. Fogparms only
describes how to render the fog on the surfaces.
<p><b>&lt;red value&gt; &lt;green value&gt; &lt;blue value&gt;</b> These are normalized values. A good computer art program should give you the RGB values for a color. To obtain the values that define fog color for Quake III Arena, divide the desired color's Red, Green and Blue values by 255 to obtain three normalized numbers within the 0.0 to 1.0 range.
<br><b>&lt;distance toopaque&gt;</b> This is the distance, in game units, until the fog becomes totally opaque, as measured from the point of view of the observer. By making the height of the fog brush shorter than the distance to opaque, the apparent density of the fog can be reduced (because it never reaches the depth at which full opacity occurs).
<ul><li>The fog volume can only have one surface visible (from outside the fog).
<li>Fog must be made of one brush. It cannot be made of adjacent brushes.
<li>Fog brushes must be axial. This means that only square or rectangular brushes may contain fog, and those must have their edges drawn along the axes of the map grid (all 90 degree angles).
</ul>
<p><div class = "tip"><strong>Design Notes:</strong>
<ul><li>If a water texture contains a fog parameter, it must be treated as if it were a fog texture when in use.
<li>If a room is to be filled completely with a fog volume,it can only be entered through one surface (and still have the fog function correctly).
<li>Additional shader passes may be placed on a fog brush, as with other brushes.</ul></div>
<h2><a name = "nopicmip">3.5 nopicmip</a></h2>
This causes the texture to ignore user-set values for the <b>r_picmip</b> cvar command. The image will always be high
resolution. Example: Used to keep images and text in the heads up display from blurring when user optimizes the game graphics.
<h2><a name = "nomipmaps">3.6 nomipmaps</a></h2>
This implies nopicmip, but also prevents the generation of any lower resolution mipmaps for use by the 3d card. This will
cause the texture to alias when it gets smaller, but there are some cases where you would rather have this than a blurry image. Sometimes thin slivers of triangles force things to very low mipmap levels, which leave a few constant pixels on otherwise scrolling special effects.
<h2><a name = "polygon">3.7 polygonOffset</a></h2>
Surfaces rendered with the <b>polygonOffset</b> keyword are rendered slightly off the polygon's surface. This is typically
used for wall markings and "decals." The distance between the offset and the polygon is fixed. It is not a variable in QuakeIII Arena.
<h2><a name = "portal">3.8 portal</a></h2>
Specifies that this texture is the surface for a portal or mirror. In the game map, a portal entity must be placed directly in front of the texture (within 64 game units). All this does is set "sortportal", so it isn't needed if you specify
that explicitly.
<h2><a name = "sort">3.9 sort &lt;value&gt;</a></h2>
Use this keyword to fine-tune the depth sorting of shaders as they are compared against other shaders in the game world. The
basic concept is that if there is a question or a problem with shaders drawing in the wrong order against each other, this allows the designer to create a hierarchy ofwhich shader draws in what order.
<p>The default behavior is to put all blended shaders in sort "additive" and all other shaders in sort "opaque", so you only
need to specify this when you are trying to work around a sorting problem with multiple transparent surfaces in a scene.
<p>The value here can be either a numerical value or one of the keywords in the following list (listed in order of ascending priority):
<ul><b>portal (1):</b> This surface is a portal, it draws over every other shader seen inside the portal, but before anything in the main view.
<br><b>Sky (2):</b> Typically, the sky is the farthest surface in the game world. Drawing this after other opaque surfaces can be an optimization on some cards. This currently has the wrong value for this purpose, so it doesn't do much of anything.
<br><b>Opaque (3):</b>This surface is opaque (rarely needed since this is the default with noblendfunc)
<br><b>Banner (6) :</b>Transparent, but very close to walls.
<br><b>Underwater (8):</b> Draw behind normal transparent surfaces.
<br><b>Additive (9):</b> normal transparent surface (default for shaders with blendfuncs)
<br><b>nearest (16):</b>this shader should always sort closest to the viewer, e.g. muzzle flashes and blend blobs</ul>
<p align = "center"><a href = "../ch01/pg1_1.htm">Back</a> | <a href = "../index.htm">Home</a> | <a href = "../ch03/pg3_1.htm">Next</a>
</body>
</html>

197
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Q3AShader_Manual/ch03/pg3_1.htm Normal file
View file

@ -0,0 +1,197 @@
<html>
<head>
<title>Quake III Arena Shader Manual: Specific Shader Keywords</title>
<link rel = "stylesheet" type = "text/css" href = "../styles/q3rad.css">
</head>
<body>
<h1 class = "MsoTitle">Q3Radiant Shader Manual</h1>
<hr>
<h1>4 Q3MAP Specific Shader Keywords</h1>
These keywords change the physical nature of the textures and the brushes that are marked with them. Changing any of these values will require the map to be re-compiled. These are global and affect the entire shader.
<h2><a name = "tessSize">4.1 tessSize &lt;amount&gt;</a></h2>
For consistency's sake, this really should have been called q3map_tessSize. But it wasn't. The tessSize shader controls
the tessellation size (how finely a surface is chopped up in to triangles), in game units, of the surface. This is only
applicable to solid brushes, not curves, and is generally only used on surfaces that are flagged with the <b>deformVertexes</b> keyword. Abuse of this can create a huge number of triangles. This happens during q3map processing, so maps must be reprocessed for changes to take effect.
<p><div class = "tip"><b>Design Note:</b> It can also be used on tesselating surfaces to make sure that tesselations arelarge, and thus, less costly in terms of triangles created.</div>
<h2><a name = "backshader">4.2 q3map_backshader &lt;shadername&gt;</a></h2>
This allows a brush to use a different shader when you are inside it looking out. By way of example, this would allow a water brush (or other) surfaces to have a different sort order (see <b><i>sort</i></b> above) or appearance when seen from the inside.
<h2><a name = "globaltex">4.3 q3map_globaltexture</a></h2>
Use this shader in the global keyword commands whenever the <b>tcMod scale</b> function is used in one of the later render stages. Many problems with getting shader effects to work across multiple adjacent brushes are a result of the way q3map optimizes texture precision. This option resolves that, but at the expense of some precision of the textures when they are far away from the origin of the map.
<h2><a name = "mapsun">4.4 q3map_sun &lt;red&gt; &lt;green&gt; &lt;blue&gt; &lt;intensity&gt; &lt;degrees&gt; &lt;elevation&gt;</a></h2>
This keyword in a sky shader will create the illusion of light cast into a map by a single, infinitely distance light source (sun, moon, hellish fire, etc.). This is only processed during the lighting phase of q3map.
<p><b>&lt;red&gt;&lt;green&gt; &lt;blue&gt;</b> Color is described by three normalized rgbvalues. Color will be normalized to a 0.0 to 1.0 range, so it doesn't matter what range you use.
<br><b>&lt;intensity&gt;</b> is the brightness of the generated light. A value of 100 is a fairly bright sun. The
intensity of the light falls off with angle but not distance.
<br><b>&lt;degrees&gt;</b> is the angle relative to the directions on the map file. A setting of 0 degrees equals east. 90
isnorth, 180 is west and 270 is south.
<br><b>&lt;elevation&gt;</b> is the distance, measured in degrees from the horizon (z value of zero in the map file). An
elevation of 0 is sunrise/sunset. An elevation of 90 is noon.
<p><div class = "tip"><b>DESIGN NOTE:</b> Sky shaders should probably still have a<b>q3map_surfacelight</b> value. The "sun" gives a strong directional light, but doesn't necessarily give the fill light needed to soften and illuminate shadows. Skies with clouds should probably have a weaker <b>q3map_sun</b>value and a higher <b>q3map_surfacelight</b> value. Heavy clouds diffuse light and weaken shadows. The opposite is true of a cloudless or nearly cloudless sky. Insuch cases, the "sun" or "moon" will cast stronger, shadows that have a greater degree of contrast.
<p><b>Design Trick:</b> Not certain what color formula you want to use for the sun's light? Try this. Create a light entity. Use the Q3Radiant editor's color selection tools to pick a color. The light's _color key's value will be the normalized RGB formula. Copy it from the value line in the editor (CTRL+c) and paste it into your shader.</div>
<h2><a name = "surflight">4.5 q3map_surfaceLight &lt;light value&gt;</a></h2>
The texture gives off light equal to the <b>&lt;light value&gt;</b> set for it. The relative surface area of the texture in the world affects the actual amount of light that appears to be radiated. To give off what appears to be the same amount
of light, a smaller texture must be significantly brighter than a larger texture. Unless the qer_lightimage keyword is used to select a different source for the texture's light color information, the color of the light will be the averaged color of the texture.
<h2><a name = "lightimg">4.6 q3map_lightimage &lt;texturepath/texturename&gt;</a></h2>
The keyword <b>q3map_lightimage</b> generates lighting from the average color of the TGA image specified by the
q3map_lightimage.
<p>The keyword sequence for generating light on a <b>q3map_surfacelight</b> should be ordered as follows:
<ol><li><b>q3map_lightimage</b> ; (the texture providing the light and the color of the light)
<li><b>qer_editorimage</b> ; (the editor-only image used to select the source map for the texture)
<li>the average color of the light emitted from the shader is calculated from the <b>lightimage.</b>)</ol>
<p>The reason <b>q3map_lightimage</b>is specified for the light in the example below, is because the blend map is predominantly yellow, and the designer wanted more yellow light to be emitted from the light.
<p align = "center"><strong>Example: Taking light from another source texture</strong>
<p><pre class = "type">
textures/eerie/ironcrosslt2_10000
{
q3map_lightimagetextures/gothic_light/ironcrosslt2.blend.tga
// this TGA is the source for the color of the blended light
qer_editorimagetextures/gothic_light/ironcrosslt2.tga
//base TGA (used because the shader is used with several
// different light values
q3map_surfacelight 10000
//emitted light value of10,000
{
map $lightmap
//source texture is affected by the lightmap
rgbGen identity
// this command handles the overbright bits created by "sunlight"
// in the game
}
{
maptextures/gothic_light/ironcrosslt2.tga
blendFunc filter
rgbGen identity
}
{
maptextures/gothic_light/ironcrosslt2.blend.tga
blendFunc add
}
}
</pre>
<h2><a name = "lightsub">4.7 q3map_lightsubdivide &lt;value&gt;</a></h2>
This allows the user to define how large, or small to make the subdivisions (triangles) in a textured surface, particularly aimed at light-emitting textures like skies. It defaults to 120 game units, but can be made larger (256 or 512) for sky boxes or smaller for light surfaces at the bottoms of cracks. This can be a dominant factor in processing time for q3map lighting.
<h2><a name = "surfparm">4.8 surfaceparm &lt;parm&gt;</a></h2>
<p>All surfaceparm keywords are preceded by the word surfaceparm as follows: <b>surfaceparm fog</b>or <b>surfaceparm noimpact.</b>
<p><div class = "subheading">4.8.1 alphashadow</div>
This keyword applied to a texture on a brush, patch or model will cause the lighting phase of the q3map process to use the texture's alpha channel as a mask for casting static shadows in the game world.
<p><div class = "tip"><b>Design Note:</b> Alphashadow does not work well with fine line detail on a texture. Fine lines may not cast acceptable shadows. It appears to work best with well-defined silhouettes and wider lines within the texture. Most of our tattered banners use this to cast tattered shadows.</div>
<p><div class = "subheading">4.8.2 areaportal</div>
A brush marked with this keyword functions as an area portal, a break in the Q3MAP tree. It is typically placed on a very thin brush placed inside a door entity (but is not a part of that entity). The intent is to block the game from processing
surface triangles located behind it when the door is closed. It is also used by the BSPC (bot area file creation compiler) in the same manner as a clusterportal. The brush must touch all the structural brushes surrounding the <b>
areaportal</b>.
<p><div class = "subheading">4.8.3 clusterportal</div>
A brush marked with this keyword function creates a subdivision of the area file (.aas) used by the bots for navigation. It
is typically placed in locations that are natural breaks in a map, such a sentrances to halls, doors, tunnels, etc. The intent is keep the bot from having to process the entire map at once. As with the the areaportal parameter, the affected brush must touch all the structural brushes surrounding the <b>areaportal</b>.
<p><div class = "subheading">4.8.4 donotenter</div>
Read as "do not enter." Like clusterportal, this is a bot-only property. A brush marked with donotenter will not affect
non-bot players, but bots will not enter it. It should be used only when bots appear to have difficulty navigating around some map features.
<p><div class = "subheading">4.8.5 flesh</div>
This will cue different sounds (in a similar manner to metalsteps) and cause blood to appear instead of bullet impact flashes.
<p><div class = "subheading">4.8.6 fog</div>
Fog defines the brush as being a "fog" brush. This is a Q3MAP function that chops and identifies all geometry inside the
brush. The General shader keyword fogparms must also be specified to tell how to draw the fog.
<p><div class = "subheading">4.8.7 lava</div>
<p>Assigns to the texture the game properties set for lava. This affects both the surface and the content of a brush.
<p><div class = "subheading">4.8.8 metalsteps</div>
The player sounds as if he is walking on clanging metal steps or gratings. Other than specifiying <b>flesh</b>, <b>metalsteps</b>, <b>nosteps</b>, or default (i.e. specify nothing) it is currently not possible for a designer to create or assign a specific sound routine to a texture. Note: If no sound is set for a texture, then the default footsteps sound routines are heard.
<p><div class = "subheading">4.8.9 nodamage</div>
The player takes no damage if he falls onto a texture with this surfaceparm
<p><div class = "subheading">4.8.10 nodlight</div>
Read as "No <i>Dee</i>Light". A texture containing this parameter will not be affected or lit by dynamic lights, such as
weapon effects. And example in <i>Quake III Arena</i> would be solid lava.
<p><div class = "subheading">4.8.11 nodraw</div>
A texture marked with nodraw will not visually appear in the game world. Most often used for triggers, clip brushes, origin
brushes, and so on.
<p><div class = "subheading">4.8.12 nodrop</div>
When a player dies inside a volume (brush) marked nodrop, no weapon is dropped. The intend use isfor "Pits of Death." Have a kill trigger inside a nodrop volume, and when the players die here, they won't drop their weapons. The intent is to prevent unnecessary polygon pileups on the floors of pits.
<p><div class = "subheading">4.8.13 noimpact</div>
World entities will not impact on this texture. No explosions occur when projectiles strike this surface and no marks
will be left on it. Sky textures are usually marked with this texture so those projectiles will not hit the sky and leave
marks.
<p><div class = "subheading">4.8.14 nomarks</div>
Projectiles will explode upon contact with this surface, but will not leave marks. Blood will also not mark this surface.
This is useful to keep lights from being temporarily obscured by battle damage.
<p><div class = "tip"><b>Design Note:</b> Use this on any surface with a deformVertexes keyword. Otherwise, the marks will appear on the unmodified surface location of the texture with the surface wriggles and squirms through the marks.</div>
<p><div class = "subheading">4.8.15 nolightmap</div>
This texture does not have a lightmap phase. It is not affected by the ambient lighting of the world around it. It does not
require the addition of an rgbGen identity keyword in that stage.
<p><div class = "subheading">4.8.16 nosteps</div>
The player makes no sound when walking on this texture.
<p><div class = "subheading">4.8.17 nonsolid</div>
This attribute indicates a brush, which does not block the movement of entities in the game world. It applied to
triggers, hint brushes and similar brushes. This affects the content of a brush.
<p><div class = "subheading">4.8.18 origin</div>
Used on the "origin" texture. Rotating entities need to contain an origin brush in their construction. The brush must be
rectangular (or square). The origin point is the exact center of the origin brush.
<p><div class = "subheading">4.8.19 playerclip</div>
Blocks player movement through a <b>nonsolid</b> texture. Other game world entities can pass through a brush marked <b>
playerclip</b>. The intended use for this is to block the player but not block projectiles like rockets.
<p><div class = "subheading">4.8.20 slick</div>
This surfaceparm included in a texture should give it significantly reduced friction.
<p><div class = "subheading">4.8.21 slime</div>
Assigns to the texture the game properties for slime. This affects both the surface and the content of a brush.
<p><div class = "subheading">4.8.22 structural</div>
This surface attribute causes a brush to be seen by the Q3MAP process as a possible break-point in a BSP tree. It is used
as a part of the shader for the "hint" texture. Generally speaking, any opaque texture not marked as "<b>detail</b>" is, by
default, <b>structural,</b> so you shouldn't need to specify this.
<p><div class = "subheading">4.8.23 trans</div>
Tells q3map that pre-computed visibility should not be blocked by this surface. Generally, any shaders that have blendfuncs
should be marked as surfaceparm trans.
<p><div class = "subheading">4.8.24 water</div>
Assigns to the texture the game properties for water.
<p align = "center"><a href = "../ch02/pg2_1.htm">Back</a> | <a href = "../index.htm">Home</a> | <a href = "../ch04/pg4_1.htm">Next</a>
</body>
</html>

64
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Q3AShader_Manual/ch04/pg4_1.htm Normal file
View file

@ -0,0 +1,64 @@
<html>
<head>
<title>Quake III Arena Shader Manual: Editor Specific Shader Instructions</title>
<link rel = "stylesheet" type = "text/css" href = "../styles/q3rad.css">
</head>
<body>
<h1 class = "MsoTitle">Q3Radiant Shader Manual</h1>
<hr>
<h1>5 Editor specific shader instructions</h1>
These instructions only affect the texture when it is seen in the Q3Radiant editor. They should be grouped with the surface
parameters but ahead of them in sequence.
<h2><a name = "edimg">5.1 qer_editorimage &lt;texture path/texturename&gt;</a></h2>
This keyword creates a shader name in memory, but in the editor, it displays the TGA art image specified in qer_editorimage (in the example below this is textures/eerie/lavahell.tga).
<p>The editor maps a texture using the size attributes of the TGA file used for the editor image. When that editor image represents a shader, any texture used in any of the shader stages will be scaled up or down to the dimensions of the editor image. If a 128x128 pixel image is used to represent the shader in the editor, then a 256x256 image used in a later stage will be shrunk to fit. A 64x64 image would be stretched to fit. Be sure to check this on bouncy, acceleration, and power-uppads placed on surfaces other than 256 x 256. Use <b>tcMod scale</b> to change the size of the stretched
texture. Rememberthat <b>tcMod scale</b> 0.5 0.5 will double your image, while <b>tcMod scale</b> 2 2will halve it.
<p><div class = "tip"><b>Design Notes:</b> The base_light and gothic_light shaders contain numerous uses of this. It can be very useful for making different light styles (mostly to change the light brightnesses) without having to create a new piece of TGA art for each new shader.</div>
<p><pre class = "type">textures/liquids/lavahell2//path and name of new texture
{
qer_editorimagetextures/eerie/lavahell.tga
//based on this
qer_nocarve
//cannot be cut by CSG subtract
surfaceparm noimpact
//projectiles do not hitit
surfaceparm lava
//has the game properties of lava
surfaceparm nolightmap
//environment lighting does not affect
q3map_surfacelight 3000
//light is emitted
tessSize 256
//relatively large triangles
cull disable
//no sides are removed
deformVertexes wave 100sin 5 5 .5 0.02
fogparms 0.85191420.309723 0.0 128 128
{
maptextures/eerie/lavahell.tga
//base texture artwork
tcMod turb .25 0.2 1 0.02
//texture is subjected to turbulence
tcMod scroll 0.1 0.1
//the turbulence is scrolled
}
}
</pre>
<h2><a name = "nocarve">5.2 qer_nocarve</a></h2>
A brush marked with this instruction will not be affected by CSG subtract functions. It is especially useful for water and fog textures.
<h2><a name = "trans">5.3 qer_trans &lt;value&gt;</a></h2>
This parameter defines the percentage of transparency that a brush will have when seen in the editor (no effect on game
rendering a tall). It can have a positive value between 0 and 1. The higher the value, the less transparent the texture.
Example: qer_trans 0.2 means the brush is 20% opaque and nearly invisible.
<p align = "center"><a href = "../ch03/pg3_1.htm">Back</a> | <a href = "../index.htm">Home</a> | <a href = "../ch05/pg5_1.htm">Next</a>
</body>
</html>

483
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Q3AShader_Manual/ch05/pg5_1.htm Normal file
View file

@ -0,0 +1,483 @@
<html>
<head>
<title>Quake III Arena Shader Manual: Stage Specific Keywords</title>
<link rel = "stylesheet" type = "text/css" href = "../styles/q3rad.css">
</head>
<body>
<h1 class = "MsoTitle">Q3Radiant Shader Manual</h1>
<hr>
<h1>6 Stage Specific Keywords</h1>
Stage specifications only affect rendering. Changing any keywords or values within a stage will usually take effect as soon
as a vid_restart is executed. Q3MAP ignores stage specific keywords entirely.
<p>A stage can specify a texture map, a color function, an alpha function, a texture coordinate function, a blend function, and a few other rasterization options.
<h2><a name = "texmap">6.1 Texture map specification</a></h2>
<div class = "subheading">6.1.1 map &lt;texturepath/texturename&gt;</div>
Specifies the source texture map (a 24 or 32-bit TGA file) used for this stage. The texture may or may not contain alpha
channel information. The special keywords <b>$lightmap</b> and <b>$whiteimage</b> may be substituted in lieu of an actual
texture map name. In those cases, the texture named in the first line of the shader becomes the texture that supplies the light mapping data for the process.
<p><div class = "subheading">$lightmap</div>
This is the overall lightmap for the game world. It is calculated during the Q3MAP process. It is the initial color
data found in the framebuffer. Note: due to the use of overbright bits in light calculation, the keyword <b>rgbGen
identity</b> must accompany all <b>$lightmap</b> instructions.
<p><div class = "subheading">$whiteimage</div>
This is used for specular lighting on MD3 models. This is a white image generated internally by the game. This image can
be used in lieu of $lightmap or an actual texture map if, for example, you wish for the vertex colors to come
through unaltered.
<p><div class = "subheading">6.1.2 Clampmap &lt;texturepath&gt;</div>
Dictates that this stage should clamp texture coordinates instead of wrapping them. During a stretch function, the area,
which the texture must cover during a wave cycle, enlarges and decreases. Instead of repeating a texture multiple times
during enlargement (or seeing only a portion of the texture during shrinking) the texture dimensions increase or contract accordingly. This is only relevant when using something like deformTexCoordParms to stretch/compress texture coordinates for a specific special effect. Remember that the Quake III Arena engine normalizes all texture coordinates (regardless of actual texture size) into a scale of 0.0 to1.0.
<p><b>Proper Alignment:</b> When using <b>clampTexCoords</b> make sure the texture is properly aligned on the brush. The <b>
clampTexCoords</b> function keeps the image from tiling. However, the editor doesn't represent this properly and shows a tiled image. Therefore, what appears to be the correct position may be offset. This is very apparent onanything with a <b>tcMod rotate</b> and <b>clampTexCoords</b> function.
<p><b>AvoidingDistortion:</b> When seen at a given distance (which can vary, depending onhardware and the size of the texture), the compression phase of a stretchfunction will cause a "cross"-like visual artifact to form on the modified texture due to the way that textures are reduced. This occurs because the texture undergoing modification lacks sufficient "empty space" around the displayed (non-black) part of the texture (see figure 2a). To compensate for this, make the non-zero portion of the texture substantially smaller (50% of maximum stretched size -- see figure 2b)than the dimensions of the texture. Then, write a scaling function (tcScale) into the appropriate shader phase, to enlarge the image to the desired proportion.
<p>The shaders for the bouncy pads (in the sfx.shader file) show the stretch function in use, including the scaling of the
stretched texture:
<p><strong>Example: UsingclampTexCoords to control a stretching texture</strong>
<p><pre class = "type">
textures/sfx/metalbridge06_bounce
{
//q3map_surfacelight 2000
surfaceparm nodamage
q3map_lightimage textures/sfx/jumppadsmall.tga
q3map_surfacelight 400
{
map textures/sfx/metalbridge06_bounce.tga
rgbGen identity
}
{
map $lightmap
rgbGen identity
blendfunc gl_dst_color gl_zero
}
{
map textures/sfx/bouncepad01b_layer1.tga
blendfunc gl_one gl_one
rgbGen wave sin .5 .5 0 1.5
}
{
clampmap textures/sfx/jumppadsmall.tga
blendfunc gl_one gl_one
tcMod stretch sin 1.2 .8 0 1.5
rgbGen wave square .5 .5 .25 1.5
}
// END
}
</pre>
<p>
<p><div class = "subheading">6.1.3 AnimMap &lt;frequency&gt; &lt;texture1&gt; &hellip; &lt;texture8&gt;</div>
The surfaces in the game can be animated by displaying asequence of 1 to 8 frames (separate texture maps). These animations
are affected by other keyword effects in the same and later shader stages.
<p><b>&lt;Frequency&gt;:</b> the number of times that the animation cycle will repeat within a one second time period. The
larger the value, the more repeats within a second. Animations that should last for more than a second need to be expressed as decimal values.
<br><b>&lt;texture1&gt; &hellip;&lt;texture8&gt;:</b> the texture path/texture name for each animation frame must be
explicitly listed. Up to eight frames (eight separate .tga files) can be used to make an animated sequence. Each frame is
displayed for an equal subdivision of the frequency value.
<p><b>Example:</b> <i>AnimMap 0.25 animMap 10textures/sfx/b_flame1.tga textures/sfx/b_flame2.tga textures/sfx/b_flame3.tgatextures/sfx/b_flame4.tga</i> would be a 4 frame animated sequence, calling each frame in sequence over a cycle length of 4 seconds. Each frame would be displayed for 1 second before the next one is displayed. The cycle repeats after the last frame in sequence is shown.
<p><div class = "tip"><b>Design Notes:</b> To make a texture image appear for an unequal (longer) amount of time (compared to other frames), repeat that frame more than once in the sequence.</div>
<p><pre class = "type">textures/sfx/flameanim_blue
{
// *************************************************
// * Blue Flame *
// * July 20, 1999 Surface Light 1800 *
// * Please Comment Changes *
// *************************************************
qer_editorimage textures/sfx/b_flame7.tga
q3map_lightimage textures/sfx/b_flame7.tga
surfaceparm trans
surfaceparm nomarks
surfaceparm nolightmap
cull none
q3map_surfacelight 1800
// texture changed to blue flame.... PAJ
{
animMap 10 textures/sfx/b_flame1.tgatextures/sfx/b_flame2.tga
textures/sfx/b_flame3.tga textures/sfx/b_flame4.tgatextures/sfx/b_flame5.tga
textures/sfx/b_flame6.tga textures/sfx/b_flame7.tgatextures/sfx/b_flame8.tga
blendFunc GL_ONE GL_ONE
rgbGen wave inverseSawtooth 0 1 0 10
}
{
animMap 10 textures/sfx/b_flame2.tgatextures/sfx/b_flame3.tga
textures/sfx/b_flame4.tga textures/sfx/b_flame5.tgatextures/sfx/b_flame6.tga
textures/sfx/b_flame7.tga textures/sfx/b_flame8.tgatextures/sfx/b_flame1.tga
blendFunc GL_ONE GL_ONE
rgbGen wave sawtooth 0 1 0 10
}
{
map textures/sfx/b_flameball.tga
blendFunc GL_ONE GL_ONE
rgbGen wave sin .6 .2 0 .6
}
}
</pre>
<h2><a name = "blend">6.2 Blend Functions</a></h2>
Blend functions are the keyword commands that tell the <i>Quake III Arena</i> graphic engine's renderer how graphic layers are to be mixed together.
<p><div class = "subheading">6.2.1 Simplified blend functions:</div>
The most common blend functions are set up here as simple commands, and should be used unless you really know what you are
doing.
<p><strong>6.2.1.1 blendfunc add</strong>
<br>This is a shorthand command for <b>blendfunc gl_one gl_one.</b> Effects like fire and energy are additive.
<p><strong>6.2.1.2 blendfunc filter</strong>
<br>This is a shorthand command that can be substituted for either <b>blendfunc gl_dst_color gl_zero</b> or <b>blendfunc gl_zero gl_src_color</b>. A filter will always result in darker pixels than what is behind it, but it can also remove color selectively. Lightmaps are filters.
<p><strong>6.2.1.3 blendfunc blend</strong>
<br>Shorthand for blendfunc gl_src_alphagl_one_minus_src_alpha. This is conventional transparency, where part of the background is mixed with part of the texture.
<p><div class = "subheading">6.2.2 Explicit blend functions:</div>
Getting a handle on this concept is absolutely key to understanding all shader manipulation of graphics.
<p>BlendFunc or "Blend Function" is the equation at the core of processing shader graphics. The formula reads as follows:
<p style = "font-weight: bold; text-align: center">[Source *&lt;srcBlend&gt;] + [Destination *
&lt;dstBlend&gt;]
<p><b>Source</b> is usually the RGB color data in a texture TGA file (remember it's all numbers) modified by any rgbgen and alphagen. In the shader, the source is generally identified by command MAP, followed by the name of the image.
<p><b>Destination</b> is the color data currently existing in the frame buffer.
<p>Rather than think of the entire texture as a whole, it maybe easier to think of the number values that correspond to a single pixel, because that is essentially what the computer is processing &hellip; one pixel of the bit map at a time.
<p>The process for calculating the final look of a texture in place in the game world begins with the precalculated lightmap for the area where the texture will be located. This data is in the frame buffer. That is to say, it is the initial data in the <b>Destination</b>. In an unmanipulated texture (i.e. one without a special shader script), color information from the texture is combined with the lightmap. In a shader-modified texture, the $lightmap stage must be present for the lightmap to be included in the calculation of the final texture appearance.
<p>Each pass or "stage" of blending is combined (in a cumulative manner) with the color data passed onto it by the
previous stage. How that data combines together depends on the values chosen for the Source Blends and Destination Blends at each stage. Remember it's numbers that are being mathematically combined together that are ultimately interpreted as colors.
<p>A general rule is that any <b>Source Blend</b> other than <b> GL_ONE</b> (or <b>GL_SRC_ALPHA</b> where the alpha channel is entirely white) will cause the Source to become darker.
<p><div class = "subheading">6.2.3 Source Blend &lt;srcBlend&gt;</div>
The following values are valid for the Source Blend part of the equation.
<p><b>GL_ONE</b> This is the value 1. When multiplied by the <b>Source</b>, the value stays the same the value of the color information does not change.
<br><b>GL_ZERO</b> This is the value 0. When multiplied by the <b>Source</b>, all RGB data in the <b>Source</b> becomes Zero (essentially black).
<br><b>GL_DST_COLOR</b> This is the value of color data currently in the Destination (frame buffer). The value of that information depends on the information supplied by previous stages.
<br><b>GL_ONE_MINUS_DST_COLOR</b> This is nearly the same as GL_DST_COLOR except that the value for each component color
is inverted by subtracting it from one. (,i.e. R = 1.0 - DST.R, G = 1.0 - DST.G, B = 1.0 - DST.B, etc.)
<br><b>GL_SRC_ALPHA</b> The TGA file being used for the <b>Source</b> data <u>must have an alpha channel</u> in addition to its RGB channels (for a total of four channels). The alpha channel is an 8-bit black and white only channel. An entirely white alpha channel will not darken the <b>Source</b>.
<br><b>GL_ONE_MINUS_SRC_ALPHA</b> This is the same as GL_SRC_ALPHA except that the value in the alpha channel is inverted by subtracting it from one.(i.e. A=1.0 - SRC.A)
<p><div class = "subheading">6.2.4 Destination Blend &lt;dstBlend&gt;</div>
The following values are valid for the Destination Blend part of the equation.
<p><b>GL_ONE</b> This is the value 1. When multiplied by the <b>Destination</b>, the value stays the same the value of the color information does not change.
<br><b>GL_ZERO</b> This is the value 0. When multiplied by the <b>Destination</b>,all RGB data in the <b>Destination</b>becomes Zero (essentially black).
<br><b>GL_SRC_COLOR</b> This is the value of color data currently in the <b>Source</b> (which is the texture being manipulated here).
<br><b>GL_ONE_MINUS_SRC_COLOR</b> This is the value of color data currently in <b>Source</b>, but subtracted from one(i.e.
inverted).
<br><b>GL_SRC_ALPHA</b> The TGA file being used for the <b>Source</b> data <u>must have an alpha channel</u> in addition to its RGB channels (four a total of four channels). The alpha channel is an 8-bit black and white only channel. An entirely white alpha channel will not darken the <b>Source</b>.
<br><b>GL_ONE_MINUS_SRC_ALPHA</b> This is the same as GL_SRC_ALPHA except that the value in the alpha channel is inverted by subtracting it from one. (i.e. A=1.0 - SRC.A).
<p><strong>Doing the Math: The Final Result</strong>
<br>The product of the <b>Source</b> side of the equation is added to the product of the <b>Destination</b> side of the equation. The sum is then placed into the frame buffer to become the <b>Destination</b> information for the next stage. Ultimately, the equation creates a modified color value that is used by other functions to define what happens in the texture when it is displayed in the game world.
<p><div class = "subheading">6.2.5 Default Blend Function</div>
<i>If no <b>blendFunc</b> is specified then no blending will take place.</i> A warning is generated if any stage after the first stage does not have a <b>blendFunc</b> specified.
<p><div class = "subheading">6.2.6 Technical Information/Limitations Regarding Blend Modes:</div>
The Riva 128 graphics card supports ONLY the following blendmodes:
<p>GL_ONE, GL_ONE
<br>GL_DST_COLOR, GL_ZERO
<br>GL_ZERO, GL_SRC_COLOR
<br>GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA
<br>GL_ONE_MINUS_SRC_ALPHA, GL_SRC_ALPHA
<p>Cards running in 16 bit color cannot use any GL_DST_ALPHA blends.
<h2><a name = "rgbgen">6.3 rgbGen &lt;func&gt;</a></h2>
There are two color sources for any given shader, the texture file and the vertex colors. Output at any given time will be equal to <b>TEXTURE</b> multiplied by <b>VERTEXCOLOR</b>. Most of the time VERTEXCOLORwill default to white (which is a normalized value of 1.0), so output will be TEXTURE (this usually lands in the <b> Source</b>side of the shader equation). Sometimes you do the opposite and use TEXTURE = WHITE, but this is only commonly used when doing specular lighting on entities (i.e. shaders that level designers will probably never create
<p>The most common reason to use rgbGen is to pulsate something. This means that the VERTEXCOLOR will oscillate between two
values, and that value will be multiplied (darkening) the texture.
<p>If no rgbGen is specified, either "identityLighting" or"identity" will be selected, depending on which blend modes are
used.
<p>Valid &lt;func&gt; parameters are <b>wave, identity, identityLighting, entity, oneMinusEntity, fromVertex,</b> and <b>
lightingDiffuse</b>.
<p><div class = "subheading">6.3.1 RgbGen identityLighting</div>
Colors will be (1.0,1.0,1.0) if running without overbright bits (NT, linux, windowed modes), or (0.5, 0.5, 0.5) if running
with overbright. Overbright allows a greater color range at the expense of a loss of precision. Additive and blended stages
will get this by default.
<p><div class = "subheading">6.3.2 rgbGen identity</div>
Colors are assumed to be all white (1.0,1.0,1.0). All filters stages (lightmaps, etc) will get this by default.
<p><div class = "subheading">6.3.3 rgbGen wave &lt;func&gt; &lt;base&gt; &lt;amp&gt;&lt;phase&gt; &lt;freq&gt;</div>
Colors are generated using the specified waveform. An affected texture with become darker and lighter, but will not change
hue. Hue stays constant. Note that the rgb values for color will not go below 0 (black) orabove 1 (white). Valid waveforms are sin, triangle, square, sawtooth and inversesawtooth.
<p><b>&lt;func&gt; Waveforms and their effects:</b>
<br><b>Sin:</b> color flows smoothly through changes.
<br><b>Triangle:</b> color changes at a constant rate and spends noappreciable time at peaks and valleys.
<br><b>Square:</b> color alternates instantly between its peak and valley values.
<br><b>Sawtooth:</b> With a positive frequency value, the color changes at aconstant rate to the peak then instantly drops to its valley value.
<br><b>Inversesawtooth:</b> An inverse sawtooth wave will reverse this, making the ascent immediate (like a square wave) and the decay fall off like a triangle wave.
<br><b>&lt;base&gt;</b> Baseline value. The initial RGB formula of a color (normalilzed).
<br><b>&lt;amp&gt;</b> Amplitude. This is the degree of change from the baseline value. In some cases you will want
values outside the 0.0 to 1.0 range, but it will induce clamping (holding at the maximum or minimum value for a time period)
instead of continuous change.
<br><b>&lt;phase&gt;</b> See the explanation for phase under the waveforms heading of Key Concepts.
<br><b>&lt;freq&gt;</b> Frequency. This is a value (NOT normalized) that indicates peaks per second.
<p><div class = "subheading">6.3.4 RgbGen entity</div>
Colors are grabbed from the entity's <b>modulate</b> field. This isused for things like explosions.
<p><div class = "tip"><b>Design Note</b>: This keyword would probably not be used by a level designer.</div>
<p><div class = "subheading">6.3.5 rgbGen oneMinusEntity</div>
Colors are grabbed from 1.0 minus the entity's modulate field.
<p><div class = "tip"><b>Design Note</b>: This keyword would probably not be used by a level designer.</div>
<p><div class = "subheading">6.3.6 rgbGen Vertex</div>
Colors are filled in directly by the data from the map or model files.
<p><div class = "tip"><b>Design Note</b>: rgbGen vertex should be used when you want the RGB values to be computed for a static model (i.e. mapobject) in the world using precomputed static lighting from Q3BSP. This would be used on things like
the gargoyles, the portal frame, skulls, and other decorative MD3s put into the Quake III Arena world.</div>
<p><div class = "subheading">6.3.7 rgbGen oneMinusVertex</div>
As rgbGen vertex, but inverted.
<p><div class = "tip"><b>Design Note</b>: This keyword would probably not be used by a level designer</div>
<p><div class = "subheading">6.3.8 rgbGen lightingDiffuse</div>
Colors are computed using a standard diffuse lighting equation. It uses the vertex normals to illuminate the object correctly.
<p><div class = "tip"><b>Design Note:</b> -rgbGen lightingDiffuse is used when you want the RGB values to be computed for a dynamic model (i.e. non-map object) in the world using regular in-game lighting. For example, you would specify on shaders for items, characters, weapons, etc.</div>
<h2><a name = "alphagen">6.4 AlphaGen &lt;func&gt;</a></h2>
The alpha channel can be specified like the rgbchannels. If not specified, it defaults to 1.0.
<p><div class = "subheading">6.4.1 AlphaGen portal</div>
This rendering stage keyword is used in conjunction with the surface parameter keyword <b>portal</b>. The function
accomplishes the "fade" that causes the scene in the portal to fade from view. Specifically, it means "Generate alpha values
based on the distance from the viewer to the portal." Use <b>alphaGen</b> portal on the last rendering pass.
<h2><a name = "tcgen">6.5 tcGen &lt;coordinate source&gt;</a></h2>
Specifies how texture coordinates are generated and where they come from. Valid functions are <b>base</b>,<b>lightmap</b> and <b>environment.</b>
<p><b>&lt;base&gt;</b> = base texture coordinates from the original art.
<br><b>&lt;lightmap&gt;</b> = lightmap texture coordinates
<br><b>&lt;environment&gt;</b> = Make this object environment mapped.
<p><div class = "subheading">6.5.1 tcGen vector (&lt;sx&gt; &lt;sy&gt; &lt;sz&gt;)
(&lt;tx&gt;&lt;ty&gt; &lt;tz&gt;)</div>
New texcoord generation by world projection. This allows you to project a texture onto a surface in a fixed way, regardless of its orientation.
<p>S coordinates correspond to the "x" coordinates on the texture itself.
<br>T coordinates correspond to the "y" coordinates on the texture itself.
<p>The measurements are in game units.
<p>
<p>Example: tcGen vector (0.01 0 0) (0 0.01 0)
<br>This would project a texture with a repeat every 100 units across the X/Y plane.
<h2><a name = "tcmod">6.6 tcMod &lt;func&gt; &lt;&hellip;&gt;</a></h2>
Specifies how texture coordinates are modified after they are generated. The valid functions for tcMod are <b>rotate,
scale,scroll, stretch and transform.</b> <b>Transform</b> is a function generally reserved for use by programmers who suggest that designers leave it alone. When using multiple tcMod functions during a stage, place the <b>scroll</b> command last in order, because it performs a mod operation to save precision, and that can disturb other operations. Texture coordinates are modified in the order in which tcMods are specified. In otherwords, if you see:
<p><strong>tcMod scale 0.5 0.5</strong>
<br><strong>tcMod scroll 1 1</strong>
<p>Then the texture coordinates will be <b>scaled</b> <i>then</i> <b>scrolled.</b>
<p><div class = "subheading">6.6.1 tcMod rotate &lt;degrees per per second&gt;</div>
This keyword causes the texture coordinates to rotate. The value is expressed in degrees rotated each second. A positive value means clockwise rotation. A negative value means counterclockwise rotation. For example "tcMod rotate 5" would
rotate texture coordinates 5 degrees each second in a clockwise direction. The texture rotates around the center
point of the texture map, so you are rotating a texture with a single repetition, be careful to center it on the brush (unless off-center rotation is desired).
<p><div class = "subheading">6.6.2 tcMod scale &lt;sScale&gt; &lt;tScale&gt;</div>
Resizes (enlarges or shrinks) the texture coordinates bymultiplying them against the given factors of &lt;sScale&gt;
and &lt;tScale). The values "s" and "t"conform to the "x" and "y" values (respectively) as they are found in the original texture TGA. The values for <b>sScale</b> and <b>tScale</b> are NOT normalized. This means that a value greater than 1.0 will increase the size of thetexture. A positive value less than one will reduce the texture to a fraction of its size and cause it to repeat within the same area as the original texture (Note: see <b>clampTexCoords</b> for ways to control this).;
<p><b>Example:</b> <i>tcMod scale 0.5 2</i> would cause the texture to repeat twice along its width, but expand to twice its height (in which case half of the texture would be seen in the same area as the original)
<p><div class = "subheading">6.6.3 tcMod scroll &lt;sSpeed&gt; &lt;tSpeed&gt;</div>
Scrolls the texture coordinates with the given speeds. The values "s" and "t" conform to the "x" and "y" values
(respectively) as they are found in the original textureTGA. The scroll speed is measured in "textures" per second. A "texture" is the dimension of the texture being modified and includes any previous shader modifications to the original TGA). A negative s value would scroll the texture to the left. A negative t value would scroll the texture down.
<p><strong>Example:</strong> tcMod scroll 0.5 -0.5 moves the texture down and right (relative to the TGA files original coordinates) at the rate of a half texture each second of travel.
<p>This should be the LAST tcMod in a stage. Otherwise there maybe popping or snapping visual effects in some shaders.
<p><div class = "subheading">6.6.4 tcMod stretch &lt;func&gt; &lt;base&gt;
&lt;amplitude&gt;&lt;phase&gt; &lt;frequency&gt;</div>
Stretches the texture coordinates with the given function. Stretching is defined as stretching the texture coordinate away from the center of the polygon and then compressing it towards the center of the polygon.
<p><b>&lt;base&gt;:</b> A base value of one is the original dimension of the texture when it reaches the stretch stage.
Inserting other values positive or negative in this variable will produce unknown effects.
<br><b>&lt;amplitude&gt;:</b> This is the measurement of distance the texture will stretch from the base size. It is
measured, like scroll, in textures. A value of 1 here will double the size of the texture at its peak.
<br><b>&lt;phase&gt;:</b> See the explanation for phase under the deform vertexes keyword.
<br><b>&lt;frequency&gt;:</b> this is wave peaks per second.
<br><strong>Wave Functions &lt;func&gt;</strong>
<br><b>Sin wave</b>: the texture expands smoothly to its peak dimension and then shrinks smoothly to its valley dimension in a flowing manner.
<br><b>Triangle wave:</b> The textures stretch at a constant rate and spend no appreciable time at the peak or valley points.
<br><b>Square wave:</b> The texture is shown at its peak for the duration of the frequency and then at its valley for the
duration of the frequency.
<br><b>Sawtooth:</b> the texture stretches like a triangle wave until it reaches a peak, then instantly drops to the valley, as in a square wave.
<br><b>Inversesawtooth:</b> this is the reverse of the sawtooth wave.
<p><div class = "subheading">6.6.5 tcMod &lt;transform&gt; &lt;m00&gt; &lt;m01&gt; &lt;m10&gt;&lt;m11&gt; &lt;t0&gt; &lt;t1&gt;</div>
Transforms each texture coordinate as follows:
<p>S' = s * m00 + t * m10 + t0
<br>T' = s * m01 + t * m11 + t1
<p>This is for use by programmers.
<p><div class = "subheading">6.6.6 tcMod turb &lt;base&gt; &lt;amplitude&gt;
&lt;phase&gt;&lt;freq&gt;</div>
<p>Applies turbulence to the texture coordinate. Turbulence is a back and forth churning and swirling effect on the texture.
<p>The parameters for this shader are defined as follows:
<p><b>&lt;base&gt;</b> Currently undefined.
<br><b>&lt;amplitude&gt;</b> This is essentially the intensity of the disturbance or twisting and squiggling of the texture.
<br><b>&lt;phase&gt;</b> See the explanation for phase under the <b>deformvertexes</b> keyword.
<br><b>&lt;freq&gt;</b> Frequency. This value is expressed as repetitions or cycles of the wave per second. A value of one
would cycle once per second. A value of 10 would cycle 10 times per second. A value of 0.1 would cycle once every 10
seconds.
<h2><a name = "depthfunc">6.7 depthFunc &lt;func&gt;</a></h2>
This controls the depth comparison function used while rendering. The default is "lequal" (Less than or equal to)
where any surface that is at the same depth or closer of an existing surface is drawn. This is used for textures with
transparency or translucency. Under some circumstances you may wish to use "equal", e.g. for light-mapped grates that are alpha tested (it is also used for mirrors).
<h2><a name = "depthwrite">6.8 depthWrite</a></h2>
By default, writes to the depth buffer when depthFunc passes will happen for opaque surfaces and not for translucent surfaces. Blended surfaces can have the depth writes forced with this function.
<h2><a name = "detail">6.9 Detail</a></h2>
This feature was not used in Quake III Arena maps, but should still function.
Designates this stage as a detail texture stage, which means that if the c_var, r_detailtextures, is set to 0 then this stage will be ignored (detail will not be displayed). This keyword, by itself, does not affect rendering at all. If you do put in a detail texture, it has to conform to very specific rules. Specifically, the blendFunc:
<p><strong>blendFuncGL_DST_COLOR GL_SRC_COLOR</strong>
<p>This is also the simple blend function: <b>blendfuncfilter</b>
<p>And the average <i>intensity</i> of the detail texture itself must be around 127.
<p>Detail is used to blend fine pixel detail back into a base texture whose scale has been increased significantly. When detail iswritten into a set of stage instructions, it allows the stage to be disabled by the c_var console command setting "r_detailtextures 0".
<p>A texture whose scale has been increased beyond a 1:1 ratio tends not to have very high frequency content. In other words, one texel can cover a lot of real estate. Frequency is also known as "detail." Lack of detail can appear acceptable if the player never has the opportunity to see the texture at close range. But seen close up, such textures look glaringly wrong within the sharp detail of the Quake III Arena environment. A detail texture solves this problem by taking a noisy "detail" pattern (a tiling texture that appears to have a great deal of surface roughness) and applying it to the base texture at a very densely packed scale (that is, reduced from its normal size). This is done programmatically in the
shader, and does not require modification of the base texture. Note that if the detail texture is the same size and scale as the base texture that you may as well just add the detail directly to the base texture. The theory is that the detail texture's scale will be so high compared to the base texture (e.g.; 9 detail texels fitting into 1 base texel) that it is literally impossible to fit that detail into the base texture directly.
<p>For this to work, the rules are as follows:
<ol type = "A">
<li>the lightmap must be rendered first. This is because the subsequent detail texture will be modifying the lightmap in the framebuffer directly;
<li>the detail texture must be rendered next since it modifies the lightmap in the framebuffer;
<li>the base texture must be rendered last;
<li>the detail texture MUST have a mean intensity around 127-129. If it does not then it will modify the displayed texture's perceived brightness in the world;
<li>the detail shader stage MUSThave the "<b>detail</b>" keyword or it will not be disabled if the user uses the "r_detailtextures 0" setting;
<li>the detail stage MUST use "blendFunc GL_DST_COLOR GL_SRC_COLOR". Any other BlendFunc will cause mismatches in brightness between detail and non-detail views.;
<li>the detail stage should scale its textures by some amount (usually between 3 and 12) using "tcMod" to control density. This roughly corresponds to coarseness. A very large number, such as 12, will give very fine detail, however that detail will disappear VERY quickly as the viewer moves away fromthe wall since it will be MIP mapped away. A very small number, e.g. 3, gives diminishing returns since not enough is brought in when the user gets very close. I'm currently using values between 6 and 9.5. You should use non-integral numbers as much as possible to avoid seeing repeating patterns.
<li>detail textures add one pass of overdraw, so there is a definite performance hit .
<li>detail textures can be shared, so designers may wish to define only a very small handful of detail textures for common surfaces such as rocks, etc.</ol>
<p>An example (non-existent) detailshader is as follows:
<p><strong>Example: Texture with Detail</strong>
<p><pre class = "type">
textures/bwhtest/foo
{
// draw the lightmap first
{
map $lightmap
rgbGen identity
}
// modify the lightmap in the framebuffer by
// a highly compressed detail texture
{
map textures/details/detail01.tga
blendFunc GL_DST_COLOR GL_SRC_COLOR
// YOU MUST USE THIS!!
detail
// for the detail to be disabled, this must be present
tcMod scale 9.1 9.2
}
// now slap on the base texture
{
map textures/castle/blocks11b.tga
blendFunc filter
}
}
</pre>
<h2><a name = "alphafunc">6.10 alphaFunc &lt;func&gt;</a></h2>
Determines the alpha test function used when rendering this map. Valid values are GT0, LT128, and GE128. These
correspond to "GREATER THAN 0", "LESS THAN 128", and "GREATER THAN OR EQUAL TO 128". This function is used when determining if a pixel should be written to the framebuffer. For example, if GT0 is specified, the only the portions of the texture map with corresponding alpha values greater than zero will be written to the framebuffer. By default alpha testing is disabled.
<p>Both alpha testing and normal alpha blending can be used to get textures that have see-through parts. The difference is that alphaFunc is an all-or-nothing test, while blending smoothly blends between opaque and translucent at pixel edges. Alpha test can also be used with <b>depthwrite</b>, allowing other effects to be conditionally layered on top of just the opaque pixels by setting <b>depthFunc</b> to equal.
<p align = "center"><a href = "../ch04/pg4_1.htm">Back</a> | <a href = "../index.htm">Home</a> | <a href = "../ch06/pg6_1.htm">Next</a>
</body>
</html>

145
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Q3AShader_Manual/ch06/pg6_1.htm Normal file
View file

@ -0,0 +1,145 @@
<html>
<head>
<title>Quake III Arena Shader Manual: Notes on Alpha Channels</title>
<link rel = "stylesheet" type = "text/css" href = "../styles/q3rad.css">
</head>
<body>
<h1 class = "MsoTitle">Q3Radiant Shader Manual</h1>
<hr>
<h1>7 Notes on Alpha Channels</h1>
To use some blend modes of alphaFunc, you must add an alpha channel to your texture files. Photoshop can do this.
Paintshop Pro has the ability to make an alpha channel but cannot work directly in to it. In Photoshop you want to set the type to Mask. Black has a value of 255. White has a value of 0. The darkness of a pixel's alpha value determines the
transparency of the corresponding RGB value in the game world. Darker = more transparent.
<p>Care must be taken when reworking textures with alpha channels. Textures without alpha channels are saved as 24 bit images while textures with alpha channels are saved as 32 bit. If you save them out as 24 bit, the alpha channel is erased. Note: Adobe Photoshop will prompt you to save as 32, 24 or 16 bit. Choose wisely. If you save a texture as 32 bit and you don't actually have anything in the alpha channel, Quake III Arena may still be forced to use a lower quality texture format (when in 16 bit rendering) than if you had saved it as 24 bit.
<p>To create a texture that has "open" areas, make those areas black in the alpha channel and make white the areas that are to be opaque. Using gray shades can create varying degrees of opacity/transparency.
<p align = "center"><strong>Example: An opaque texture with see-through holes knocked in it.</strong>
<p><pre class = "type">
textures/base_floor/pjgrate1
{
surfaceparm metalsteps
cull none
// A GRATE OR GRILL THAT CAN BE SEEN FROM BOTH SIDES
{
map textures/base_floor/pjgrate1.tga
blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA
alphaFunc GT0
depthWrite
rgbGen identity
}
{
map $lightmap
rgbGen identity
blendFunc GL_DST_COLOR GL_ZERO
depthFunc equal
}
}
</pre>
<p>The alpha channel can also be used to merge a texture (including one that contains black) into another image so that the merged art appears to be and opaque decal on a solid surface (unaffected by the surface it appears to sit on), without actually using an alpha function. The following is a very simple example:
<p align = "center"><img src = "../q3ashader_manual_files/image002.jpg" width = "600" height = "200">
<br>Figure 1
<p>Start with a TGA file image. In this case, a pentagram on a plain white field (figure 1A). The color of the field surrrounding the image to be merged is not relevant to this process (although having a hard-edged break between the image to be isolated and the field makes the mask making process easier). Make an alpha channel. The area of the image to be merged with another image is masked off in white. The area to be masked out (notused) is pure black (figure 1B). The image to be merged into is greenfloor.tga (figure 1C).
<p>Make a <b>qer_editorimage</b> of greenfloor.tga. This is placed inthe frame buffer as the map image for the texture. By
using GL_SRC_ALPHA as the source part of the blend equation, the shader adds in only the non-black parts of the pentagram.
Using GL_MINUS_ONE_SRC_ALPHA, the shader inverts the pentagram's alpha channel and adds in only the non-black parts of the green floor.
<p>In a like manner, the alpha channel can be used to blend the textures more evenly. A simple experiment involves using a
linear gradiant in the alpha channel (white to black) and merging two textures so they appear to cross fade into each other.
<p>A more complicated experiment would be to take the pentagram in the first example and give it an aliased edge so that the pentagram appeared to fade or blend into the floor.
<h1><a name = "trouble">8 Troubleshooting Shaders</a></h1>
If a shader is not working, look first for syntax errors.
<ul><li>Are the brackets correctly set?
<li>Do you have too many parameter values on a line?
<li>Are you using a word in a parameter that wants a numerical value?
<li>Are you using a numerical value in a parameter that wants a word?
<li>Are the path names to your textures correct?
<li>Are your texture names correct? There is a chance that the texture name is too long or too complex. Try renaming a
texture with a shorter, simpler name.</ul>
<h1><a name = "newtex">9 Creating New Textures</a></h1>
If you are familiar with the required tools, creating new assets for use in Quake III Arena is not particularly difficult. As a general rule, you should create new directories for each map with names different from the names used by id. If you are making a map that will be called "H4x0r_D00M", every directory containing new assets for that map should be titled H4x0r_D00M. This is to try and avoid asset directories overwriting each other as the editor and the gameload in assets.
<h2><a name = "tools">9.1 Tools Needed</a></h2>
Any combination of graphic programs and plug-ins that canout put a 24 bit MS windows compatible Targa (.tga) or JPEG (.jpg) graphic file.If you plan to make textures that will have an alpha channel component (a 4<sup>th</sup> 8-bit greyscale channel that is used by the shaders to further manipulate the art), you must have a program that can create 32-bit art with that fourth channel.
<p>Adobe Photoshop has the ability to easily create alpha channels. PaintShop Pro from JASC (v5.0+) can also make an
alpha channel by creating a mask and naming it "alpha".
<p>Generally speaking, regardless of the program used, we found it best to do most of the art manipulation of the alpha channel in a separate layer or file and then paste it into the alpha channel before saving.
<h2><a name = "files">9.2 Setting up Files</a></h2>
The editor and the game program look for assets to be located along the paths set up in your project file. Start by creating
a directory for you new textures by creating file folders to make a directory path as follows:
<p><div class = "type">quake3\baseq3\textures\[mymapname]</div>
<p>The installation of Q3Radiant will create a text document called "shaderlist.txt" in the following path:
<p><div class = "type">quake3\baseq3\scripts\shaderlist.txt</div>
<p>Q3Radiant will use the contents of this script to grab your new textures for inclusion in the game. The contents of shaderlist.txt document will contain a listing of all the shader documents that were used by id Software to create Quake III Arena.
<p>Since you will obviously want to create your own shaders, you need to put them in separate folders and create a new shader script for them.
<p>If you plan to work on several maps at once and want to distinguish between textures used in each map, simply add additional map names here. For map and mod makers, we STRONGLY recommend that any new shader scripts created use the name of the map or mod in the shader file name. We know we can't avoid every incident of files overwriting each other, but we certainly can advise you how to try.
<p>Now, in the scripts directory that you just created, create another text file and call it:
<p><div class = "type">[mymapname].shader</div>
<p>This file will contain the shader scripts you write to modify a particular texture.
<h2><a name = "rng">9.3 Rules and Guidelines</a></h2>
<div class = "subheading">9.3.1 Rules</div>
Follow these rules when creating textures for the Quake III Arena engine:
<ul><li>Save your textures into your new [map name] directories.
<li>Don't use the same names that id used for textures. It will cause problems.
<li>For best quality, save textures without an alpha channel as 24 bit TARGA files. Using JPEG files can save memory space, but at the risk of losing detail and depth in the texture. JPEG files cannot be used for textures requiring an alpha channel.
<li>Textures containing an alpha channel must be saved as32 bit TARGA files.
<li>If a new texture requires no further manipulation, it does not need a shader script.
<li>Size textures in powers of 2. Example: 8x8, 16x16,32x32, 64x64 pixels and so on.
<li>Textures don't need to be square. A 32x256 pixel texture is perfectly acceptable.</ul>
<p><div class = "subheading">9.3.2 Guidelines</div>
The following are some things the id designers learned about textures.
<ul><li>Create textures in "suites" built around one or two large textures with a number of much smaller supporting detail or accent textures.
<li>Very large textures are possible, but some video cards compress textures larger than 256x256 pixels.
<li>Textures are grouped alphabetically by name in the texture display window, so you may want to give suites of textures
similar names.
<li>Use the shader function qe3_editorimage to conserve memory when making multiple versions of a single texture (as in the case of a glowing texture with several light values).
<li>Unless you are creating special effects or textures designed to draw the player's eye to a specific spot, muted, middle value colors work best with the game engine.
<li>Extremely busy (a lot of fussy detail) textures can break up or form visually unpleasant patterns when seen at distances.</ul>
<h2><a name = "pk3">9.4 Making the .pk3 File></a></h2>
When you go to distribute your creation to the gaming world, you need to put your newly created map, textures, bot area files, and shader documents into an archive format called a "pk3" file. You do not need to include the shaderlist.txt file, since that is only used by the editor. You will need to keep the paths to the various assets the same. So your paths should be something like this:
<p>Textures: <span class = "type">baseq3/textures/[mymapnamefolder]</span>
<br>Bsp &amp; aas: <span class = "type">baseq3/maps/mymapname.bsp, mymapname.aas</span>
<br>Shader scripts: <span class = "type">baseq3/scripts/mymapname.shader</span>
<p>You need to use an archiving program call Winzip to make the pk3 file. Get Winzip from <a href=
"http://www.winzip.com/winzip/winzip.htm">http://www.winzip.com/winzip/winzip.htm</a>
<br>Make a zip archive called mymapname.zip
<br>Zip all the required assets into a zip archive file (Quake III Arena <i>DOES</i> support compressed pk3 files).
<br>Rename the zip archive to mymapname.pk3
<br>Put it where the Quake III Arena community can find it.
<p align = "center"><a href = "../ch05/pg5_1.htm">Back</a> | <a href = "../index.htm">Home</a> | Next
</body>
</html>

76
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Q3AShader_Manual/index.htm Normal file
View file

@ -0,0 +1,76 @@
<html>
<head>
<title>Quake III Arena Shader Manual: Table of Contents</title>
<link rel = "stylesheet" type = "text/css" href = "styles/q3rad.css">
</head>
<body>
<div align = "center">
<h1 class = "MsoTitle">Q3Radiant Shader Manual</h1>
<h2>Revision #12</h2>
<p style = "font-weight: bold">By Paul Jaquays and Brian Hook
<p class = "heading">(with additional material by John Carmack, Christian Antkow, Kevin Cloud, &amp; Adrian Carmack)
<p class = "heading">QERadiant.com thanks John Hutton for re-formating this manual into a more web friendly version</div>
<hr>
<h1>Table of Contents</h1>
<a href = "ch01/pg1_1.htm">1 Preface: Making Your Own Shaders</a>
<br><a href = "ch01/pg1_1.htm#intro">2 Introduction</a>
<ul style = "margin-top: 0em"><a href = "ch01/pg1_1.htm#what">2.1 What is a Shader?</a>
<br><a href = "ch01/pg1_1.htm#conventions">2.2 Shader Name & File Conventions</a>
<br><a href = "ch01/pg1_1.htm#types">2.3 Shader Types</a>
<br><a href = "ch01/pg1_1.htm#concepts">2.4 Key Concepts</a></ul>
<a href = "ch02/pg2_1.htm">3 General Shader Keywords</a>
<ul style = "margin-top: 0em"><a href = "ch02/pg2_1.htm#skyparms">3.1 skyParms <em>&lt;farbox&gt; &lt;cloudheight&gt; &lt;nearbox&gt;</em></a>
<br><a href = "ch02/pg2_1.htm#cull">3.2 cull <em>&lt;side&gt;</em></a>
<br><a href = "ch02/pg2_1.htm#deform">3.3 deformVertexes</a>
<br><a href = "ch02/pg2_1.htm#fogparms">3.4 fogparms <em>&lt;red value&gt; &lt;green value&gt; &lt;bluevalue&gt; &lt;distance to Opaque&gt;</em></a>
<br><a href = "ch02/pg2_1.htm#nopicmip">3.5 nopicmip</a>
<br><a href = "ch02/pg2_1.htm#nomipmaps">3.6 nomipmaps</a>
<br><a href = "ch02/pg2_1.htm#polygon">3.7 polygonOffset</a>
<br><a href = "ch02/pg2_1.htm#portal">3.8 portal</a>
<br><a href = "ch02/pg2_1.htm#sort">3.9 sort <em>&lt;value&gt;</em></a></ul>
<a href = "ch03/pg3_1.htm">4 Q3MAP Specific Shader Keywords</a>
<ul style = "margin-top: 0em"><a href = "ch03/pg3_1.htm#tessSize">4.1 tessSize <em>&lt;amount&gt;</em></a>
<br><a href = "ch03/pg3_1.htm#backshader">4.2 q3map_backshader <em>&lt;shadername&gt;</em></a>
<br><a href = "ch03/pg3_1.htm#globaltex">4.3 q3map_globaltexture</a>
<br><a href = "ch03/pg3_1.htm#mapsun">4.4 q3map_sun <em>&lt;red&gt; &lt;green&gt; &lt;blue&gt; &lt;intensity&gt; &lt;degrees&gt; &lt;elevation&gt;</em></a>
<br><a href = "ch03/pg3_1.htm#surflight">4.5 q3map_surfaceLight <em>&lt;light value&gt;</em></a>
<br><a href = "ch03/pg3_1.htm#lightimg">4.6 q3map_lightimage <em>&lt;texturepath/texturename&gt;</em></a>
<br><a href = "ch03/pg3_1.htm#lightsub">4.7 q3map_lightsubdivide <em>&lt;value&gt;</em></a>
<br><a href = "ch03/pg3_1.htm#surfparm">4.8 surfaceparm <em>&lt;parm&gt;</em></a>
</ul>
<a href = "ch04/pg4_1.htm">5 Editor specific shader instructions</a>
<ul style = "margin-top: 0em"><a href = "ch04/pg4_1.htm#edimg">5.1 qer_editorimage <em>&lt;texture path/texturename&gt;</em></a>
<br><a href = "ch04/pg4_1.htm#nocarve">5.2 qer_nocarve</a>
<br><a href = "ch04/pg4_1.htm#trans">5.3 qer_trans <em>&lt;value&gt;</em></a>
</ul>
<a href = "ch05/pg5_1.htm">6 Stage Specific Keywords</a>
<ul style = "margin-top: 0em"><a href = "ch05/pg5_1.htm#texmap">6.1 Texture map specification</a>
<br><a href = "ch05/pg5_1.htm#blend">6.2 Blend Functions</a>
<br><a href = "ch05/pg5_1.htm#rgbgen">6.3 rgbGen <em>&lt;func&gt;</em></a>
<br><a href = "ch05/pg5_1.htm#alphagen">6.4 AlphaGen <em>&lt;func&gt;</em></a>
<br><a href = "ch05/pg5_1.htm#tcgen">6.5 tcGen <em>&lt;coordinate source&gt;</em></a>
<br><a href = "ch05/pg5_1.htm#tcmod">6.6 tcMod <em>&lt;func&gt; &lt;&hellip;&gt;</em></a>
<br><a href = "ch05/pg5_1.htm#depthfunc">6.7 depthFunc <em>&lt;func&gt;</em></a>
<br><a href = "ch05/pg5_1.htm#depthwrite">6.8 depthWrite</a>
<br><a href = "ch05/pg5_1.htm#detail">6.9 Detail</a>
<br><a href = "ch05/pg5_1.htm#alphafunc">6.10 alphaFunc <em>&lt;func&gt;</em></a>
</ul>
<a href = "ch06/pg6_1.htm">7 Notes on Alpha Channels</a>
<br><a href = "ch06/pg6_1.htm#trouble">8 Troubleshooting Shaders</a>
<br><a href = "ch06/pg6_1.htm#newtex">9 Creating New Textures</a>
<ul style = "margin-top: 0em"><a href = "ch06/pg6_1.htm#tools">9.1 Tools Needed</a>
<br><a href = "ch06/pg6_1.htm#files">9.2 Setting up Files</a>
<br><a href = "ch06/pg6_1.htm#rng">9.3 Rules and Guidelines</a>
<br><a href = "ch06/pg6_1.htm#pk3">9.4 Making the .pk3 File</a>
</ul>
<br><a href = "appendix/appA.html">Appendix A: targetShaderName and targetNewShaderName</a>
</body>
</html>

BIN
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Q3AShader_Manual/q3ashader_manual_files/image002.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 26 KiB

23
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Q3AShader_Manual/styles/q3rad.css Normal file
View file

@ -0,0 +1,23 @@
body { font: 12pt "Times New Roman";
margin-left: 5mm;
margin-right: 5mm;
text-align: justify;
background: #ffffff;
color: #000000 }
h1 { font: bold 24pt Arial, Helvetica }
h2 { font: bold italic 18pt Arial, Helvetica }
.subheading { font: bold 16pt Arial, Helvetica }
:link {color: blue;
text-decoration: none; }
:visited {color: purple;
text-decoration: none; }
h6 { font: 10pt "Times New Roman" }
.MsoToc2 { font: bold small-caps 12pt "Times New Roman" }
.MsoTitle { text-align:center;
font: bold 24pt "BankGothic Md BT";
letter-spacing:2.5pt }
.heading { font: italic 10pt "Times New Roman" }
.subcontents { font: 10pt "Times New Roman" }
.tip { font: 10pt "Comic Sans MS" }
.type { font: 10pt "Courier New" }
.menu { font: 10pt Arial, Helvetica }

113
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pages/design_tips.html Normal file
View file

@ -0,0 +1,113 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Design Tips and Suggestions</title>
</head>
<body bgcolor="#000000" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font SIZE="5">Design Tips and Suggestions</font></p>
</b>
<div align="right">
<table border="1" cellpadding="13" width="100%" bordercolor="#808080" bgcolor="#000000">
<tr>
<td width="100%"><font SIZE="2">&nbsp;</font>
<blockquote>
<blockquote>
<p><font size="3">· <font FACE="Times New Roman">The skull
generator in Harvester tosses skulls about it to a maximum distance
of 96 units. The id map designers usually allowed for a drop radius
of 104 to 128 units as a minimum. As a rule, the generator should
drop skulls only in a places accessible to the players. Skulls
should not drop out into death fog or the void.</font></font></p>
<p><font size="3">· <font FACE="Times New Roman">Where you place
the persistent team power-ups is really more a matter of personal
style than a fixed requirement. Generally speaking, we found having
all or most of them in easy view of the initial start positions was
a good thing. In some cases, we found that placing the scout in a
contested area made for interesting game challenges.</font></font></p>
<p><font size="3">· <font FACE="Times New Roman">It is not
necessary to put every team power-up on every map. If a team
power-up would be overpowering on a map, leave it out. If you study
the id team maps, you’ll note that not every map has every power
up. In a small map, the scout can be unreasonable. In a map where
the base is easily attacked and overwhelmed, the guard can unbalance
things. In a map where the base is easily defended by snipers, the
doubler is powerful.</font></font></p>
<p><font size="3">· <font FACE="Times New Roman">For One Flag CTF,
the flag should be placed in an area that is roughly equidistant
from both bases and can be easily reached by players from either
team.</font></font></p>
<p><font size="3">· <font FACE="Times New Roman">The same (as
above) is true for Harvester.</font></font></p>
<p><font size="3">· <font FACE="Times New Roman">You don’t have
to place the white flag and the Harvester skull generator in the
same place in the map.</font></font></p>
<p><font size="3">· <font FACE="Times New Roman">Don’t feel
obligated to put the CTF flag bases, the skull receptacles, and the
Overload skull obelisk in the exact same location in the bases. Just
remember to mark gametypes correctly.</font></font></p>
<p><font size="3">· <font FACE="Times New Roman">Don’t include a
kamikaze in a map where players are unlikely to ever see the full
effect of the explosion.</font></font></p>
<p><font size="3">· <font FACE="Times New Roman">The personal
teleporter entity takes the player to a deathmatch spawn. That’s
how we restricted where the player teleported to in some maps.</font></font></p>
<p><font size="3">· <font FACE="Times New Roman">When converting
Q3A CTF maps with small base areas around their flags will probably
need to have their bases enlarged to accommodate the Overload skull
obelisk.</font></font></p>
<p><font size="3">· <font FACE="Times New Roman">OVERLOAD: When
designing the base for the placement of the skull obelisk, don’t
make it easy for attackers to shoot the obelisk from protected
locations.</font></font></p>
<p><font size="3">· <font FACE="Times New Roman">FLOOR ARROWS: The
graphic arrows were added to map floors to help the players find
their ways through potentially confusing arenas and to give the
player a sense of how close to the flag room he or she might be. The
rule of thumb was that the greater the distance to the flag, the
more stripes or bars would follow the arrow. Exact style of arrow
use varied from mapper to mapper. Study the individual maps to
determine which works best for your own map. The floor arrows act
like decals (if you ever built plastic model kits, these are the
little graphic things that you soaked in water and then stuck on the
surfaces of the model). The images will appear to be a part of the
surface upon which they rest. For the arrows, you will want to build
them as nodraw brushes of the proper dimension with a surface raised
about 2 units above the floor or wall. For the arrow, use
missionpack/proto2/bluea_dcl for the blue arrows and missionpack/proto2/reda_dcl
for the red. You may have to scale and rotate the texture to get
what you want. For more than three trailing bars, add additional
decals and arrange to suit.</font></font></p>
</blockquote>
</blockquote>
</td>
</tr>
</table>
</div>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0" background="../pics/MAINPOP.gif" width="256" height="256">
<tr>
<td width="100%">
<p align="center"><a href="ta_game_types.html">Back</a> <br>
<br>
<a href="table_of_contents.htm">
Table of Contents</a><br>
<br>
<a href="map_converters_checklist.html">
Map Converter's Checklist</a><br>
<br>
-9-</td>
</tr>
</table>
</center>
</div>
</body>
</html>

101
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pages/map_converters_checklist.html Normal file
View file

@ -0,0 +1,101 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Design Tips and Suggestions</title>
</head>
<body bgcolor="#000000" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font SIZE="5">Map Converter’s Checklist</font></p>
</b>
<div align="right">
<table border="1" cellpadding="13" width="100%" bordercolor="#808080" bgcolor="#000000">
<tr>
<td width="100%"><font SIZE="2">&nbsp;</font>
<p><font size="3">The following is a list of things to look for, do, or
be aware of when converting a pre-existing CTF map to Q3:TA game types.</font></p>
<blockquote>
<blockquote>
<p><font size="3"><font FACE="Symbol">· </font>New file name. Don’t
overwrite your old CTF map.</font></p>
<p><font size="3"><font FACE="Symbol">· </font>If you want to
convert an existing Q3A CTF map to the team arena game types, it
would be good to make a clean break from Q3A. Give it a new file
name and even a new map name. We did the same for our original CTF
maps.</font></p>
<p><font size="3"><font FACE="Symbol">· </font>If you don’t
already have one, build a central “neutral” area in keeping with
the style of the rest of the map. This is an important play area,
perhaps even more so than the bases. Make the opportunities for
gameplay here just as exciting as the flag bases.</font></p>
<p><font size="3"><font FACE="Symbol">· </font>Fix-up Time. This is
your opportunity to fix all those things that players have been
telling you are wrong with your map (sticky spots, bad hallway
connections, misaligned textures, poor item placement). The id guys
did it, so can you. It’s also a good time to read or re-read the
Q3Radiant section on optimizing maps for bots (you may want to look
for the recent updates that accompany the bspc tool). Pay particular
attention to placement of clip brushes and cluster portals. If
players can’t reach an area of the map (such as sky above ceiling
grills, or beyond window bars, fill the unreachable space with clip
brush - just walling it off is often worse than doing nothing.</font></p>
<p><font size="3"><font FACE="Symbol">· </font>Add Team Power-ups
in or near bases.</font></p>
<p><font size="3"><font FACE="Symbol">· </font>Place .md3 powerup
pad bases beneath Power-ups</font></p>
<p><font size="3"><font FACE="Symbol">· </font>Remove “ow”
marks from floors that were used as weapon locators. Replace them
with the base floor for that texture. You may also be able to
simplify the geometry.</font></p>
<p><font size="3"><font FACE="Symbol">· </font>Place Weapon pad
markers (use the pfbs) beneath weapon spawns.</font></p>
<p><font size="3"><font FACE="Symbol">· </font>Consider adding new
weapon types or replacing existing ones with the new weapons. Don’t
just do it because they are new, though. Make sure the weapon is
appropriate to the map. If you don’t like a weapon or it’s
effect on play, don’t add it to your map.</font></p>
<p><font size="3"><font FACE="Symbol">· </font>Replace old Q3A CTF
banners with new Q3: TA banners. Use the banner prefabs (pfbs) for
ease of placement.</font></p>
<p><font size="3"><font FACE="Symbol">· </font>Consider adding team
logos as decals (see FLOOR ARROWS above) to other parts of the map,
like walls and floors.</font></p>
<p><font size="3"><font FACE="Symbol">· </font>Make sure that the
team logos on banners and floors; walls, etc. have the proper
facing. You should be able to properly read the word “red” or
“blue” on the placeholder logo.</font></p>
<p><font size="3"><font FACE="Symbol">· </font>Add in the flag
bases and obelisks. Follow directions noted above (page 9) to mark them for
gameplay types.</font></p>
</blockquote>
</blockquote>
</td>
</tr>
</table>
</div>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0" background="../pics/MAINPOP.gif" width="256" height="256">
<tr>
<td width="100%">
<p align="center"><a href="design_tips.html">Back</a> <br>
<br>
<a href="table_of_contents.htm">
Table of Contents</a><br>
<br>
<a href="related_links.html">
Related Links</a><br>
<br>
-10-</td>
</tr>
</table>
</center>
</div>
</body>
</html>

40
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pages/preface.html Normal file
View file

@ -0,0 +1,40 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>If you are already familiar with the tools and processes for making your
own</title>
</head>
<body bgcolor="#000000" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<p align="center">&nbsp;</p>
<p align="center">&nbsp;</p>
<p align="center"><b><font size="4">If you are already familiar with the tools
and processes for making your own </font></b></p>
<p align="center"><b><font size="4">Quake III Arena game maps, then this
document and the other files in this directory </font></b></p>
<p align="center"><b><font size="4">are what you need to create Quake III: Team
Arena maps. If you have previously </font></b></p>
<p align="center"><b><font size="4">created team play style maps (for Capture
the Flag or other game “mods”), </font></b></p>
<p align="center"><b><font size="4">it will not be difficult to add the new game
entities and models.</font></b></p>
<p align="center"><b><font size="4">If you think you might be interested in
making game maps, consider </font></b></p>
<p align="center"><b><font size="4">stopping by the Level Editing forum at <a href="http://quake3world.com" target="_blank">Quake3World</a></font></b></p>
<p align="center"><b><font size="4">registering as a forum user and asking what
you need to do to </font></b></p>
<p align="center"><b><font size="4">get started. From the Quake3World home page,
click </font></b></p>
<p align="center"><b><font size="4">on the “Community” button, and then </font></b></p>
<p align="center"><b><font size="4">select the “Level Editing” button.</font></b></p>
<p align="center">&nbsp;</p>
<p align="center"><font size="3"><a href="../start.html">Back</a> - <a href="table_of_contents.htm"> Table of Contents</a></font></p>
<p align="center"><font size="4">-2-</font></p>
</body>
</html>

51
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pages/related_links.html Normal file
View file

@ -0,0 +1,51 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Related Links</title>
</head>
<body bgcolor="#000000" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Related Links</font></p>
</b>
<div align="right">
<table border="1" cellpadding="13" width="100%" bordercolor="#808080" bgcolor="#000000">
<tr>
<td width="100%">
<p align="center"><font size="3">&nbsp;<a href="http://www.qeradiant.com/" target="_blank">Q3Radiant</a><br>
<a href="http://www.Quake3world.com" target="_blank">Quake3World</a><br>
<a href="http://mapcenter.qeradiant.com" target="_blank">AstroCreep's
Map Center</a><br>
<a href="http://www.claudec.com/" target="_blank">ClaudeC's Lair</a><br>
<a href="http://gamedesign.net/" target="_blank">Rust</a><br>
<a href="http://www.qworkshop3.com/" target="_blank">Q-Workshop3</a><br>
<br>
</font><font SIZE="2"><br>
</font>
</td>
</tr>
</table>
</div>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0" background="../pics/MAINPOP.gif" width="256" height="256">
<tr>
<td width="100%">
<p align="center"><a href="map_converters_checklist.html">Back</a> <br>
<br>
<a href="table_of_contents.htm">
Table of Contents</a><br>
<br>
-11-</td>
</tr>
</table>
</center>
</div>
</body>
</html>

199
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pages/ta_game_types.html Normal file
View file

@ -0,0 +1,199 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Design for all Team Arena Game Types</title>
</head>
<body bgcolor="#000000" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Design for All Team Arena Game Types</font></p>
</b>
<div align="right">
<table border="1" cellpadding="13" width="100%" bordercolor="#808080" bgcolor="#000000">
<tr>
<td width="100%"><font SIZE="2">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font size="3">We
encourage designers to make their maps compatible with all “team”
style games. Team DM and Tournament are the exceptions here. Experience
shows that balanced CTF style maps do not make great (or even good) Team
DM maps. To do this, you will need to mark some of the team game
entities for multiple game types. An example is the obelisk used in
Overload. The entity is also used to mark the location of the
skull-receiving base in Harvester. If your Overload obelisk and your
Harvester base are to be in the same location give the entity a
key/value of “gametype/obelisk, harvester”. If you choose to place
the entities in different locations in each game type, you will need to
place separate entities and mark them appropriately.</font><font SIZE="2">
<p>&nbsp;</p>
</font><b><font FACE="Arial" SIZE="4">
<p>Placing Common Entities for all Game types</p>
</font></b><font SIZE="2">
<p>&nbsp;&nbsp;&nbsp;&nbsp; </font><font size="3"> Typically, the player
start, respawn, power-ups, ammo and weapon placement are the same for
each game type. It helps players if they don’t have to remember a lot
of placement locations from game to game. But this doesn’t have to be
the case. Use the gametype key to control placement if you want them
different between game types.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place
team_CTF_blueplayer entities in the locations where you want blue team
members to join the game and team_CTF_redplayer entities in the
locations where you want red team members to join the game. You should
place enough of these to accommodate the maximum number of players that
will be on a side (though usually no more than 8 to a side in a “normal”
map and as many as 32 in an extremely large terrain map). If you place
too few, teammates are likely to telefrag each other as they join the
game.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place
team_CTF_bluespawn entities in the locations where you want blue team
members to respawn when they die in the game. Place team_CTF_redspawn
entities in the locations where you want red team members to respawn
when they die in the game. You should place enough of these to
accommodate the maximum number of players that will be on a side (though
usually no more than 8 to a side).</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place the four
persistent power-ups (guard, doubler, scout, and ammo_regen) in or near
the bases of each team. On the blue side, check the BLUETEAM spawn flag
box for each entity. On the red side, check the REDTEAM spawn flag box
for each entity. Place (and center) the appropriate spawn spot model
beneath each power-up (spawn.md3 on the blue side, spawn_red.md3 on the
red side).</font></p>
<font SIZE="2">
<p>&nbsp;</p>
</font><b><font FACE="Arial" SIZE="4">
<p>Placing Game-type Specific Entities</p>
</font></b><font SIZE="2">
<p>&nbsp;&nbsp;&nbsp; </font><font size="3">&nbsp; Each of the four
team-style game types has a set of associated entities that go with it,
whether it’s the flags and bases in Capture the Flag, or the obelisk
in Overload.</font></p>
<font SIZE="2"><b>
<p>Capture the Flag (required entities)</p>
</b>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font size="3">This corresponds
to the cvar: “/g_gametype 4” when entered in the console.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Entities in this game
must have a value/key setting of “gametype/ctf”</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a
team_CTF_blueflag in the blue base.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a
team_CTF_redflag in the red base.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a
team_blueobelisk in the blue base where the goal should be. Give it a
facing angle. This forms the flag base. Do not mark any gametype.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a team_redobelisk
in the red base where the goal should be. Give it a facing angle. This
forms the flag base. Do not mark any gametype.</font></p>
<font SIZE="2">
<p>&nbsp;</p>
<b>
<p>One Flag CTF (required entities)</p>
</b>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font size="3">This corresponds
to the cvar: “/g_gametype 5” when entered in the console.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Entities in this game
must have a value/key setting of “gametype/oneflag”</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a
team_CTF_blueflag in the blue base.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a
team_CTF_redflag in the red base.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a
team_blueobelisk in the blue base where the goal should be. Give it a
facing angle. This forms the flag base. Do not mark any gametype.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a team_redobelisk
in the red base where the goal should be. Give it a facing angle. This
forms the flag base. Do not mark any gametype.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a
team_neutralflag some place in the neutral area of the map, preferably
equidistant from both bases.</font></p>
<font SIZE="2">
<p>&nbsp;</p>
<b>
<p>Overload (required entities)</p>
</b>
<p>&nbsp;&nbsp;&nbsp;&nbsp; </font><font size="3"> This corresponds to
the cvar: “/g_gametype 6” when entered in the console.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Entities in this game
must have a value/key setting of “gametype/obelisk”</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a
team_blueobelisk in the blue base where the goal should be. Give it a
facing angle. Do not mark any gametype.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a team_redobelisk
in the red base where the goal should be. Give it a facing angle. Do not
mark any gametype.</font></p>
<font SIZE="2">
<p>&nbsp;</p>
<b>
<p>Harvester (required entities)</p>
</b>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font size="3">This corresponds
to the cvar: “/g_gametype 7” when entered in the console.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Entities in this game
must have a value/key setting of “gametype/harvester”</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a
team_blueobelisk in the blue base. Do not mark any gametype.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a team_redobelisk
in the red base. Do not mark any gametype.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a
team_neutralobelisk some place in the neutral area of the map,
preferably equidistant from both bases.</font></p>
<font SIZE="2">
<p>&nbsp;</p>
<b>
<p>Using Entities for All Gametypes</p>
</b>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; </font><font size="3">This assumes
that the designer will use the same entities, in the same locations for
all gametypes. Mark the gametypes on each entity as noted:</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a
team_CTF_blueflag in the blue base.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gametype: ctf, oneflag</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a
team_CTF_redflag in the red base.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gametype: ctf, oneflag</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a
team_blueobelisk in the blue base where the goal should be. Give it a
facing angle. This forms the flag base.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gametype: Do not mark
any gametype.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a team_redobelisk
in the red base where the goal should be. Give it a facing angle. This
forms the flag base.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gametype: Do not mark
any gametype.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a
team_neutralobelisk some place in the neutral area of the map,
preferably equidistant from both bases.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gametype: harvester</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Place a
team_neutralflag some place in the neutral area of the map, preferably
equidistant from both bases.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Gametype: oneflag</font></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0" background="../pics/MAINPOP.gif" width="256" height="256">
<tr>
<td width="100%">
<p align="center"><a href="using_new_game_entities.html">Back</a> <br>
<br>
<a href="table_of_contents.htm">
Table of Contents</a><br>
<br>
<a href="design_tips.html">
Design Tips</a><br>
<br>
-8-</td>
</tr>
</table>
</center>
</div>
</body>
</html>

77
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pages/table_of_contents.htm Normal file
View file

@ -0,0 +1,77 @@
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Table of Contents</title>
</head>
<body bgcolor="#000000" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<p align="center"><font face="Impact" size="6">Table of Contents<br>
</font><font size="3">(HTML Conversion by AstroCreep)</font></p>
<div align="right">
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td width="50%">
<p align="right"><font size="3"><a href="../start.html">Title</a>..........................1<br>
<br>
<a href="preface.html">
Preface</a>..........................2<br>
<br>
<a href="table_of_contents.htm">
Table of Contents</a>..........................3<br>
<br>
<a href="team_arena_entity_definitions.html">
Team Arena Entity Definitions</a>..........................4<br>
<br>
<a href="team_arena_prefabs.html">
Team Arena Prefabs</a>..........................5<br>
<br>
<a href="team_powerup_bases.html">
Team Power-Up Bases</a>..........................6<br>
<br>
<a href="using_new_game_entities.html">
Using the New Game Entities</a>..........................7<br>
<br>
<a href="ta_game_types.html">
Design for All Team Arena Game Types</a>...........................8<br>
<br>
<a href="design_tips.html">
Design Tips and Suggestions</a>...........................9<br>
<br>
<a href="map_converters_checklist.html">
Map Converter’s Checklist</a>.........................10<br>
<br>
<a href="related_links.html">Related Links</a>.........................11<br>
</font></p>
</td>
<td width="50%" align="center"><img border="0" src="../pics/MENUBACKgif.gif" width="370" height="310"></td>
</tr>
</table>
</div>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0" background="../pics/MAINPOP.gif" width="256" height="256">
<tr>
<td width="100%" align="center">
<p align="center"><a href="preface.html">Back</a><br>
<br>
<a href="table_of_contents.htm">
Table of Contents</a><br>
<br>
<a href="team_arena_entity_definitions.html">
T A Entity Definitions</a><br>
<br>
-3-</td>
</tr>
</table>
</center>
</div>
<p align="center">&nbsp;</p>
</body>
</html>

66
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pages/team_arena_entity_definitions.html Normal file
View file

@ -0,0 +1,66 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Team Arena Entity Definitions</title>
</head>
<body bgcolor="#000000" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Team Arena </font><font size="5">Entity
Definitions</font></p>
<div align="right">
<table border="1" cellpadding="13" width="100%" bordercolor="#808080" bgcolor="#000000">
<tr>
<td width="100%"><font size="3">The enclosed </font></b><font size="3"><b>tadef_ptch.def</b><b>
</b>file a bare bones list of entity descriptions for use in the Q3Radiant
editor. You can paste it onto the end of your current def file (or better
yet, into a copy of that file).</font>
<p><font size="3">This is the Quake III: Team Arena entities definition
file patch (note that it is not the entire definition file). The Q3Radiant
editing tool uses this data to place game entities (ammo, weapons,
power-ups, etc.) in the game map and the game. It contains the definitions
for all the power-ups, game-specific items (like the Obelisks from
Harvester and Overload). To use these definitions, open the text file and
copy it. Now open the definitions file that you are currently using
(probably in Baseq3/Scripts) and paste the contents of your clipboard at
the end of the file. Now save this modified document as “teamarena.def”
in a folder in your Quake III Arena folder called Missionpack/scripts.
Open the Q3Radiant editor. Click on the File menu, and then select the “Project
Settings” entry. This brings up the Project Settings pop-up window.
Change the entitypath field so the pathname leads to the new definitions
file.</font></p>
<p><font size="3">Example: If the field currently reads c:/quake3 or
g:/quake3/missionpack/scripts/*.def, change it to
c:/quake3/baseq3/scripts/teamarena.def</font></p>
<b>
<p>&nbsp;</b></td>
</tr>
</table>
</div>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0" background="../pics/MAINPOP.gif" width="256" height="256">
<tr>
<td width="100%">
<p align="center"><a href="table_of_contents.htm">Back</a> <br>
<br>
<a href="table_of_contents.htm">
Table of Contents</a><br>
<br>
<a href="team_arena_prefabs.html">
&nbsp;Team Arena Prefabs</a><br>
<br>
-4-</td>
</tr>
</table>
</center>
</div>
<p align="center">&nbsp;</p>
</body>
</html>

96
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pages/team_arena_prefabs.html Normal file
View file

@ -0,0 +1,96 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Team Arena Entity Definitions</title>
</head>
<body bgcolor="#000000" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Team Arena Prefabs</font></p>
<div align="right">
<table border="1" cellpadding="13" width="100%" bordercolor="#808080" bgcolor="#000000">
<tr>
<td width="100%"><font size="3">There are eight prefabricated brush groups
in this folder. They are pre-built game components (using brushes and/or
curve patches) for some of the objects frequently used in Quake III:
Team Arena. The shader scripts and textures for these prefabs are
already a part of the Team Arena Mission Pack pak file and need not be
added separately.</font>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The pads act like
decals (if you ever built plastic model kits, these are the little
graphic things that you soaked in water and then stuck on the surfaces
of the model). The images will appear to be a part of the surface upon
which they rest. For the pads, you will want to place them in such a way
that they are centered under the entity boxes above them. The surface of
the pad should be one to two units above the surface beneath them.</font></p>
<p><font size="3">When positioning the banners, the banner brush should
not touch the surface behind it.</font></p>
<b>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp; armorpad_blue.pfb</font></b><font size="3">
Place this prefab beneath yellow and/or red armor on the blue team’s
side.</font></p>
<b>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp; armorpad_red.pfb </font></b><font size="3">Place
this prefab beneath yellow and/or red armor on the red team’s side</font></p>
<b>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp; armorpad_neutral.pfb</font></b><font size="3">
Place this prefab beneath yellow and/or red armor in neutral areas.</font></p>
<b>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp; weaponpad_blue.pfb</font></b><font size="3">
Place this prefab beneath weapons and (non persistent) power-ups on the
blue team’s side.</font></p>
<b>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp; weaponpad_red.pfb</font></b><font size="3">
Place this prefab beneath weapons and (non-persistent) power-ups on the
red team’s side.</font></p>
<b>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp; weaponpad_neutral.pfb</font></b><font size="3">
Place this prefab beneath weapons and (non-persistent) power-ups in the
map’s neutral areas (in between bases).</font></p>
<b>
<p><font size="3">TA_banner_blue.pfb</font></b><font size="3"> This
prefab is a smallish blue team flag with the placeholder blue team logo
placed over the flag surface as a decal. During game play, this logo
will change to show the logo selected by the blue team. Designers may
wish to scale the size or proportions of this banner to suit their
needs. Always make sure that the word “blue” on the logo reads
correctly. Otherwise, non-symmetrical team logos will appear backwards
on the banner.</font></p>
<b>
<p><font size="3">TA_banner_red.pfb</font></b><font size="3"> This
prefab is a red team flag with the placeholder red team logo placed over
the flag surface as a decal. During game play, this logo will change to
show the logo selected by the red team. Designers may wish to scale the
size or proportions of this banner to suit their needs. Always make sure
that the word “red” on the logo reads correctly. Otherwise,
non-symmetrical team logos will appear backwards on the banner.</font></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</b>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0" background="../pics/MAINPOP.gif" width="256" height="256">
<tr>
<td width="100%">
<p align="center"><a href="team_arena_entity_definitions.html">Back</a> <br>
<br>
<a href="table_of_contents.htm">
Table of Contents</a><br>
<br>
&nbsp;<a href="team_powerup_bases.html">Team Power-up Bases</a>
<p align="center">-5-</td>
</tr>
</table>
</center>
</div>
<p align="center">&nbsp;</p>
</body>
</html>

62
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pages/team_powerup_bases.html Normal file
View file

@ -0,0 +1,62 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Team Arena Entity Definitions</title>
</head>
<body bgcolor="#000000" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Team Power-up Bases</font></p>
</b>
<div align="right">
<table border="1" cellpadding="13" width="100%" bordercolor="#808080" bgcolor="#000000">
<tr>
<td width="100%"><font size="3">In Quake III: Team Arena, a base model
marks the location of each of the four persistent Team Power-Ups (Ammo
Regen, Guard, Doubler, and Scout). These models are not generated
programmatically (as is the case with the obelisks and flag bases) and
must be placed in the game maps by the mapmaker. Position the model such
that the center of its origin sits on top of the floor and so that it is
centered beneath the Team Power-Up. There are separate models for the
blue and red team sides. If you choose to place a powerup in neutral
territory (as in MPTERRA3), place a weaponpad_neutral.pfb under the
powerup.</font>
<p><font size="3">Copy the spawn folder into the models/mapobjects
directory in your missionpack directory (if necessary, create all three
directories now). Do not create a new directory for them. Shader scripts
and textures for these models are already a part of the Mission Pack pak
file and need not be added separately.</font></p>
<p><font size="3"><b>spawn.md3</b>&nbsp; This model is the location marker for the
blue side.</font></p>
<p><font size="3">s<b>pawn_red.md3</b>&nbsp; This model is the location marker for
the red side.</font></p>
<b>
<p>&nbsp;</b></td>
</tr>
</table>
</div>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0" background="../pics/MAINPOP.gif" width="256" height="256">
<tr>
<td width="100%">
<p align="center"><a href="team_arena_prefabs.html">Back</a> <br>
<br>
<a href="table_of_contents.htm">
Table of Contents</a><br>
<br>
&nbsp;<a href="using_new_game_entities.html">New Game Entities</a>
<p align="center">-6-</td>
</tr>
</table>
</center>
</div>
<p align="center">&nbsp;</p>
</body>
</html>

115
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pages/using_new_game_entities.html Normal file
View file

@ -0,0 +1,115 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Team Arena Entity Definitions</title>
</head>
<body bgcolor="#000000" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Using New Game Entities</font></p>
</b>
<div align="right">
<table border="1" cellpadding="13" width="100%" bordercolor="#808080" bgcolor="#000000">
<tr>
<td width="100%"><font size="3">The best way to get a feeling for how the
new game entities should be used is to play Team Arena for a while. Here
are the id team’s rules and suggestions for using the new entities.</font><font SIZE="2">
<p>&nbsp;</p>
</font><b>
<p><font face="Arial" size="3">Game Types</font></p>
</b>
<p><font size="3">There are eight game types (including those from
original Quake III Arena). Unless marked with a gametype key, entities
will appear in every game type. The game types are:</font></p>
<b>
<p><font size="3">Gametype Type of play corresponds to cvar …</font></p>
</b>
<p><font size="3">FFA (multiplayer Free for All deathmatch) corresponds
to g_gametype 0</font></p>
<p><font size="3">Tournament (1 on 1 deathmatch) corresponds to
g_gametype 1</font></p>
<p><font size="3">Single (Single Player Free for All) corresponds to
g_gametype 2</font></p>
<p><font size="3">Team (Team deathmatch) corresponds to g_gametype 3</font></p>
<p><font size="3">CTF (Capture the Flag … traditional rules)
corresponds to g_gametype 4</font></p>
<p><font size="3">Oneflag (single flag CTF) corresponds to g_gametype 5</font></p>
<p><font size="3">Overload (destroy the opponent’s obelisk)
corresponds to g_gametype 6</font></p>
<p><font size="3">Harvester (collect skulls, take to opponent’s base)
corresponds to g_gametype 7</font></p>
<font SIZE="2">
<p>&nbsp;</p>
</font><b>
<p><font face="Arial" size="3">The “notfree”, “notteam”, and “notsingle”
Keys</font></p>
</b>
<p><font size="3">These are still checked by the game engine. They are
checked AFTER the gametype keys are checked. Because they complicate the
design (simple is usually best), we recommend not using them in Quake 3
Team Arena maps.</font></p>
<font SIZE="2">
<p>&nbsp;</p>
</font><b>
<p><font face="Arial" size="3">Enable/Disabled entities for TA / Vanilla Q3</font></p>
</b>
<p><font size="3">
Entities can now have one of the following epairs:
</font></p>
<p><font size="3">
"notta" "1"
</font></p>
<p><font size="3">
for when the entity is not supposed to show up in Team Arena, and:
</font></p>
<p><font size="3">
"notq3a" "1"
</font></p>
<p><font size="3">
for when the entity is not supposed to show up in Quake III Arena.
</font></p>
<p><font size="3">
An entity may have both epairs, meaning it will only show up in mods.
</font></p>
<p><font size="3">
The epairs only work on "gameplay" type entities such as weapons,
powerups, items, ammo, etc. They will not affect entities that are
compiled into maps, such as models.
</font></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
<div align="center">
<center>
<table border="0" cellpadding="0" cellspacing="0" background="../pics/MAINPOP.gif" width="256" height="256">
<tr>
<td width="100%">
<p align="center"><a href="team_powerup_bases.html">Back</a> <br>
<br>
<a href="table_of_contents.htm">
Table of Contents</a><br>
<br>
<a href="ta_game_types.html">T.A. Game Types</a>
<p align="center">-7-</td>
</tr>
</table>
</center>
</div>
<p align="center">&nbsp;</p>
</body>
</html>

BIN
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pics/CRUSADER.gif Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 4.2 KiB

BIN
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pics/INTRUDER.gif Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 4.6 KiB

BIN
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pics/MAINPOP.gif Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 25 KiB

BIN
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pics/MENUBACKgif.gif Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 21 KiB

BIN
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pics/PAGANs.gif Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 3.8 KiB

BIN
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pics/STROGGS.gif Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 4.8 KiB

BIN
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pics/THEFALLEN.gif Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 5.2 KiB

BIN
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/pics/logo.gif Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 41 KiB

30
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Team_Arena_Mapping_Help/start.html Normal file
View file

@ -0,0 +1,30 @@
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>MAPPING HELP</title>
</head>
<body bgcolor="#000000" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<p align="center">&nbsp;</p>
<p align="center"><img border="0" src="pics/logo.gif" width="512" height="150"></p>
<p align="center"><font face="Impact" size="7"><span style="letter-spacing: 7pt">MAPPING
HELP</span></font></p>
<p align="center"><strong><span style="letter-spacing: 6pt"><font size="4">by
Paul Jaquays</font><font face="Impact" size="4"><br>
</font><font size="1">Copyright © 2000 id software, inc.</font></span></strong></p>
<p align="center"><img border="0" src="pics/INTRUDER.gif" width="128" height="128">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<img border="0" src="pics/PAGANs.gif" width="128" height="128">&nbsp;&nbsp;&nbsp;
<img border="0" src="pics/STROGGS.gif" width="128" height="128">&nbsp;&nbsp;&nbsp;
<img border="0" src="pics/THEFALLEN.gif" width="128" height="128">&nbsp;&nbsp;&nbsp;
<img border="0" src="pics/CRUSADER.gif" width="128" height="128"></p>
<p align="center">&nbsp;</p>
<p align="center"><font face="Impact" size="5"><b><a href="pages/preface.html">START</a></b></font></p>
</body>
</html>

BIN
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/Image3.gif Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 46 KiB

BIN
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/Image4.gif Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 24 KiB

BIN
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/Image5.gif Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 27 KiB

BIN
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/Image6.gif Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 46 KiB

40
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/adding_bots.html Normal file
View file

@ -0,0 +1,40 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Adding Bots</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b><font SIZE="5">
<p align="center">Adding Bots</p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Despite their massive size, terrain maps can support enjoyable bot play. The
key is careful placement of cluster portals, which is true of any map. Study the
bspc documentation for details. The documents accompanying the tools are more up
to date than those in the Q3Radiant manual. Your goal should be to keep the
number of areas in each cluster roughly equal and reasonably low (hundreds, not
thousands).</p>
</font>
<p align="center"><a href="adding_buildings_to_terrain.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="glossary.html">Glossary</a></p>
</td>
</tr>
</table>
</div>
</font></b>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p align="center">-25-</p>
</body>
</html>

85
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/adding_buildings_to_terrain.html Normal file
View file

@ -0,0 +1,85 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Adding Buildings to Terrain</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b><font SIZE="5">
<p align="center">Adding Buildings to Terrain</p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>This is really best addressed as a number of semi-related building tips:</p>
<b>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Plan Ahead.</b> If you know you want buildings
in your map, plan their locations from the first. Very complicated buildings
(lots of geometry and surface detail) should be isolated away from long views.
One reason for this is to control in view polygon counts. The second (and really
obscure one) is to reduce the amount of z-compression that will affect the
structures.</p>
<b>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Build to Support Game play.</b> Each of the
structures in the Q3:TA terrain maps was built to support a game play need.
Quite often, less is better than more.</p>
<b>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Build Simply.</b> Simple, uncomplicated
architecture may be best. The more complicated you make your buildings, the less
complicated the terrain around them can be. Depends on what you want to play up.
The busy look of many Q3A maps doesn’t translate well to large terrain.
Details are lost at great distances and only add to the triangle complexity of
maps containing them.</p>
<b>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Detail Content.</b> With few exceptions ALL
the geometry inside the terrain map is detail content, not just the terrain
entity. The walls forming the corridor in mpterra2 may be the only non-detail
structures in that map. Making geometry into detail makes a map far easier and
faster to compile. If you want to block vis inside your structures, create
simple caulk structures … much the same way as described for vis blocking the
terrain.</p>
<b>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Z-Compression Problems.</b> Review the the map
in 16 bit mode during development. This brings out z-fighting issues that occur
at long distances. This z-fighting is created by detail brushes being compressed
into each other (The Q3A engine does a significant amount of “z compression”
as geometry becomes farther away from the viewer). This z-compression is far
less apparent in 32 bit modes, but we have to remember that many people turn
down graphic features in order to simply play Q3A on their systems (not just to
get ridiculously high frame rates).</p>
<b>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Fit Structures to the Terrain. </b>Don’t
just set structures on terrain and expect them to look right. Make your
buildings look like they belong where you put them. Accommodate the rise and
fall of terrain in your floor plans … or “dig” into the terrain brushes to
create basements, tunnels and whatever you need. You can also adjust the height
map to better arrange the geometry around structures, or manually tweak the
triangles once the structures are in place. History is full of examples of
really interesting buildings that have been built to accommodate difficult
terrain like hills, cliffs and mountains.</p>
<p>&nbsp;</p>
<blockquote>
<blockquote>
</font>
</blockquote>
</blockquote>
<p align="center"><a href="terrain_related_worldspawn_features.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="adding_bots.html">Adding Bots</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</font></b>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p align="center">-24-</p>
</body>
</html>

39
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/art_tools.html Normal file
View file

@ -0,0 +1,39 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Art Tools Required</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b><font SIZE="5">
<p align="center">Art Tools Required</p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The creation of terrain maps requires that the mapmaker have, or have access
to a computer art program. Both <a href="http://www.jasc.com" target="_blank"> JASC’s Paint Shop Pro</a> and
<a href="http://www.adobe.com" target="_blank"> Adobe’s Photoshop</a>
were tested and will do the job. Any art program that can output an 8-bit BMP
format file with indexed color should work also.</p>
</font>
<p align="center"><a href="key_changes.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a>- <a href="terrain_entity.html"> The Terrain Entity</a></p>
</td>
</tr>
</table>
</div>
</font></b>
<p align="center">&nbsp;</p>
<p align="center">&nbsp;</p>
<p align="center">&nbsp;</p>
<p align="center">-5-</p>
</body>
</html>

101
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/blocking_vis.html Normal file
View file

@ -0,0 +1,101 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Blocking Vis</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Blocking Vis</font></p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Terrain maps still have to follow the rules that apply to all Q3A engine
maps. There’s only so much that you can allow to be seen at one time, or the
game starts slowing down. The good news is that the engine will only draw the
terrain triangles that are in the player’s PVS (potential visible set). It
doesn’t have to draw all the triangles in the terrain entity just because part
of the entity is in view.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; At first, most of the usual bag of tricks that mappers use to create vis
blocking structures in architectural maps don’t seem to apply to terrain. But
that is not the case. If anything, you <font color="#FFFF00"> NEED</font> to think of terrain in much the same
way as you think of buildings. You are still dealing with open spaces that could
be considered corridors and large rooms … even though they look like large
valleys.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In fact, it would be best to plan out the layout of your terrain
<font color="#FFFF00"> BEFORE</font>
creating your height map. If you know you want to block vis, you can design your
terrain to work with vis blocking techniques and avoid the agony of having to go
all the way back to the start when you discover that your killer terrain map
lets you see too much at once.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If you want the player, even in spectator mode, to be able to fly everywhere
and see the whole world laid out below him … an unrestricted vista, so to
speak, you’re going to be much more limited. Every single triangle in the map
will essentially be viewable at any moment in time. However, if you’re willing
to place restrictions on your players - limit how high they can fly or climb,
you suddenly have more options for blocking player visibility.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; First, the terrain entity is entirely detail content, so it doesn’t block
vis. That’s a key part of how this whole process works. Otherwise, vis time
would be measured in eras (not minutes or hours) and visdata size would be very,
very large.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To block vis in the terrain, start by creating simple
vis-blocking structures
out of caulk texture inside the forms of the terrain (they are not part of the
terrain entity). You can try to match the silhouette of the terrain, but in the
end, you may only end up complicating the visdata without gaining any real
benefit.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Next, and this is going to sound strange, build thin walls of caulk that
follow the divide line (where the terrain falls away on both sides) of the
highest mountains, buttes or hills. Only do this where you know that you will
not allow the player to move over or see over </font><font FACE="Times New Roman" COLOR="#000000">that
part of the terrain (we’ll talk about clipping real soon).</p>
<p>&nbsp;</p>
</font><b><font SIZE="4">
<p>Other Tips:</p>
<blockquote>
<blockquote>
</font></b><font FACE="Symbol" SIZE="2">
<p>· </font><b><font FACE="Times New Roman">Sky Texture in Place of Caulk:</font></b><font FACE="Times New Roman">
You sometimes want to apply the sky texture to some of the surfaces of the thin
walls used as vis blockers. This can remove some HOM effects. The caulk brushes
that block the vis around the bases in mpterra2 have sky texture painted on the
surfaces facing the base.</p>
</font><font FACE="Symbol" SIZE="2">
<p>· </font><b><font FACE="Times New Roman">Hint Brushes:</font></b><font FACE="Times New Roman">
Use these extremely sparingly and only after trying to solve the problem in
other ways. Hint brushes can add hours to vis compile times. Even so, they can
make a difference. One trick you can try is to put a horizontal hint brush at a
point about midway up the slopes of your terrain. It can add some additional vis
break points.</p>
</font><b><font FACE="Symbol" SIZE="2">
<p><font color="#FFFFFF">· </font> </font><font FACE="Times New Roman" color="#FFFFFF">Adjusting Terrain:</font></b><font FACE="Times New Roman" color="#FFFFFF">
Vis times totally depend on the placement of your vis blockers. Vis times are
not affected by modifying the terrain surfaces (terrain entities are detail
content, remember?). With that being said, you may want to modify the terrain to
allow you to more effectively position the vis-blockers.
</font>
</p>
</blockquote>
</blockquote>
<p align="center"><a href="terrain_texture.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="clipping_the_terrain.html">Clipping the Terrain</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</b>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p align="center">-18-</p>
</body>
</html>

48
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/boxing_in_the_world.html Normal file
View file

@ -0,0 +1,48 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Boxing in the World</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Boxing in the World</font></p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It may not need mentioning here, but … the terrain entity needs to be
contained inside a sealed world. For the terrain maps in Q3:TA, we built huge
boxes. Any portion of the box that could be seen while playing the game, or
flying around in spectator mode was covered in sky texture. Any portion of the
box that could not be seen was made out of common/caulk. If mountains or canyon
walls surround your map, plan to bring the caulk portion of the wall up as high
as you can. This can reduce the number of triangles seen in the map. Generally
speaking, you will see ALL the sky triangles inside the map at all times.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Finally, and this is a part of vis blocking, but it should also be noted
here. Don’t forget to place large caulk structures that rise up from the
bottom of the world box to near the ground surfaces of terrain entity. If the
ground level rises and falls substantially, these can be a part of the vis
blocking process. Otherwise they serve to reduce the size of the map’s total
volume (generally speaking … a good thing).</p>
</font>
<p align="center"><a href="terrain_mesh_into_terrain_entity.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="entity_keys_and_values.html">Entity Keys and Values</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</b>
<p align="center">&nbsp;</p>
<p align="center">&nbsp;</p>
<p align="center">-14-</p>
</body>
</html>

58
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/clipping_the_terrain.html Normal file
View file

@ -0,0 +1,58 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Clipping the Terrain</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5" color="#FFFFFF">Clipping the Terrain</font></p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The terrain entity uses its triangle surfaces as clipping planes. No
additional clipping is required to allow characters to run on the terrain’s
surface. As the initial terrain maps developed in house, we discovered that to
control and guide play flow, we needed to clip many of our mountain and canyon
slopes with vertical walls. Done right (as the slopes start becoming too steep
to climb), players don’t notice (as much).</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Next, decide how far up in the sky you are willing to let your player’s
fly. If the map is entirely open you might want to keep it that way. If you’ve
placed caulk barriers as described above, then the low point on the ridgeline
(or lower) will likely be your ceiling height.</p>
<b>
<p>Clipping Tips</p>
<blockquote>
<blockquote>
</b></font><font FACE="Symbol" SIZE="2">
<p>· </font><font FACE="Times New Roman">Make sure your “ceiling” clip
brushes extend all the way up the sky brush.</p>
</font><font FACE="Symbol" SIZE="2">
<p>· </font><font FACE="Times New Roman">Keep your clip brushes simple.</p>
</font><font FACE="Symbol" SIZE="2">
<p>· </font><font FACE="Times New Roman">Right angles are rarely found in
nature. Use the clipper tool to take the corners off your vertical clips.</p>
</blockquote>
</blockquote>
</font>
<p align="center"><a href="blocking_vis.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="mapping_the_textures.html">Mapping the Textures</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</b>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p align="center">-19-</p>
</body>
</html>

194
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/creating_the_alphamap.html Normal file
View file

@ -0,0 +1,194 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Creating the Alphamap</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Creating the Alphamap</font></p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The alphamap referenced by the alphamap key/value pair is an art file created
specifically for the map. For non-digital artists, it may be one of the more
technically and conceptually challenging things that need to be created to make
the terrain map work.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Simply put, the alpha map is the template that the compiler uses to assign
textures to the terrain surface.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; To make the alphamap, you must have, or have access to, an art program that
can save a file as an 8-bit BMP file with indexed color. I’ll discuss other
file types later on, but the BMP file is probably the simplest solution, both
technically and conceptually.</p>
<p>&nbsp;</p>
</font><b><font SIZE="4">
<p>Terms</p>
</font></b><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; First, you need to understand a couple vocabulary words … jargon, if you
will:</p>
<b>
<p>Indexed Color:</b> In essence, each color used in a piece of art is
remembered by its location on the color table or palette (see below). There are
256 colors available, numbered from 0 to 255. Each position on the palette has
its own number. This number has nothing to do with the RGB values of a color in
that position. If you change the actual color located at a particular location
on the palette (say from red to blue), all the pixels that were formerly that
shade of red (if painted using a color with that index number), will change to
the new color of blue.</p>
<b>
<p>Color Table:</b> This is what Photoshop calls the indexed color layout of 256
colors. In Paint Shop Pro it’s a palette. This is a pop-up window that shows
the colors in the palette and their arrangement. For making an alphamap for a
terrain map, the colors you choose are not important, but their position on the
palette is.</p>
<b>
<p>Palette:</b> This is what Paint Shop Pro calls a Color Table.</p>
<p>&nbsp;</p>
</font><b><font SIZE="4">
<p>Making the Palette</p>
</font></b><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The best way to start is to make a set of colors to use when painting
alphamaps. If you want, you can do this once and save it out. In PSP edit the
palette (in Photoshop, open the Color Table). Make sure the colors are sorted by
index number (there may be a pull down menu that allows this). In PSP, the
colors are indexed from the upper left (color 0 in the upper leftmost position
and increasing in value to the right). In Photoshop, the positions are reversed.
The color with value 0 is in the lower rightmost position and the index numbers
increase to the right.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Because there is a direct one-to-one relationship between colors in the
palette and individual shaders that make of the metashader, you should select
clearly distinct colors to represent each shader. You should have one color for
each layer you intend to include in the map (see keys above), which means one
color to represent each root shader. You may find it convenient to create more,
so they are available for later use (if you save the palette).</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This method worked for me to make a 16-color palette in Paint Shop Pro.
First, I reduced my palette size to 16 colors. I clicked on each palette
position and created a color for it (don’t use black). Then, I increased my
palette size back up to 256 colors, filling the rest with black. In Photoshop,
it’s easier to select all the colors you don’t intend to use and make them
black. Then, I save the palette out as a file for later use.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Another thing you might try is to make a grayscale palette, then use only the
first few positions for your color and leave the rest for grayscale (this allows
you to import bmp height maps and use them as guidelines).</p>
<p>&nbsp;</p>
</font><b><font SIZE="4">
<p>Alphamap File Data</p>
</font></b><font FACE="Times New Roman"><b>
<p>File type:</b> The alphamap is a BMP format file or a TGA file (see other
file formats below). With BMP format, each color in your palette corresponds
directly to a root shader used to create the smooth texture blends on the
terrain.</p>
<b>
<p>File size:</b> The size of the alphamap should be one-to-one with the number
of vertexes in the map. If you have 64 divisions x 32 divisions in your terrain
mesh (65x33 vertexes), you should use a 65 by 33 alphamap. You can use an
alphamap with a size that is not a one-to-one map with the number of map
vertexes, but you can then expect a less precise interpretation of your texture
assignments.</p>
<b>
<p>Colors linked to Shaders:</b> If an 8-bit texture is used (BMP), q3map links
a color’s position on the palette to an identifying number in the name of a
shader. The color in position 0 would reference a root shader named &lt;metashadername&gt;_0.
The color in position 1 would reference a root shader named &lt;metashadername&gt;_1.
&lt;metashadername&gt; refers to the value of the Shader key (see Key: Shader
below). In theory, you could probably have 256 different root shaders assigned
to the terrain entity. In practice, you’d probably want to bite your arm off
at the elbow before doing something as complicated as that.</p>
</font><b><font SIZE="4">
<p>Other File Formats</p>
</font></b><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It is possible to use a TGA file (a RGB color format) for an
alphamap. TGA
files are handled differently than indexed color files like BMP. Instead of
looking for a position on the palette, q3map interprets the RGB value of actual
color. With a 32-bit TGA file, only the color values in the red channel are
used. The program assumes that a gray scale of equal values is being used. The
program divides the colors by the number of levels into equal-sized ranges. When
assigning textures, q3map looks at what range the color falls in and chooses the
appropriate shader to place or blend.</p>
</font><b><font SIZE="4">
<p>Controlling Texture Blends</p>
</font></b><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Each triangle on the mesh can only have two root shaders blending across it.
Another way to say this is that there should be only two different colors on the
three vertexes that form any given triangle in the mesh. Any more, and a sharp,
unblended edge appears on the terrain surface. This can take some trial and
error to correct. A bsp -switch command called -showseams can help the mapmaker
find these errors. Create a new bsp command in your project file that includes
this option. We recommend doing it with a novis only operation.</p>
</font><font FACE="Times New Roman" SIZE="2">
<p align="center"><img SRC="Image5.gif" WIDTH="266" HEIGHT="352">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
<img SRC="Image6.gif" WIDTH="264" HEIGHT="352"></p>
</font><font FACE="Times New Roman">
<p>Figure 3</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; In figure 3, the blue and white image on the left is a scaled up (4X) version
of the alphamap used on Distant Screams. It shows three different root shaders
in use. Compare that to the gray scale height map on the right and you can see
how the artist chose to assign textures to the various heights and depths of the
map. As long as the guidelines for texture placement are followed, a mapmaker
should be able to work with more different root shaders than shown here.</p>
</font><b><font SIZE="4">
<p>Alphamap Creation Tips:</p>
<blockquote>
<blockquote>
</font></b><font FACE="Symbol" SIZE="2">
<p>· </font><font FACE="Times New Roman">The alphamaps for the team arena maps
are included with this document, both as reference and as files that you can
modify to work with your own maps. You may want to compare the alphamaps against
the heightmaps for the same maps, just to see how id resolved mapping issues.</p>
</font><font FACE="Symbol" SIZE="2">
<p>· </font><font FACE="Times New Roman">You can create a quick (though not
necessarily good) alphamap by saving your height map as a new file. Then use the
“posterize” filter that can be found in some art tools. Reduce the number of
colors in the art to equal the layers (number of unique root shaders) in the
terrain.</p>
</font><font FACE="Symbol" SIZE="2">
<p>· </font><font FACE="Times New Roman">If you are creating a new alphamap
from scratch, use colors that are easily distinguished from each other.</p>
</font><font FACE="Symbol" SIZE="2">
<p>· </font><font FACE="Times New Roman">If you are making an alphamap for a
team style map where both sides of the map are identical (mirrored or rotated),
you only need to design the map for one side. Copy and position it as described
above for the heightmap.</p>
</font><font FACE="Symbol" SIZE="2">
<p>· </font><font FACE="Times New Roman">The id maps used simple color schemes
that were homogenous throughout the maps. That is not the only way of doing
things. It would be quite reasonable to use many more terrain textures
(particularly if you weren’t going to build complicated, multi-texture
architecture on top of them). Consider a map where one part of the terrain used
red-themed textures and the other side blue themed textures. Have them blend
into a few simple neutral colors near the map center.</p>
</font><font FACE="Symbol" SIZE="2">
<p>· </font><font FACE="Times New Roman">Try doing terrain style texture
mapping on non-terrain geometry. Results will definitely vary, but some could be
interesting.</p>
</blockquote>
</blockquote>
<b>
<p>Samples:</b> The last height map and the alphamap used to create each of the
terrain maps in Team Arena is included in the Mapping Support folder. Note that
the designers made vertex manipulations to the final terrain meshes that are not
reflected in these height maps. Also, the alphamaps are in PCX format, not BMP
format.</p>
</font>
<p align="center"><a href="entity_keys_and_values.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="terrain_texture.html">The Terrain Texture</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</b>
<p align="center">&nbsp;</p>
<p align="center">&nbsp;</p>
<p align="center">-16-</p>
</body>
</html>

63
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/creating_the_terrain.html Normal file
View file

@ -0,0 +1,63 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Creating the Terrain</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<p align="center"><b><font size="5">Creating the Terrain “Mesh”</font></b></p>
<font SIZE="4">
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Although it’s not necessarily the only way to develop a piece of terrain,
thinking of it and creating it as “mesh” of triangular brushes may be the
easiest way to work initially. The terrain sections for Quake III: Team Arena
were built in this manner, though each designer went about it in slightly
different ways.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Our primary tool was a plugin for <a href="http://www.qeradiant.com/" target="_blank"> Q3Radiant</a> , created by David Hyde, called
<a href="http://tarot.telefragged.com/gensurf/" target="_blank">GenSurf</a>. The tool was originally created for Quake 2 (and may have been around
longer) and has been adapted for use with many of the game engines using Quake,
Quake2 and Quake3 technology. The basic concept behind GenSurf is that it can
create and export a group of brushes (or curve patches) to Q3Radiant that have
the look of “natural” terrain about them. Within the plug-in, the mapmaker
has control over the horizontal dimensions of the terrain entity, the steepness
of the slopes it creates, and the number of columns and rows of triangles that
it subdivides into.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The terrain can be generated from within the tool by using simple waveforms,
more complex mathematical expressions, fractal calculations, or height maps. The
last item, height maps, is in our opinion, the route to take for creating
complex, visually interesting terrain layouts. A height map is a piece of art
(we rendered them in grayscale) that GenSurf uses as a template for establishing
the height of vertexes (the points where the corners of the terrain triangles
meet). GenSurf interprets the color of the pixel (or more correctly the
numerical color value of the pixel) that corresponds to the location of the
vertex. Generally, the darker the gray value, the lower in height the vertex
(256 unique height values corresponding to 256 pixel colors). GenSurf then uses
the vertexes to define the extents of triangles and suddenly, one has a terrain
surface. Of course, there are a few details of construction between start and
finish …</p>
</font>
<p align="center"><a href="terrain_entity.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="height_maps.html">Height Maps</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</font>
<p align="center">&nbsp;</p>
<p align="center">&nbsp;</p>
<p align="center">-7-</p>
</body>
</html>

102
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/entity_keys_and_values.html Normal file
View file

@ -0,0 +1,102 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Entity Keys and Values</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Entity Keys and Values</font></p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Once you’ve created the func_group that will become the terrain entity, you
need to add the various keys and key values that make it a terrain entity.</p>
<b>
<p><font color="#000000">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<span style="background-color: #FF0000">
A word to the wise:</span></font></b> <font color="#000000"><span style="background-color: #FFFF00"> WRITE YOUR KEYS AND VALUES ON SOMETHING YOU CAN
EASILY REFER TO DURING DEVELOPMENT!!</span></font> During the creation, testing and tweaking
of the heightmap, you will have to reenter these key/value pairs for the terrain
entity every time you recreate it. One thing that can make things easier is
before replacing the terrain entity with a new mesh, open the entity window and
click on the most complicated of the key/value pairs (usually the alphamap).
When the new terrain func_group is in place, click on the value line and hit
return. That’s one less thing to retype.</p>
</font><b><font SIZE="4">
<p>Key: Alphamap</p>
</font><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Value:</font></b><font FACE="Times New Roman"> The value should be the
pathname to the art file use to assign textures to the terrain. Example:
maps/alpha/pj_terra1.bmp. The pathname begins in the game (baseq3 or missionpack)
directory, which includes the name of the art file.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The q3map compiler applies and blends the textures
(shaders) on the terrain
entity using a “metashader” (see Texturing the Terrain below) that
references the art file named by the alphamap value. See the Creating the
Alphamap section below for details.</p>
</font><b><font SIZE="4">
<p>Key: Layers</p>
</font><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Value:</font></b><font FACE="Times New Roman"> A positive integer, equal to
the number of unique or root textures to be blended on the map. Each color on
the alphamap’s palette corresponds to a “layer.” If you plan to blend 4
textures, you need a layer value of 4.</p>
</font><b><font SIZE="4">
<p>Key: Shader</p>
</font><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Value:</font></b><font FACE="Times New Roman"> A pathname, beginning in the
missionpack/scripts directory, which includes the name of the filename and the
name of the metashader. Example: The shader value for mpterra2 is “terrain/mpterra2”.
“terrain” is the name of the script and mpterra2 is the name of the
metashader used to apply texture to this terrain.</p>
</font><b><font SIZE="4">
<p>Key: Terrain</p>
</font><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Value:</font></b><font FACE="Times New Roman"> Set this to 1 to indicate that
the func_group is a terrain entity. It’s essentially a yes/no flag.</p>
</font><b><font SIZE="4">
<p>Key: Min</p>
</font><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Value:</font></b><font FACE="Times New Roman"> Map coordinates of the minimum
XY extents (lowest left extent) of a component piece of a multi-part terrain
entity. This is optional, only used if you are texturing a subset of the total
terrain area.</p>
<p>The Min and Max extents (both must be in the entity) establish where a
subsection of terrain fits into the overall terrain map. It lets q3map assign a
subset of the alphamap to the entity, instead of referencing the entire alphamap.
It could also be used on a separate terrain entity to use the same alphamap, but
reference a different shader.</p>
</font><b><font SIZE="4">
<p>Key: Max</p>
</font><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Value:</font></b><font FACE="Times New Roman"> Map coordinates of the maximum
XY extents (uppermost right extent) of a component piece of a multi-part terrain
entity. This is optional, only used if you are texturing a subset of the total
terrain area.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The Min and Max extents (both must be in the entity) establish where a
subsection of terrain fits into the overall terrain map. It lets q3map assign a
subset of the alphamap to the entity, instead of referencing the entire alphamap.
It could also be used on a separate terrain entity to use the same alphamap, but
reference a different shader.</p>
</font>
<p align="center"><a href="boxing_in_the_world.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="creating_the_alphamap.html">Creating the Alphamap</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</b>
<p align="center">&nbsp;</p>
<p align="center">&nbsp;</p>
<p align="center">-15-</p>
</body>
</html>

52
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/glossary.html Normal file
View file

@ -0,0 +1,52 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Glossary</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b><font SIZE="5">
<p align="center">Glossary</p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%">
<b><font FACE="Times New Roman">
<p>Root Shader</font></b><font FACE="Times New Roman">: a shader that is part of
a family of related shaders used to texture a terrain entity. It represents a
terrain texture in its unblended state. The naming convention for a root shader
is &lt;metashadername&gt;_#.</p>
<b>
<p>Blend Shader</b>: a shader that is part of a family of related shaders used
to texture a terrain entity. It represents a terrain texture in its blended
state, two textures that crossfade across each other. The naming convention for
a blend shader is &lt;metashadername&gt;_#to#.</p>
<b>
<p>Metashader:</b> the identifying name of a group of related shaders used to
texture a terrain entity. By way of example, the metashader name used to texture
mpterra2 was … mpterra2. Its root shaders had names like mpterra2_0,
mpterra2_1, and mpterra2_2. Its blend shaders were named mpterra2_0to1,
mpterra2_1to2, and mpterra2_0to2.</p>
</font>
<p align="center"><a href="adding_bots.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="new_or_revised_q3map_shader_comm.html">Q3Map Shader
Commands</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</font></b>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p align="center">-26-</p>
</body>
</html>

41
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/height_map_into_terrain_mesh.html Normal file
View file

@ -0,0 +1,41 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Height Map into Terrain Mesh</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Height Map into Terrain Mesh</font></p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is not intended to be a tutorial on using GenSurf, but it will include
some pointers on getting the most out of the tool. You can download the
standalone tool and find tutorials for GenSurf at this <a href="http://tarot.telefragged.com/gensurf/" target="_blank">site</a></p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This <a href="http://tarot.telefragged.com/gensurf/appendix.htm#problems" target="_blank">page</a>, in particular, contains tips for using GenSurf, most of which to
apply to Q3A terrain creation.&nbsp;</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When starting the GenSurf plug-in: You will probably want to “<i>Select Ground
Surface</i>” as the option for making your terrain surface.</p>
</font>
<p align="center"><a href="other_possible_height_map_tools.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="suggested_gensurf_settings.html">Gensurf Settings</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</b>
<p align="center">&nbsp;</p>
<p align="center">&nbsp;</p>
<p align="center">-10-</p>
</body>
</html>

174
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/height_maps.html Normal file
View file

@ -0,0 +1,174 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Height Maps</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Height Maps</font></p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The terrain maps in Quake III: Team Arena began as grayscale bitmap art files
imported into David Hyde’s “<i>GenSurf</i>” tool, a Q3Radiant plug-in. As
mentioned before, the height map is a template that the utility uses to define
the vertex heights of the triangles forming the terrain surface. We used <i> Adobe
Photoshop</i> and <i> JASC’s Paint Shop Pro</i> to create and adjust our height maps …
but any art program that can output a .bmp format file can be used to create the
height map.</p>
</font><font FACE="Times New Roman" SIZE="2">
<p><img SRC="Image3.gif" WIDTH="264" HEIGHT="350" align="left"></p>
</font><font FACE="Times New Roman">
<p>figure 1.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; By way of example, the piece of artwork in figure 1 is a greatly scaled up
(4X) version of the height map used to create the initial terrain geometry for
mpterra2. The very dark, horizontal area near the center is the big “lake”
near the center of the map. The dark curves to the upper right and lower left
are the “fjord” water areas. The dark areas in the upper left and lower
right are the locations of the bases. The white and very light gray areas
represent the peaks of hills and mountains.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The key to understanding how the height map works is that the shades of gray
in the art (call them “color values”) represent the height of mesh vertexes
(triangle corners) and not the triangle quads (squares created by two
triangles). When you work on a piece of art where each individual pixel
corresponds to a vertex, it is easy to imagine the pixels (usually large square
blocks) as squares of terrain. But that’s not how it works.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Start by giving some thought to the eventual size and proportions of the
final terrain area in your map. How many rows and columns of triangles do you
want in the map? The finer you subdivide the map (making more rows and columns),
the more triangles will appear in any given view, but the terrain can be made
less blocky by including more.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GenSurf can generate a terrain mesh of up to 64 triangles on a side (of the X
and Y dimensions of the entire mesh). If you don’t decimate the GenSurf output
(an option that optimizes and reduces the number of triangles used to create the
mesh … and we really recommend that you don’t), it generates a mesh of
triangles in arranged in quads in neat rows and columns. By way of reference,
mpterra2 (the largest Team Arena map) is “only” 48x64 columns and rows of
triangles. Since Q3Radiant and q3map tend to like things that end up in neat
powers of 2 or units of 64 subdivisions, consider having your map extents (lower
left and upper right map corners) fall onto neat units, power of 2 units. In
mpterra2, the extents were set up to make the mesh triangles have sides of 256
units.</p>
</font><font FACE="Times New Roman" SIZE="2">
<p><img SRC="Image4.gif" WIDTH="103" HEIGHT="99" align="left"></p>
</font><font FACE="Times New Roman">
<p>Figure 2.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Figure 2 shows an example of a top view of a terrain mesh that is 8 x 8 rows
and colums of triangles (on a side).</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Just as you would plan out a game map, give thought to the layout and flow of
your terrain map. Will it be all-open in one view? Can you use natural terrain
features to block vis? How complicated will your buildings (if any) be? Do you
want to include trees, water, weather effects or other items that could add to
the visual cost of your map?</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Begin the creation of your height map by making a new grayscale file. If your
program doesn’t allow you to easily modify a .bmp format file, work in another
format and then convert it when you save. You can make the dimensions of your
height map art whatever you want. The extents you set in GenSurf for the map
dimensions are what determine the final size of the terrain piece. Some may find
it easier to work with a large file initially, using their favorite painting
tools to lay in the shades of gray.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; However, when you get down to making final and precise changes in your height
map you should (and this is STRONGLY recommended), change the size of the art
file such that the pixel dimensions of the map are 1 pixel larger than the
number of divisions (rows and columns) in the terrain mesh you want to create.
If you are making a 64 x 64 division map, then you want to create a 65 x 65
pixel height map.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If there is not a one-to-one match between the number of vertexes in the mesh
(one more than the number of divisions) and the number of pixels in the height
map, then GenSurf interpolates the number values (0 to 255 range) of the pixels
to get an averaged value instead of an exact value for the height of the vertex
at that point.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; When you save out the height map art file, you must save it in 8-bit .BMP
format. Currently, this is the only the file format that GenSurf recognizes.</p>
<b>
<p>Tips and things to consider for making Height Maps</p>
<blockquote>
<blockquote>
</b></font><font FACE="Symbol">
<p>· </font><font FACE="Times New Roman">Read through the section on blocking
vis later in the document. Plan your vis blocking terrain structures in advance
instead of having to start over when you discover that too much of your world is
in view.</p>
</font><font FACE="Symbol">
<p>· </font><font FACE="Times New Roman">Consider what type of geometry will
form the edges of your map. The terrain maps in Q3:TA resolve the issue by
creating canyon-like settings … valleys bordered by high canyon or mountain
walls.</p>
</font><font FACE="Symbol">
<p>· </font><font FACE="Times New Roman">Start by filling your map with a
neutral gray (value 127 or 128). Paint the high areas lighter and the low areas
darker.</p>
</font><font FACE="Symbol">
<p>· </font><font FACE="Times New Roman">Keep your terrain shapes simple when
you start. You can add greater complexity as your map develops.</p>
</font><font FACE="Symbol">
<p>· </font><font FACE="Times New Roman">You will probably want to keep the “playable”
area of your map within a fairly close or “narrow” range of gray values
close to the middle range of values. This allows you to use very dark shades of
gray to create deep chasms and very light shades of gray to create high
mountains, canyon walls or visual barriers.</p>
</font><font FACE="Symbol">
<p>· </font><font FACE="Times New Roman">Extreme jumps between the gray values
in adjacent areas means steep slopes.</p>
</font><font FACE="Symbol">
<p>· </font><font FACE="Times New Roman">Avoid making vertical or near vertical
terrain surfaces … unless you don’t mind the resulting textured surface
looking like barcode. Q3Map planar projects the textures onto the terrain entity’s
surface (Normal brushes are box mapped). The pixels will stretch and stretch to
fill the space. The farther the surface is from horizontal, the greater the
stretching.</p>
</font><font FACE="Symbol">
<p>· </font><font FACE="Times New Roman">Use the roughness feature of GenSurf
to add a little, um … roughness to your map … so flat areas aren’t
completely flat. If you are using a 1 to 1 scale height map, adding “noise”
to the file will also accomplish this.</p>
</font><font FACE="Symbol">
<p>· </font><font FACE="Times New Roman">If you want an area, such as a path,
to be flat, you need to make the gray value affecting two adjacent vertexes the
same value.</p>
</font><font FACE="Symbol">
<p>· </font><font FACE="Times New Roman">You can create gentle slopes by
changing the gray values between adjacent areas by very small amounts.</p>
</font><font FACE="Symbol">
<p>· </font><font FACE="Times New Roman">Slopes greater than 45 degrees are
close to becoming unplayable barriers.</p>
<p>&nbsp;</p>
</blockquote>
</blockquote>
<p>If you are building a symmetrical team style map, only create one side of the
terrain. Create a new piece of art that has the dimensions of the final piece.
Paste the map half into the new file and move it into position. If the map will
have an even number of vertexes, paste the map again and then rotate or mirror
(as you choose) the selection and move it into position. If the number of
vertexes is odd, after you paste the first half of the map, select all but the
row or column of pixels along which the two halves of the map will face and copy
it. Paste it, rotate or mirror it, then position it. Now, select and copy half
the row or column of pixels you didn’t copy in the last operation. Paste it,
transform it as you did in the last operation, and then position it so that it
is in the same row or column, but on the opposite side of the piece you copied.</p>
<p>When you make significant changes to a height map, consider saving it as
version rather than over-writing the older file. Always nice to have a back up
when you realize that you’ve messed up more than you’ve fixed.</p>
</font>
<p align="center"><a href="creating_the_terrain.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="other_possible_height_map_tools.html">Other Height
Map Tools</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</b>
<p align="center">&nbsp;</p>
<p align="center">-8-</p>
</body>
</html>

49
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/introduction.html Normal file
View file

@ -0,0 +1,49 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Introduction</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b><font SIZE="5">
<p align="center">Introduction</p>
</font></b><font FACE="Times New Roman">
<div align="right">
<table border="1" cellpadding="10" width="100%" bgcolor="#000000" bordercolor="#808080" cellspacing="1">
<tr>
<td width="100%" bordercolor="#000000"><font FACE="Times New Roman">
<p><font color="#FFFFFF">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; <font size="3">Creating workable terrain style maps for the Q3A engine takes some
reorganizing of thought, but in many ways is not substantially different from
making a halls-and-rooms type of map. The designer still has to be concerned
about how much can be seen at one time and give thought to map flow and play.
The rules and restrictions that guide conventional map design are still there
… it just occurs on a much grander scale. You still have to think about poly
counts, that hasn’t changed; but generally speaking, the polys that you will
use to make your game terrain are VERY large and less are likely to be seen all
at once during a game.</font></font></p>
<p><font face="Times New Roman" size="3" color="#FFFFFF">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
The “<i>terrain</i>” style maps in Quake III: Team Arena do not represent any
changes to the Quake 3 Engine. The power to make them work has always been there,
unrealized and untapped. What has changed is the way map files are created and
processed. These construction techniques rely on changes in the <a href="http://www.qeradiant.com/" target="_blank"> Q3Radiant editor</a>
and the q3map program that processes the map files into game files.</font></p>
</font>
<p align="center"><a href="table_of_contents.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="key_changes.html"> Key Changes</a></p>
</td>
</tr>
</table>
</div>
</font>
<p align="center">&nbsp;</p>
<p align="center">&nbsp;</p>
<p align="center">-3-</p>
</body>
</html>

64
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/key_changes.html Normal file
View file

@ -0,0 +1,64 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Key changes that have been made include</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Key changes that have been made include:</font></p>
<font SIZE="4">
<div align="right">
<table border="1" cellspacing="1" width="100%" bgcolor="#000000" bordercolor="#808080">
<tr>
<td width="100%"><font FACE="Times New Roman">
<blockquote>
<p>&nbsp;</p>
<blockquote>
</font><font FACE="Symbol">
<p>· </font><font FACE="Times New Roman">A variant of the func_group entity
has been added to the game. When a func_group of brushes (only) is given a
terrain key and a numerical value (an ID number for that terrain) and several
other key attributes, it becomes a terrain entity and is treated differently
than other brushes during the compile.</p>
</font><font FACE="Symbol">
<p>· </font><font FACE="Times New Roman">The map area has been expanded to
128,000 units in all extents (256,000 units on any edge of the map volume).
While this does not mean that a map that large could actually run on current
game hardware, it does give the designer room to explore what the actual
limits may be. As a point of reference, mpterra2.bsp is roughly 12K x 16K x 3K
units in size … the largest map in the game by far.</p>
</font><font FACE="Symbol">
<p>· </font><font FACE="Times New Roman">A terrain texture mapping system
plots textures across the terrain entity using a specially created .pcx or .tga
art file as a map for planar projecting and blending shaders on terrain
surfaces.</p>
</font><font FACE="Symbol">
<p>· </font><font FACE="Times New Roman">A “meta-shader” is used to
organize and calculate blends between the shaders that are mapped onto the
terrain.</p>
</font><font FACE="Symbol">
<p>· </font><font FACE="Times New Roman">Textures designed for use under
vertex lighting can be substituted at map load time for more complex shader-manipulated
textures that may not look correct in a vertex light only situation.</p>
</blockquote>
</blockquote>
</font>
<p align="center"><a href="introduction.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="art_tools.html"> Art Tools</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</font></b>
<p align="center">&nbsp;</p>
<p align="center">-4-</p>
</body>
</html>

135
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/lighting_the_terrain.html Normal file
View file

@ -0,0 +1,135 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Lighting the Terrain</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b><font SIZE="5">
<p align="center">Lighting the Terrain</p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Terrain maps also require some rethinking about the way you light maps.</p>
</font><b><i><font SIZE="4">
<p>Vertex Only</p>
</font></i></b><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If you are making a large terrain map, you should plan on making your terrain
textures be lit by vertex lighting only. Lightmaps can quickly become far too
large for the game to handle.</p>
<p>Make sure your large terrain textures contain the following parameters:</p>
<b>
<p>Surfaceparm nolightmap</b> //signifies vertex lighting only.</p>
<b>
<p>Q3map_novertexshadows</b> //this is what keeps those caulk vis blockers from
causing ugly shadows to form on your terrain.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; If you are using q3map_sun in your sky …</p>
<b>
<p>Q3map_forcesunlight</b> //this makes the light emitted by a q3map_sun
parameter affect the vertex lit surface.</p>
</font><b><i><font SIZE="4">
<p>Light Sources</p>
</font></i></b><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For outdoor maps, the obvious source of lighting ought to be the sky. The
skies in the mpterra maps began with skies used in more conventional Team Arena
maps, but were modified to better suit the needs of the terrain worlds.</p>
<blockquote>
<blockquote>
</font><font FACE="Symbol" SIZE="2">
<p>· </font><b><font FACE="Times New Roman">Slow Down Those Clouds.</font></b><font FACE="Times New Roman">
One thing to consider is slowing down the rate of cloud movement. What looks
OK in smaller maps looks wrong in vast panoramas.</p>
</font><b><font FACE="Symbol" SIZE="2">
<p>· </font><font FACE="Times New Roman" color="#FFFFFF">Strong Sunlight is
Good.</font></b><font FACE="Times New Roman" color="#FFFFFF"> For team maps,
you want to try and keep the light relatively the same in both base areas, so
if you have mountains or large base structures, having the light come in at a
nearly vertical angle is good, but less dramatic.
</font></p>
<b><font FACE="Symbol" SIZE="2">
<p><font color="#FFFFFF">· </font> </font><font FACE="Times New Roman">Ambient Light is Not
So Bad.</font></b><font FACE="Times New Roman" color="#FFFFFF"> Since the
beginning of Q3A map development we’ve said things like “Ambient Lighting
is bad”. Well, the problems caused by ambient lighting are still there
(flattening of shadows and colors), but with the distance of the play areas
from the sky surface (in some maps), adding an ambient really helps bring up
the overall light value in the map. Start low, maybe around an ambient value
of 5 and creep upwards until the map looks right. It is VERY IMPORTANT that
you give your ambient light a color. If you leave it white, you get ugly pink
light instead of white. Even specifying white makes it look wrong. Best
suggestion is to sample the sky texture color and translate that into an rgb
formula for your ambient. One warning
though … if you include “interior spaces” in your maps, the ambient
light will affect those areas too. You will not get the deep dark shadows you
may want in there.
</font></p>
<font FACE="Symbol" SIZE="2">
<p><font color="#FFFFFF">· </font> </font><font color="#FFFFFF"><b><font FACE="Times New Roman">Sky Shader Trick #1: Lose the
Backsplash</font></b></font><font FACE="Times New Roman"><font color="#FFFFFF">. The attributes of the sky
shader can have a significan</font>t effect on the amount of time it takes to perform
a light compile on a map. You have to think of the sky as a huge area light.
However, unlike light emitting textures (like your average light fixture), the
sky doesn’t need to be illuminated itself. Therefore, you can eliminate the
backsplash light feature which is the default status of the q3map_surfacelight
parameter. Your sky shader should have the parameter q3map_backsplash with a
value of -1. Removing backsplash light doesn’t affect the appearance of the
sky, but does remove a significant amount of compiling overhead when the
-light algorithm is used (the normal way you light things).</p>
</font><font FACE="Symbol" SIZE="2">
<p>· </font><b><font FACE="Times New Roman">Sky Shader Trick#2: Big
Subdivisions.</font></b><font FACE="Times New Roman"> Q3Map automatically
subdivides the sky into triangle quads. The more triangle quads, the more
light emitting surfaces you have on your sky (if q3map_surfacelight is used).
The light compile calculates for every one of these light emitting surfaces.
Increase the size of the subdivision and you get less light emitters and a
faster compile.</p>
</font><font FACE="Symbol" SIZE="2">
<p>· </font><b><font FACE="Times New Roman">Sky Shader Trick #3: -V-light.</font></b><font FACE="Times New Roman">
This is a fast lighting algorithm. It’s especially fast for calculating sky
lighting. It loses a little precision, but it can greatly speed up the time it
takes to light a map. Even if you decide to use a normal light operation for
your final map, using -vlight for interim compiles can mean a lot less time
spent waiting on the compiler to see your results.</p>
<b>
<p>&nbsp;</p>
</blockquote>
</blockquote>
</b></font><b><i><font SIZE="4">
<p>The Light Grid</p>
</font></i></b><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This is discussed in detail under terrain-related Worldspawn features. One of
the things that can add enough memory complexity to a large terrain map, enough
to make it unplayable (read crash the game), is the light grid. Think of the
light grid as a map for determining how to light entities in the world. It’s
what makes player models appear to move in and out of shadows as they move
through the world. It’s a nice effect, but costly in memory terms. For the
largest maps in Q3:TA, we “traded down” to a less detailed light grid.
Increasing the size of grid subdivisions from 32 units to 256 units did this. We
experimented with smaller and larger grids and settled on 256 x 256 x 256 as the
best size. Smaller and the grid became large and unwieldy. Larger (especially on
the z dimension) and not enough light reached some of the entities.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The details of this feature are noted below under Terrain-Related WorldSpawn
Features.</p>
</font>
<p align="center"><a href="the_meta_shader.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="terrain_related_worldspawn_features.html">Terrain
Worldspawn Features</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</font></b>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p align="center">-22-</p>
</body>
</html>

42
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/manipulating_the_terrain_mesh.html Normal file
View file

@ -0,0 +1,42 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Manipulating the Terrain Mesh</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Manipulating the Terrain Mesh</font></p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Once the terrain mesh has been generated, it’s very likely that you will
want to fine-tune the triangles inside the editor. Do this by pulling vertexes
up and down along the Z axis. Once you start fine-tuning in this manner, the
height map no longer exactly represents the map.</p>
<b>
<p align="center"><font color="#000000"><span style="background-color: #FF0000">WARNING:</span></font></b> <font color="#000000"><span style="background-color: #FFFF00"> If you revise and convert the height map, your manipulations
here are lost.</span></font></p>
</font>
<p align="center"><a href="suggested_gensurf_settings.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="terrain_mesh_into_terrain_entity.html">Terrain Mesh
into Terrain Entity</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</b>
<p align="center">&nbsp;</p>
<p align="center">&nbsp;</p>
<p align="center">-12-</p>
</body>
</html>

71
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/mapping_the_textures.html Normal file
View file

@ -0,0 +1,71 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Mapping the Textures</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b><font SIZE="5">
<p align="center">Mapping the Textures</p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The key to making this stuff look good is the q3map routine that works with
alphamap and the metashader (see below) to smoothly blends textures across the
terrain entity.</p>
</font><b><i><font SIZE="4">
<p>Texturing Overview</p>
</font></i></b><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; As noted earlier, Q3Map assigns textures, or more correctly, shader
manipulated textures, to each triangle used to create the terrain map. The
shaders used are part of a group of shaders called a metashader. The metashader
is the family name for the shader. Individidual shaders within it are identified
by a suffix, either an underline character followed by a number, or an underline
character followed by a string indicating a blend between two other shaders.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Within the body of the metashader, there are two types of shaders used. The
first, is the <b>root</b> shader. A root shader represents a terrain texture in
its unblended state. The naming convention for a root shader is &lt;metashader&gt;_#.
The second type is the <b>blended</b> shader. The blended shader creates a
crossfade between two root shaders across the face of a single geometry
triangle. The naming convention for a blended shader is &lt;metashader&gt;_#to#.
The map maker does not need to make a blend between each root shader, but for a
blend to occur, there must be a blend shader for the two root shaders.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Q3map will map a shader (root or blended) once and only once across the face
of the triangle. The shaders will not tile or repeat across the triangle face.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; As noted earlier, the textures are planar mapped or projected on the surface
of terrain texture. The angle of any individual triangle does not affect the
angle or direction at which the texture lies on the brush surface. The angle,
however, does affect the apparent stretching of the texture on the surface. The
steeper the angle of the brush surface, the greater will be the stretch of the
shader on that surface.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Q3map looks at the pixel on the alphamap that corresponds to a given vertex.
It uses the color of that pixel (or more correctly the identification number of
the position that color occupies in the palette) to determine which root shader
will be applied. That root shader is applied to triangles that have one vertex
located at the given vertex. It then examines the alphamap color of the vertexes
adjacent to the given vertex. If an adjacent vertex has the same color as the
given vertex, the root shader is applied to the surface. If an adjacent vertex
has a different alphamap color, the blended shader that crossfades between the
two.</p>
</font>
<p align="center"><a href="clipping_the_terrain.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="the_meta_shader.html">The Meta-Shader</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</font></b>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p align="center">-20-</p>
</body>
</html>

361
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/new_or_revised_q3map_shader_comm.html Normal file
View file

@ -0,0 +1,361 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>New or Revised Q3map Shader Commands</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b><font FACE="Arial" SIZE="5">
<p align="center">New or Revised Q3map Shader Commands</p>
</font>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%">
<p><font size="3">q3map command line switches:</font></p>
<pre>
q3map
-----
-threads <number>
Number of threads used to compile the map. For the fastest compile
times the number of threads is set to the number of system processors.
-glview
Write a .gl file of the bsp tree for debugging.
-v
Output verbose information.
-draw
Enable realtime debug drawing output.
-nowater
Water, slime and lava brushes are not compiled and won't show up when running the map in Quake.
-noopt
unused.
-nofill
unused.
-nodetail
Detail brushes are not compiled and won't show up when running the map in Quake.
-fulldetail
Detail brushes will be treated as normal brushes.
-onlyents
Only change the entities in a .bsp using a .ent file.
-onlytextures
Only change the textures in a .bsp file.
-micro
unused.
-nofog
Visible surfaces that cross fog boundaries will not be split along the bound.
This can cause visually incorrect fog in the map.
-nosubdivide
Visible surfaces are not subdivided as required by shader tesselation.
The shader parameter "tesssize" sets the tesselation of a surface.
-leaktest
Only test the map for leaks. If a leak is found the compilation is stopped.
-verboseentities
Output verbose information about entity sub-models.
-nocurves
Curves are not compiled and won't show up when running the map in Quake.
-notjunc
T-junctions are not fixed. This can cause tiny slits where a surface meets halfway another surface.
-expand
Expands all the brush planes and saves a new map out to allow visual inspection of the clipping bevels
-tmpout
Output files to a folder called "tmp".
-fakemap
Write out a fakemap.map This map will contain a worldspawn entity with all the world brushes.
-samplesize <N>
Set the lightmap pixel size to NxN units. Default 16x16.
-custinfoparms
Will enable custom surface flags (see below)
q3map -vis
----------
-threads <number>
Number of threads used to compile the map. For the fastest compile
times the number of threads is set to the number of system processors.
-fast
Only calculate a very loose visiblity list. It doesn't take much time to
calculate but a lot more polygons will be drawn by the Q3 engine than necesary.
-merge
Merge bsp leaves before calculating the visibility list. This will speed up
the vis calculations but mostly more polygons will be drawn by the Q3 engine
than necesary.
-nopassage
Disable the passage visibility algorithm. The passage vis is faster and a bit more
tight than the old algorithm.
-level
unused.
-v
Output verbose information.
-nosort
Don't sort the portals on complexity. Sorting mostly speeds up visibility calculations
because more complex portals can use information from less complex portals.
-saveprt
Don't delete the .prt file after creating the visibility list.
-tmpin <path>
Input files will be read from a folder called "tmp".
-tmpout <path>
Output files will be written to a folder called "tmp".
q3map -light
------------
-threads <number>
Number of threads used to compile the map. For the fastest compile
times the number of threads is set to the number of system processors.
-area <scale>
This scales the light intensity of area lights.
-point <scale>
This scales the light intensity of point lights.
-notrace
No light tracing is performed. As a result no shadows will be casted.
-patchshadows
Enable patches casting shadows.
-novertex
Don't calculate vertex lighting.
-nogrid
Don't calculate light grid for dynamic model lighting.
-extra
Take four samples per lightmap pixel and store the average light value of these
four samples for the actual lightmap pixel.
This super sampling is used for anti-aliasing.
-extrawide
Just like -extra four samples per lightmap pixel are calculated. However the
average of 12 samples is stored per lightmap pixel.
-samplesize <N>
Set the lightmap pixel size to NxN units. Default 16x16.
-border
Create a debugging border around the lightmap.
-v
Output verbose information.
-nosurf
unused.
-dump
unused.
q3map -vlight
-------------
-threads <number>
Number of threads used to compile the map. For the fastest compile
times the number of threads is set to the number of system processors.
-area <scale>
This scales the light intensity of area lights.
-point <scale>
This scales the light intensity of point lights.
-novertex
Don't calculate vertex lighting.
-nogrid
Don't calculate light grid for dynamic model lighting.
-nostitching
No polygon stitching before lighting.
-noalphashading
Don't use alpha shading at all.
-nocolorshading
Don't use colored alpha shading. The alpha channel will be used as if it were binary.
The light goes through or not and does not change color.
-tracelight
Use the "-light" light algorithm for all surface unless a surface
uses a shader with the shader option "q3map_vlight".
-samplesize <N>
Set the lightmap pixel size to NxN units. Default 16x16.
-v
Output verbose information.
</pre>
<p><font size="3">The q3map options are a subset of the shader instructions that require
recompiling of the map.</font></p>
<p><font size="3">q3map_tracelight</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>] Surfaces using a shader with this option will always be lit with the
original &quot;-light&quot; light algorithm. Patches will not cast shadows on
this surface unless the shader option q3map_patchshadows is used.</font></p>
<p><font size="3">q3map_patchshadows</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>] When this option is used in conjunction with the original (-light)
lighting algorithm, surfaces with textures modified by this option will will
show shadows cast by curve patches (under normal circumstances, curve patches do
not cast shadows).</font></p>
<p><font size="3">q3map_vertexshadows</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>] By default, no shadows are cast on vertex-only lit surfaces (see
surfaceparm pointlight). Also when running Quake III Arena in vertex&nbsp; lighting
mode, no shadows are cast upon any surfaces (shadows are part of the light map).
When using this shader option shadows *will* be cast on the surface when vertex
lit. However sharp shadow edges won't be seen on the surface because light
values are only calculated at the vertexes.</font></p>
<p><font size="3">q3map_novertexshadows</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>] Shaders used for misc_models and terrain can now use
q3map_novertexshadows to disable shadows to be cast at the vertex lit surfaces.
Shadows being cast at small misc_model objects often makes sense. However
shadows on large vertex lit terrain surfaces often look bad. By default no
shadows are cast at forced vertex list surfaces ( shaders with &quot;pointlight&quot;
).</font></p>
<p><font color="#FFFFFF" size="3">q3map_forcesunlight</font></p>
<p><font color="#FFFFFF" size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [</font><font color="#FFFF00" size="3">NEW</font><font color="#FFFFFF" size="3">] No sunlight is cast at vertex lit md3 models and terrain by default.
Using this option sunlight (overbright bits created by q3map_sun option) will be
cast on these surfaces.</font></p>
<p><font size="3">q3map_vertexscale &lt;scale&gt;</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>] The light value at the vertexes of a surface using a shader with this
option is multiplied by the scale value. This is a way to lighten or darken a
vertex light only surface in comparison to other, light-map lit surfaces around
it.</font></p>
<p><font size="3">q3map_notjunc</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>] Surfaces modified by a shader with this option are not used for
tjunction fixing.</font></p>
<p><font size="3">q3map_vlight</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>] Surfaces modified by a shader with this option will always be lit with
the &quot;-vlight&quot; algorithm when q3map is used with the options &quot;-vlight
-tracelight&quot;.</font></p>
<p><font size="3">q3map_lightmapsamplesize &lt;S&gt;</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; [<font color="#FFFF00">NEW</font>] Surfaces using a shader with this shader option will use lightmaps with
pixel size SxS. This option can be used to produce high resolution shadows on
certain surfaces or can be used to reduce the size of lightmap data where high
resolution shadows are not required.</font></p>
<p><font size="3">q3map_lightimage &lt;image&gt;</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Image to use for the light color of a surface light instead of the image(s)
used by the shader. Color is averaged from the texture. Texture must be the same
size as the base image map.</font></p>
<p><font size="3">q3map_surfacelight &lt;value&gt;</font></p>
<p><font size="3">Sets the amount of light this surface emits.</font></p>
<p><font size="3">q3map_lightsubdivide &lt;value&gt;</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A surface light is subdivided into a bunch of point lights for the actual
lighting of the world. This parameter controls the space between those point
lights. Default value is 120.</font></p>
<p><font size="3">q3map_backsplash &lt;percent&gt; &lt;distance&gt;</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; A surface light is also lit by itself using back splash point lights with a
lower intensity. The &lt;percent&gt; parameter specifies the intensity
percentage they use from the q3map_surfacelight &lt;value&gt; parameter. The
&lt;distance&gt; parameter controls the distance of these back splash lights
from the surface. You can set the &lt;percent&gt; to zero or a negative value to
disable the back splash lights.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; q3map_globaltexture</font></p>
<p><font size="3">When this option is set the texture is not aligned to the world.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; q3map_backshader &lt;shader&gt;</font></p>
<p><font size="3">&lt;shader&gt; is the path/name of the shader or texture to be used at the
back side of the surface.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; q3map_flare &lt;shader&gt;</font></p>
<p><font size="3">Creates a flare using the specified &lt;shader&gt; at the center of the
surface using a shader with this option.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; light &lt;value&gt;</font></p>
<p><font size="3">Old style flare specification always using the shader &quot;flareshader&quot;.
The &lt;value&gt; parameter is unused.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; q3map_sun &lt;red&gt; &lt;green&gt; &lt;blue&gt; &lt;intensity&gt;
&lt;degrees&gt; &lt;elevation&gt;</font></p>
<p><font size="3">Color will be normalized, so it doesn't matter what range you use. The
intensity falls off with angle but not distance. A value of 100 is a fairly
bright sun.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; degree of 0 = from the east, 90 = north, etc.</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; elevation of 0 = sunrise/set, 90 = noon</font></p>
<p><font size="3">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; surfaceparm pointlight</font></p>
<p><font size="3">Surfaces using a shader with this parameter will always be vertex lit</font></p>
<p><font size="3">This option can be used to reduce the lightmap data. Often used on surfaces</font></p>
<p><font size="3">that don't need any shadows.</font></p>
<p><font size="3">Surfaceparm dust</font></p>
<p><font size="3">If a player lands (jumps onto) on a surfaces using a shader with this
parameter, a put of dust will appear at the player’s feet. Note that the
worldspawn entity of that map must have an enableDust key set to a value of 1.</font></p>
<font FACE="Arial" SIZE="5"><b><font SIZE="4">
<p>Custom surfaceparms</p>
</font></b><font SIZE="2">
<p>With the new q3map tool you can add custom surface parameters for mods
without the need to recompile the q3map tool. These custom surfaceparms are
stored in a file called ‘custinfoparms.txt’ in the folder scripts/. An
example of this file with the new surfaceparm treacle and surfaceparm grass is
shown below.</p>
<p>// Custom Infoparms File<br>
// Custom Contentsflags<br>
{<br>
treacle 0x4000<br>
}<br>
// Custom Surfaceflags<br>
{<br>
grass 0x80000<br>
}</p>
<p>&nbsp;</p>
<b>
<p>NOTE:</b> For linux users, when using the -custinfoparms parameter q3map
first looks in your homedir, and only if it doesn't find a custinfoparms.txt
there, it uses the one stored in the</p>
<p>quake3 install dir (usually /usr/local/games).</p>
<p>&nbsp;</p>
</font><b>
<p>Content Flags</p>
</b><font SIZE="2">
<p>Contents flags are flags similar to CONTENTS_FOG in the original Q3A. These
flags define the contents of volumes inside the game (for instance lava, fog,
water, etc.).</p>
<p>If you look in the source file game/surfaceflags.h, it has defines for all
contents flags. The define is split into a name and a hexadecimal value, for
instance CONTENTS_PLAYERCLIP 0x10000. These hexadecimal values are powers of 2
and can be ored together (binary) to form a bit mask. Up to 32 contents flags
can be ored together this way.</p>
<b>
<p>Example</b>: creating a volume with treacle.</p>
<p>The following outlines how a custom contents flag can be added and used in a
mod. First open the ‘custinfoparms.txt’ file and add ‘treacle 0x4000’
to the Custom Contentsflags section as shown in the example file above (0x4000
is one of the unused values available for custom use). Next write a shader
script which uses ‘surfaceparm treacle’. Apply this new shader to all sides
of a brush in a test map. When you compile the map, add the -custinfoparms
parameter to the command line following q3map.</p>
<p>Next, add CONTENTS_TREACLE 0x4000 to the source file game/surfaceflags.h in
your mod. Now you can call the point contents function. If the point is inside
the brush with the shader using the ‘surfaceparm treacle’ then the point
contents call will return a bit mask with CONTENTS_TREACLE set. This can for
instance be used to slow down player movement when a player is inside such a
brush.</p>
<p>&nbsp;</p>
</font><b>
<p>Surface Flags</p>
</b><font SIZE="2">
<p>The surface flags are texture properties that often affect entities in
contact with surfaces using such flags. The ‘surfaceparm metalsteps’
parameter from Q3A is a good example.</p>
<p>If you look in the source file game/surfaceflags.h, it has defines for all
surface flags. The define is split into a name and a hexadecimal value, for
instance SURF_NODAMAGE 0x1. These hexadecimal values are powers of 2 and can be
ored together (binary) to form a bit mask. Up to 32 surface flags can be ored
together this way.</p>
<b>
<p>Example</b>: Making ‘footsteps on grass’ sounds</p>
<p>The following outlines how a custom surface flag can be added and used in a
mod. First open up the ‘custinfoparms.txt’ file and add 'grass 0x80000' to
the Custom Surfaceflags section as shown in the example file above (0x80000 is
the first available unused value in surfaceflags.h for surface flags). Next
write a shader script which uses a grass image and has 'surfaceparm grass’.
Create a test map with the grass shader covering the ground surface. When you
compile the map, add the -custinfoparms parameter to the command line following
q3map.</p>
<p>Next, add SURF_GRASS 0x80000 to the source file game/surfaceflags.h in your
mod. Now you'll be able to execute a trace and the trace information will be
returned in the trace_t structure. If the trace hits a surface with the grass
surfaceparm then the SURF_GRASS flag will be set in trace_t-&gt;surfaceFlags.
Such a trace can be used to trigger playing a sound of a person stepping on
grass. For a reference example, see the existing metal steps in the game code.</p>
<p>&nbsp;</p>
</font>
<p>&nbsp;</p>
</font>
<p align="center"><font face="Arial" size="3"><a href="glossary.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="related_links.html"> Links</a></font></p>
<font FACE="Arial" SIZE="5">
<p>&nbsp;</font></td>
</tr>
</table>
</div>
</b>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p align="center">-27-</p>
</body>
</html>

62
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/other_possible_height_map_tools.html Normal file
View file

@ -0,0 +1,62 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Other Possible Height Map Tools</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Other Possible Height Map Tools</font></p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; There are even some editors for other (non-fps) games that can be used to
manipulate a surface in 3D and then output a .bmp format file. It is worth
noting that we found it particularly challenging to use them … possibly more
challenging than the benefits of working in 3D.</p>
<b>
<p>SC3K Map Editor</p>
</b>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The first of these programs was a terrain editor for SimCity3000 called the
SC3K Map Editor from Tenermerx. It is a free download available here: <a href="http://www.tenermerx.com/sc3maped/" target="_blank">sc3maped</a></p>
<b>
<p>Loathing</p>
</b>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The other editor we tried was the “Loathing” terrain editor that comes
with Bungie’s Myth II game. If you’ve a copy of Myth II, this is something
you could play around with. Both of these programs could output a .bmp format
file. If you’ve used it to make some Myth II maps you may have some idea of
how it works already. It is my opinion that if you use an editor for either of
these two games to create your height map, you may still want to or need to
manipulate it in an art program. If you can visualize the relationship between
shades of gray and relative heights and slopes, the art program is probably the
easier way to go.</p>
<b>
<p>Pencils, paintbrushes and a scanner</p>
</b>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; You can also make your heightmap by painting it by traditional methods and
then scanning in the file and saving it as a .bmp. Though at some point you’ll
probably want to switch over to digital manipulation.</p>
</font>
<p align="center">&nbsp;</p>
<p align="center"><a href="height_maps.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="height_map_into_terrain_mesh.html">Height Map into
Terrain</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</b>
<p align="center">&nbsp;</p>
<p align="center">-9-</p>
</body>
</html>

40
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/related_links.html Normal file
View file

@ -0,0 +1,40 @@
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Related Links</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<p align="center"><b><font size="5">Related Links</font></b></p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000">
<tr>
<td width="100%">
<p align="center"><font size="3"><a href="http://www.qeradiant.com/" target="_blank">Q3Radiant</a><br>
<a href="http://www.qeradiant.com/manual/" target="_blank">
Q3Radiant Manual</a><br>
<a href="http://tarot.telefragged.com/gensurf/" target="_blank">
Gensurf</a><br>
<a href="http://www.Quake3world.com" target="_blank">
Quake3World</a><br>
</font></p>
<p align="center"><a href="new_or_revised_q3map_shader_comm.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
<p align="center">&nbsp;</p>
<p align="center">&nbsp;</p>
<p align="center">-28-</p>
</body>
</html>

135
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/suggested_gensurf_settings.html Normal file
View file

@ -0,0 +1,135 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Suggested GenSurf settings</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Suggested GenSurf settings</font> (by Tab)</p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%">
<b>
<p>The General TAB:</p>
</b>
<blockquote>
<blockquote>
<font FACE="Symbol">
<p>· </font>Select Quake 3 Arena under Game.</p>
<font FACE="Symbol">
<p>· </font>Select From Bitmap under Waveform. Of course, you may want to
play around with some of the other wave forms. But bitmaps give you the
greatest degree of control.</p>
<font FACE="Symbol">
<p>· </font>Orientation: as appropriate</p>
<font FACE="Symbol">
<p>· </font>If you don’t want GenSurf to add any “noise” or
randomization to the height of the mesh, set the Roughness to zero. The
preview window gives you a good representation of what roughness does to
your surface. The random seed changes the distribution of the noise. Adjust
both fields accordingly.</p>
</blockquote>
</blockquote>
<b>
<p>The Extents TAB:</p>
<p>Extents:</b> The extents of a map are the points on a map that define its
lowermost t and leftmost corner and its uppermost and rightmost corner. They are
given in terms of&nbsp; X, Y coordinates.</p>
<blockquote>
<blockquote>
<font FACE="Symbol" SIZE="2">
<p>· </font>Under Extents, you should chose number values that are even
multiples of your number of Divisions so that the grid rectangles are all
the same size (this produces better texturing results). It also makes extra
work for the compiler. Furthermore, use the Extents to position the terrain
entity on the map (XY only). You will want to make sure that the terrain
locates exactly where you want it each time you revise it. Repositioning a
terrain file can be time consuming.</p>
<font FACE="Symbol" SIZE="2">
<p>· </font>Set your X and Y divisions to equal the number of rows and
columns of triangles you want. You may want to strongly consider playing
with the numbers so that your triangle sides end up be large powers of two
(64, 128, 256 units etc.).</p>
<font FACE="Symbol" SIZE="2">
<p>· </font>Do not check Use Bezier Patches.</p>
<font FACE="Symbol" SIZE="2">
<p>· </font>Do not Decimate (keep it set to 0%). The process that applies
textures to the surfaces and blends textures between vertexes works best if
the size of the triangles is consistent and constant.</p>
</blockquote>
</blockquote>
<b>
<p>The Bitmap TAB:</p>
<blockquote>
<blockquote>
</b><font FACE="Symbol" SIZE="2">
<p>· </font>Filename should point to the .bmp file you are using as a height
map. Reload will bring in any changes you have made to the art file without
having to restart the program.</p>
<font FACE="Symbol" SIZE="2">
<p>· </font>GenSurf assigns an integer value to each of 256 shades of gray.
The value is based on the position of the color in the palette. In a grayscale
palette, the values typically range from 0 (black) to 255 (white). Map Color 0
corresponds (usually) to the lowest point on the height map and Map Color 255
to the highest. If you set Map Color 0 to 0 and Map Color 255 to 2048, each
increase in color value adds 8 units to the height of the vertex. When you
increase the difference between to the two values, the height changes are
steeper. Decrease the difference and the height changes are more global. You
can control the “Z” location at which the terrain draws by adding any
extra height above (or below) zero to the height values for both numbers.</p>
</blockquote>
</blockquote>
<b>
<p>The Fix Points TAB:</p>
</b>
<p>The general recommendation for this TAB is to leave it alone. You should
either modify the height map or directly manipulate vertexes inside the
Q3Radiant editor.</p>
<b>
<p>Texture TAB:</p>
<blockquote>
<blockquote>
</b><font FACE="Symbol" SIZE="2">
<p>· </font>Set the main texture to common/terrain. The “Steep” angle is
irrelevant for terrain texture mapping.</p>
<font FACE="Symbol" SIZE="2">
<p>· </font>Make sure that the Use detail brushes setting is checked.</p>
</blockquote>
</blockquote>
<p>Once you’ve tweaked all your settings, do a Save as. If you make changes to
the settings, consider saving again as a new file. It’s nice to have a back up
if you screw things up.</p>
<b>
<p>GenSurf Tips</p>
<blockquote>
<blockquote>
</b><font FACE="Symbol" SIZE="2">
<p>· </font>Setting extents to correspond exactly with the desired map
location is important. You want to be able to drop revised terrain into a map
without a lot of repositioning.</p>
</blockquote>
</blockquote>
<p align="center"><a href="height_map_into_terrain_mesh.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="manipulating_the_terrain_mesh.html">Manipulating the
Terrain Mesh</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</b>
<p>&nbsp;</p>
<p align="center">-11-</p>
</body>
</html>

88
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/table_of_contents.html Normal file
View file

@ -0,0 +1,88 @@
<html>
<head>
<meta http-equiv="Content-Language" content="en-us">
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Table of Contents</title>
</head>
<body background="../pics/background.jpg" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF" text="#FFFFFF">
<p align="center"><b><font size="7">Table of Contents</font><font size="6"><br>
</font><font size="3">(HTML Conversion by AstroCreep)</font></b>
</p>
<div align="right">
<table border="0" cellpadding="0" cellspacing="0" width="100%">
<tr>
<td width="50%">
<p align="right"><font size="3"><a href="../start.html">Title Page</a>............1<br>
<a href="table_of_contents.html">Table of Contents</a>............2</font><font size="6"><b><br>
</b>
</font><font size="3"><a href="introduction.html">Introduction</a>
...........3<br>
<a href="key_changes.html">Key Changes that have been made</a>............4<a href="art_tools.html"><br>
Art Tools Required</a>............5<br>
<a href="terrain_entity.html">
The Terrain Entity</a>............6<br>
<a href="creating_the_terrain.html">
Creating the Terrain “Mesh”</a>............7<br>
<a href="height_maps.html">
Height Maps</a>............8<br>
<a href="other_possible_height_map_tools.html">
Other Possible Height Map Tools</a>............9<br>
<a href="height_map_into_terrain_mesh.html">
Height Map into Terrain Mesh</a>..........10<br>
<a href="suggested_gensurf_settings.html">
Suggested GenSurf settings (by Tab)</a>..........11<br>
<a href="manipulating_the_terrain_mesh.html">
Manipulating the Terrain Mesh</a>..........12<br>
<a href="terrain_mesh_into_terrain_entity.html">
Terrain Mesh into Terrain Entity</a>..........13<br>
<a href="boxing_in_the_world.html">
Boxing in the World</a>..........14<br>
<a href="entity_keys_and_values.html">
Entity Keys and Values</a>..........15<br>
<a href="creating_the_alphamap.html">
Creating the Alphamap</a>..........16<br>
<a href="terrain_texture.html">
The Terrain Texture</a>..........17<br>
<a href="blocking_vis.html">
Blocking Vis</a>..........18<br>
<a href="clipping_the_terrain.html">
Clipping the terrain</a>..........19<br>
<a href="mapping_the_textures.html">
Mapping the Textures</a>..........20<br>
<a href="the_meta_shader.html">
The Meta-Shader</a>..........21<br>
<a href="lighting_the_terrain.html">
Lighting the Terrain</a>..........22<br>
<a href="terrain_related_worldspawn_features.html">
Terrain Related Worldspawn Features</a>..........23<br>
<a href="adding_buildings_to_terrain.html">
Adding Buildings to Terrai</a></font><font size="3"><a href="adding_buildings_to_terrain.html">n</a>..........24<br>
<a href="adding_bots.html">
Adding Bots</a>..........25<br>
<a href="glossary.html">Glossary</a>..........26<br>
<a href="new_or_revised_q3map_shader_comm.html">
New or Revised Q3Map Shader Commands</a>..........27<br>
<br>
<a href="related_links.html">
Related Links</a>..........28</font></p>
</td>
<td width="50%">
<p align="center"><img border="0" src="../pics/terrain.jpg" width="272" height="544"></td>
</tr>
</table>
</div>
<p align="left">&nbsp;</p>
<p align="center"><font size="3"><b><a href="../start.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a>- <a href="introduction.html">Introduction</a> </b></font></p>
<p align="center"><font size="3"><b>-2-</b></font></p>
</body>
</html>

50
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/terrain_entity.html Normal file
View file

@ -0,0 +1,50 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>The Terrain Entity</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b><font SIZE="5">
<p align="center">The Terrain Entity</p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The process of building a piece of terrain focuses on a new thing called the
“<i>Terrain Entity</i>.” Technically speaking, the terrain in Team Arena is nothing
more than a func_group entity (brushes only) with a number of key/value pair
combinations that are unique to it. These key/value pairs define it as terrain (<i>terrain</i>), establish the piece of art that will be used to locate textures on it
the terrain (alphamap), define the group of shaders used to blend textures
across its surface (shader), and tell how many different unique shaders will be
used. The bsp-making utility, Q3Map compiles and textures the terrain entity
based on the parameters specified in those key/value pairs.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It is possible to have multiple terrain entities in a map (see Terrain
Entities below). Once you learn the method and the techniques, terrain is
relatively easy to create. One warning though … easy to create does not mean
easy to compile. Large maps take a much longer time to compile, and huge maps
are likely to take what seems like forever. However, there are some
construction, lighting, and shader options that can significantly cut down on
compile time - as will be noted later.</p>
</font>
<p align="center"><a href="art_tools.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="creating_the_terrain.html">Creating the terrain
&quot;Mesh&quot;</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</font></b>
<p align="center">&nbsp;</p>
<p align="center">&nbsp;</p>
<p align="center">-6-</p>
</body>
</html>

44
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/terrain_mesh_into_terrain_entity.html Normal file
View file

@ -0,0 +1,44 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Terrain Mesh into Terrain Entity</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">Terrain Mesh into Terrain Entity</font></p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; GenSurf outputs its terrain as a func_group entity. If you create a terrain
mesh by any other means, you need to group it as a func_group entity.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Make certain that all the non-visible surfaces of the func_group brushes are
textured with common/caulk.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Texture the visible surfaces with common/terrain or common/terrain2.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Select the func_group and turn it to detail content (CTRL M) or use the
Selection menu.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; It is possible to map terrain onto something that is not a “terrain”
mesh. Keep in mind that textures will be planar projected onto all surfaces in
the terrain entity and that brush vertexes will be used to determine where
blends start and end.</p>
</font>
<p align="center"><a href="manipulating_the_terrain_mesh.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="boxing_in_the_world.html">Boxing in the World</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</b>
<p>&nbsp;</p>
<p align="center">-13-</p>
</body>
</html>

222
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/terrain_related_worldspawn_features.html Normal file
View file

@ -0,0 +1,222 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Terrain</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b><font SIZE="5">
<p align="center">Terrain-related WorldSpawn Features</p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>A number of worldspawn key/value pairs were created to deal with issues
arising out of terrain creation.</p>
</font><b><i><font SIZE="4">
<p>Cold Breath and Hot Dust</p>
</font></i></b>
<p><font FACE="Times New Roman" color="#FFFFFF">
The following two features need not be directly related to terrain, although
they first appear in the Q3:TA maps. Each key/value pair needs to be the
worldspawn for that particular feature to work.</font></p>
<b>
<p><font FACE="Times New Roman" color="#FFFFFF">
Key/value pairs:</font></p>
<p><font FACE="Times New Roman" color="#FFFFFF">
Key:</font></b> <font FACE="Times New Roman" color="#FFFFFF">
enableBreath</font></p>
<b>
<p><font FACE="Times New Roman" color="#FFFFFF">
Value:</font></b> <font FACE="Times New Roman" color="#FFFFFF">
1</font></p>
<p><font FACE="Times New Roman" color="#FFFFFF">
When written into the worldspawn, this enables the appearance of “frosty
breath” in the air in front of players. The frosty break does not appear in a
player’s first person view, but will be seen in front of other players and in
3<sup>rd person view.</font></p>
<b>
<p><font FACE="Times New Roman" color="#FFFFFF">
Key/value pair:</font></p>
<p><font FACE="Times New Roman" color="#FFFFFF">
Key:</font></b> <font FACE="Times New Roman" color="#FFFFFF">
enableDust</font></p>
<b>
<p><font FACE="Times New Roman" color="#FFFFFF">
Value:</font></b> <font FACE="Times New Roman" color="#FFFFFF">
1</font></p>
<p><font color="#FFFFFF">
When written into the worldspawn, this enables the appearance of dust puffs
at the player’s feet when he lands on or run on a “dusty” surface. Adding
the surface parameter “surfaceparm dust” to the shader for that surface
creates a dusty surface. The common/terrain2 texture already contains the
enableDust parameter.</font></p>
</sup><sup><b><i><font SIZE="4">
<p>Texture Remapping: Shaders for vertex light mode in Q3A</p>
</font></i></b>
<p><font color="#FFFFFF">
One thing we quickly discovered when mapping the metatexture onto the terrain
world was that it didn’t work if a player chose to run in the game’s vertex
lighting only mode. That mode compresses shaders into a single pass. Usually,
the engine makes a reasonable choice for which pass is mapped, but with the
metashaders, that wasn’t the case. The solution: allow the mapper to choose a
substitute texture that only is used in the game’s vertex lighting mode.
</font></p>
<p><font color="#FFFFFF">
For each shader that will be remapped a key/value pair must be entered in the
map’s worldspawn.
</font></p>
<b>
<p><font color="#FFFFFF">
Key</font></b><font color="#FFFFFF">: vertexremapshader</font></p>
<b>
<p><font color="#FFFFFF">
Value:
</font></b> <font color="#FFFFFF">
normal_shader;vertexlighting_shader
</font></p>
<p><font color="#FFFFFF">
The normal_shader is the shader normally used on the terrain. The
vertexlighting_shader is the shader to be used when people run the map in Q3 in
vertex lit mode. The normal_shader and the vertexlighting_shader are seperated
by a semi-colon ;
</font></p>
<p><font color="#FFFFFF">
As many shaders can be remapped as needed by using the key. However, if more
than one shader is remapped in a map, each one must have a unique identifier …
either a number or a letter after the Key word, as shown by “vertexremapshaderX”,
where X is a number or any character set. Examples, vertexremapshader01,
vertexremapshader02, vertexremapshaderA, vertexremapshaderB,
vertexremapshadermpterra2_1, etc.
</font></p>
<p><font color="#FFFFFF">
In mpterra2, the key/value pair for one of the replaced shaders looked like
this:
</font></p>
<b>
<p><font color="#FFFFFF">
Key:
</font></b> <font FACE="Times New Roman" color="#FFFFFF">
vertexremapshader1
</font></p>
<b>
<p><font color="#FFFFFF">
Value:
</font></b> <font FACE="Times New Roman" color="#FFFFFF">
textures/terrain/mpterra2_0to1;textures/terrain/vxmpterra2
</font></p>
<p><font color="#FFFFFF">
Each of the three root shaders and the two blend shaders had to replaced in
this manner.
</font></p>
<p><font color="#FFFFFF">
The following is a sample of the shader used to replace ALL the terrain
shaders in mpterra2:
</font></p>
<font FACE="Courier New">
<p>// *************************************************</p>
<p>// *</p>
<p>// * Vertex Lighting Replacement Shaders</p>
<p>// *</p>
<p>// *************************************************</p>
<p>textures/terrain/vxmpterra2</p>
<p>{</p>
<p>surfaceparm nolightmap</p>
<p>q3map_novertexshadows</p>
<p>q3map_forcesunlight</p>
<p>{</p>
<p>map textures/stone/pjrock10b_2.tga</p>
<p>rgbGen vertex</p>
<p>tcmod scale 0.125 0.125</p>
<p>}</p>
<p>}</p>
</font>
<sup><font FACE="Times New Roman">
<b><i><font SIZE="4">
<p>GridSize</p>
</font></i></b>
</font>
</sup>
</sup>
</font>
<p><font color="#FFFFFF" size="4"><sup><sup>
The Light Grid Size (as noted earlier) is the map that the Q3A engine uses to
light entities. It’s what gives the illusion of players moving in and out of
shadowed areas on the game levels. We decided, that for large terrain maps, it
should not be as detailed (and therefore nowhere near as large) as we had done
for smaller, interior maps. After experimenting with placing controls for the
grid size on the bsp command line, we finally settled on putting the command
information in the map’s world spawn. In that way, the grid size could be
easily tailored to the individual map.</sup></sup></font></p>
<font FACE="Times New Roman">
<sup><font SIZE="5">
<sup>
<b>
<p><font FACE="Times New Roman" color="#FFFFFF">
Key/value pair:
</font></p>
<p><font FACE="Times New Roman" color="#FFFFFF">
Key:
</font></b> <font FACE="Times New Roman" color="#FFFFFF">
gridsize
</font></p>
<b>
<p><font FACE="Times New Roman" color="#FFFFFF">
Value:
</font></b> <font FACE="Times New Roman" color="#FFFFFF">
X Y Z
</font></p>
</sup>
</font>
</sup>
</font>
<p><sup><sup><font color="#FFFFFF" size="3">
Note that the values are the dimensions of those coordinates. It’s best to
keep them to power of 2 values. The default value for the gridsize (if left
unchanged) is 64 64 128. Setting higher x y and z values reduces the size of the
light grid data in both the .bsp file and in the Q3A game, but it also creates
less accurate dynamic model lighting.</font></sup></sup></p>
<b>
<p><sup><sup><font color="#FFFFFF" size="3">
Errors</font></sup></sup></p>
</b>
<p><sup><sup><font color="#FFFFFF" size="3">
Definitely set the x y and z values higher if you get:</font></sup></sup></p>
<p><sup><sup><font color="#FFFFFF" size="3">
************ ERROR ************</font></sup></sup></p>
<p><font color="#FFFFFF" size="4"><sup><sup>
MAX_MAP_LIGHTGRID</sup></sup></font></p>
<p><font color="#FFFFFF" size="4"><sup><sup>
when compiling your map with q3map.</sup></sup></font></p>
<p align="center"><font face="Times New Roman" size="4"><sup><a href="lighting_the_terrain.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="adding_buildings_to_terrain.html">Adding Buildings</a></sup></font></p>
<font SIZE="5">
<font FACE="Times New Roman">
<sup>
<p align="center">&nbsp;</p>
</sup>
</font></font></td>
</tr>
</table>
</div>
</b>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p align="center">-23-</p>
</body>
</html>

65
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/terrain_texture.html Normal file
View file

@ -0,0 +1,65 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>The Terrain Texture</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">The Terrain Texture</font></p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>In Q3:TA, there are two “terrain” textures in the common shader script.
One handles all the uses of terrain where the designer does not want “dust”
to rise up as the player jumps onto the terrain (common/terrain). The second
(common/terrain2) has an enable_dust surface parameter. The terrain texture
should be applied to all visible (in game) surfaces of the terrain entity.</p>
<p>Q3map looks for the word “terrain” in the name of the shader when
texturing terrain entities. If a shader is used without the word
&quot;terrain&quot; in it, and it’s not marked as nodraw, q3map will still do
a planar projection, but using that texture. It will not blend between textures,
however. This can be used to create hard edge texture transitions, or in cases
where you want to apply textures manually, and aren’t concerned about
blending.</p>
<p>If the terrain texture is applied to a non-terrain entity brush, the surface
will not draw. The projected terrain surface textures only work on surfaces that
are a part of entities with the proper terrain entity keys and values.</p>
<p>Their scripts for terrain are as follows:</p>
</font><font FACE="Courier New">
<p><font size="2">textures/common/terrain<br>
{<br>
surfaceparm nodraw<br>
surfaceparm nomarks<br>
surfaceparm nolightmap<br>
}<br>
textures/common/terrain2<br>
{<br>
qer_editorimage textures/common/terrain.tga<br>
surfaceparm dust<br>
surfaceparm nodraw<br>
surfaceparm nomarks<br>
surfaceparm nolightmap<br>
}</font></p>
</font>
<p align="center"><a href="creating_the_alphamap.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="blocking_vis.html">Blocking Vis</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</b>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p align="center">-17-</p>
</body>
</html>

192
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pages/the_meta_shader.html Normal file
View file

@ -0,0 +1,192 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>The Meta</title>
</head>
<body background="../pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b>
<p align="center"><font size="5">The Meta-Shader</font></p>
<div align="right">
<table border="1" cellspacing="1" width="100%" bordercolor="#808080" bgcolor="#000000" cellpadding="10">
<tr>
<td width="100%"><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; The shader is the group or family of related shaders used to texture a
terrain entity. The shader key/value pair in the entity identifies the
metashader to be used. The suffix (either “_#” for a root shader or “#to#”
for a blended shader.</p>
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; For each root shader that you want to blend, you need a blend shader. Note
that you only need to make the blend once. If you have mpterra2_0to2, you don’t
need mpterra2_2to0.</p>
<p>&nbsp;</p>
</font><b><font SIZE="4">
<p>Example Terrain Shader</p>
</font></b><font FACE="Times New Roman">
<p>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; This was the shader used to map textures on mpterra2 (hence the metashader
name)</p>
</font><font FACE="Courier New">
<p><font size="2">//****************************************************<br>
// *************************************************<br>
// *<br>
// * MPTerra2 terrain shaders<br>
// *<br>
// *************************************************<br>
textures/terrain/mpterra2_0<br>
{<br>
surfaceparm nolightmap<br>
q3map_novertexshadows<br>
q3map_forcesunlight<br>
{<br>
map textures/stone/pjrock9b_2.tga<br>
rgbGen vertex<br>
tcmod scale 0.125 0.125<br>
}<br>
{<br>
map textures/skies2/clouds.tga<br>
blendfunc filter<br>
detail<br>
tcmod scale 0.01 0.01<br>
tcMod scroll -0.05 0.05<br>
tcmod transform 1 0 1 1 1 1<br>
}<br>
}<br>
textures/terrain/mpterra2_1<br>
{<br>
surfaceparm nolightmap<br>
q3map_novertexshadows<br>
q3map_forcesunlight<br>
{<br>
map textures/stone/pjrock12b_2.tga<br>
rgbGen vertex<br>
tcmod scale 0.1 0.1<br>
}<br>
{<br>
map textures/skies2/clouds.tga<br>
blendfunc filter<br>
detail<br>
tcmod scale 0.01 0.01<br>
tcMod scroll -0.05 0.05<br>
tcmod transform 1 0 1 1 1 1<br>
}<br>
}<br>
textures/terrain/mpterra2_2<br>
{<br>
surfaceparm nolightmap<br>
q3map_novertexshadows<br>
q3map_forcesunlight<br>
{<br>
map textures/stone/pjrock10b_2.tga<br>
tcmod scale 0.05 0.05<br>
rgbGen vertex<br>
}<br>
{<br>
map textures/skies2/clouds.tga<br>
blendfunc filter<br>
detail<br>
tcmod scale 0.01 0.01<br>
tcMod scroll -0.05 0.05<br>
tcmod transform 1 0 1 1 1 1<br>
}<br>
}<br>
textures/terrain/mpterra2_0to1<br>
{<br>
surfaceparm nolightmap<br>
q3map_novertexshadows<br>
q3map_forcesunlight<br>
{<br>
map textures/stone/pjrock9b_2.tga<br>
rgbGen vertex<br>
alphaGen vertex<br>
tcmod scale 0.125 0.125<br>
}<br>
{<br>
map textures/stone/pjrock12b_2.tga<br>
tcmod scale 0.1 0.1<br>
rgbGen vertex<br>
alphaGen vertex<br>
blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA<br>
}<br>
{<br>
map textures/skies2/clouds.tga<br>
blendfunc filter<br>
detail<br>
tcmod scale 0.01 0.01<br>
tcMod scroll -0.05 0.05<br>
tcmod transform 1 0 1 1 1 1<br>
}<br>
}<br>
textures/terrain/mpterra2_0to2<br>
{<br>
surfaceparm nolightmap<br>
q3map_novertexshadows<br>
q3map_forcesunlight<br>
{<br>
map textures/stone/pjrock9b_2.tga<br>
rgbGen vertex<br>
alphaGen vertex<br>
tcmod scale 0.125 0.125<br>
}<br>
{<br>
map textures/stone/pjrock10b_2.tga<br>
rgbGen vertex<br>
alphaGen vertex<br>
tcmod scale 0.05 0.05<br>
blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA<br>
}<br>
{<br>
map textures/skies2/clouds.tga<br>
blendfunc filter<br>
detail<br>
tcmod scale 0.01 0.01<br>
tcMod scroll -0.05 0.05<br>
tcmod transform 1 0 1 1 1 1<br>
}<br>
}<br>
textures/terrain/mpterra2_1to2<br>
{<br>
surfaceparm nolightmap<br>
q3map_novertexshadows<br>
q3map_forcesunlight<br>
{<br>
map textures/stone/pjrock12b_2.tga<br>
rgbGen vertex<br>
alphaGen vertex<br>
tcmod scale 0.1 0.1<br>
}<br>
{<br>
map textures/stone/pjrock10b_2.tga<br>
tcmod scale 0.05 0.05<br>
rgbGen vertex<br>
alphaGen vertex<br>
blendFunc GL_SRC_ALPHA GL_ONE_MINUS_SRC_ALPHA<br>
}<br>
{<br>
map textures/skies2/clouds.tga<br>
blendfunc filter<br>
detail<br>
tcmod scale 0.01 0.01<br>
tcMod scroll -0.05 0.05<br>
tcmod transform 1 0 1 1 1 1<br>
}<br>
}</font></p>
</font>
<p align="center"><a href="mapping_the_textures.html">Back</a> - <a href="table_of_contents.html">Table
of Contents</a> - <a href="lighting_the_terrain.html">Lighting the Terrain</a></p>
<p>&nbsp;</td>
</tr>
</table>
</div>
</b>
<p>&nbsp;</p>
<p>&nbsp;</p>
<p align="center">-21-</p>
</body>
</html>

BIN
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pics/background.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 30 KiB

BIN
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pics/start.gif Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 213 KiB

BIN
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/pics/terrain.jpg Normal file
View file

Binary file not shown.
Side by side

After

Width:  |  Height:  |  Size: 24 KiB

30
tools/radiant-config/radiant15-netradiant/q3rally.game/docs/Terrain_Manual/start.html Normal file
View file

@ -0,0 +1,30 @@
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<meta name="GENERATOR" content="Microsoft FrontPage 4.0">
<meta name="ProgId" content="FrontPage.Editor.Document">
<title>Terrain Construction for Quake 3 Engine Games</title>
</head>
<body background="pics/background.jpg" text="#FFFFFF" link="#FFFFFF" vlink="#FFFFFF" alink="#FFFFFF">
<b><font SIZE="7">
<p ALIGN="CENTER"><img border="0" src="pics/start.gif" width="800" height="600"></p>
<p ALIGN="CENTER">&nbsp;
</font></b>
Special Thanks to Jim Dos<font SIZE="2">é</font> and Jan Paul van Waveren
for their assistance and review (and making this all work in the first place)
and the same gratitude to Astrocreep for his review and suggestions for making
it into something people could understand.</p>
<p>The material here is for use in conjunction with the Q3Radiant <a href="http://www.qeradiant.com/manual/" target="_blank"> manual</a> for the
Quake 3 Engine and presumes familiarity with that tool and game engine. Although
compiling switches and shader commands are included here, this is not intended
to be a general update or revision to the Q3Radiant manual</p>
<p align="center"><b><a href="pages/table_of_contents.html">Table of Contents</a></b></p>
<p align="center">-1-</p>
</body>
</html>

10
tools/radiant-config/radiant15-netradiant/q3rally.game/game.xlink
View file

@ -1,5 +1,11 @@
<?xml version="1.0" encoding="iso-8859-1" standalone="yes"?>
<!-- Q3Rally links -->
<!-- generated by Radiant setup, modify at your own risks -->
<!-- links for the Quake III Arena game pack -->
<links>
<item name="Q3Rally website" url="http://www.q3rally.com/"/>
<item name="Model Manual" url="docs/Model_Manual/model_manual.htm"/>
<item name="Shader Manual" url="docs/Q3AShader_Manual/index.htm"/>
<item name="Terrain Manual" url="docs/Terrain_Manual/start.html"/>
<item name="Compiling Manual (q3map &amp; bspc)" url="docs/Compile_Manual/index.html"/>
<item name="TA Teams Manual" url="docs/New_Teams_For_Q3TA/index.html"/>
<item name="Team Arena Mapping" url="docs/Team_Arena_Mapping_Help/start.html"/>
</links>