Add Doom3 part of Yamagis dump
still need to fix it up and add missing pages
488
doom3/code.php
Normal file
|
@ -0,0 +1,488 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>id.sdk [The Code]</title>
|
||||
<LINK REL="stylesheet" HREF="style.css">
|
||||
</HEAD>
|
||||
|
||||
|
||||
<BODY marginwidth="0" marginheight="0" topmargin="0" leftmargin="0">
|
||||
|
||||
<table border=0 cellpadding=0 cellspacing=0 style="width: 100%; height: 99px">
|
||||
<tr>
|
||||
<td style="width: 171px"><img src="images/doom.jpg" style="width: 171px; height: 99px" alt=""></td>
|
||||
<td style="background: url(images/tile.gif)">
|
||||
<table border=0 cellpadding=0 cellspacing=0 width=600>
|
||||
<tr>
|
||||
<td style="height: 19px; background: url(images/sdk.gif) no-repeat"></td>
|
||||
<td rowspan=4 align=right><img src="images/id.gif" style="width: 42px; height: 99px" alt=""></td>
|
||||
</tr>
|
||||
<tr><td style="height: 29px; background: url(images/top.jpg) no-repeat"></td></tr>
|
||||
<tr><td style="height: 27px; background: url(images/middle.gif)" class="title"> Making DOOM 3 Mods : The Code</td></tr>
|
||||
<tr><td style="height: 24px; background: url(images/bottom.jpg) no-repeat"></td></tr>
|
||||
</table>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<table border=0 cellpadding=0 cellspacing=0 style="width: 770px">
|
||||
<tr>
|
||||
<td colspan=2 style="background: url(images/boxtop.gif);"><img src="images/span.jpg" style="width: 397px; height: 20px; float: left" alt=""></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="vertical-align: top; width: 152px; background: url(images/tileleft.gif)">
|
||||
<div class="leftMenu">
|
||||
<script src="menu.js"></script>
|
||||
</div>
|
||||
</td>
|
||||
<td class="mainContent">
|
||||
<p>
|
||||
|
||||
The Code is where all the real fun starts to happen. The Doom 3 SDK comes with pretty much half the source code for the game. I will briefly go over the major portions in the SDK, and touch on some subsystems that are in the main engine.
|
||||
|
||||
<div class="subsection">Compiling</div>
|
||||
The first thing you're going to need to do is make sure you can build and run the code. We developed it using Visual Studio.Net, it may or may not work in 6.0. Ideally all you have to do is double-click the solution file and hit build. It will create a gamex86.dll in the output folder. You're going to want to move this to your mod folder with either a batch file, a post build step, or just by changing the linker output directory.
|
||||
|
||||
<p>
|
||||
A quick way to test if your code
|
||||
is being used is by opening up Entity.cpp, scrolling idEntity::Spawn and inserting this code
|
||||
right at the beginning after the "if ( def )" line:
|
||||
<pre class="code">gameLocal.Printf("Hello %s!\n", classname);</pre>
|
||||
|
||||
This should cause "Hello <classname>!" to appear in the console any time a new entity spawns.
|
||||
|
||||
<div class="subsection">idLib</div>
|
||||
idLib is just a library where random, generic, often used code is stored. It contains things like string code, parsers, a couple hash tables, math libraries, timers, containers, etc. It is also where all the SSE code is stored so check out idLib/Math/Simd_*.* if you like that kind of thing.
|
||||
|
||||
<div class="subsection">Game System</div>
|
||||
There are a lot of parts to the game code that don't have anything to do with Doom 3, but rather are base pieces
|
||||
that the game code is built on top of.
|
||||
|
||||
<p>
|
||||
<b>GameSys</b><br>
|
||||
The very core of the game code is the GameSys. This contains the basic idClass class,
|
||||
as well as the event system and the save game system. The game system is very abstract and doesn't really know
|
||||
anything about the actual game that is built on top of it. All it knows how to do is create objects,
|
||||
fire events, and walk the objects for saving and restoring.
|
||||
|
||||
<p>
|
||||
When you specify the "spawnclass" in an entitydef it calls idClass::CreateInstance to create a instance of that
|
||||
spawn class. The classes are registered with idClass by using the CLASS_DECLARATION macro defined in Class.h
|
||||
|
||||
<p>
|
||||
<b>AI</b><br>
|
||||
The AI folder doesn't actually contain the AI for the monsters (those are defined in scripts). Rather the C++ AI
|
||||
code is the 'glue' that ties the scripts to the rest of the game. It contains routing and pathing through the AAS
|
||||
(Area Awareness System), as well as event handling. The core object is idAI, which derives from
|
||||
idActor->idAFEntity_Gibbable->idAFEntity_Base->idAnimatedEntity->idEntity->idClass.
|
||||
|
||||
<p>
|
||||
In Doom 3, routing is "how do I get from one area of the map to the other" whereas pathing is "how do I navigate
|
||||
around that chair". The difference is subtle but important.
|
||||
|
||||
<p>
|
||||
AI is the game system that is most closely tied to the actual game that is being produced. An example
|
||||
is idAI_Vagary, which contains special code for the Vagary to pick up and throw objects at the player.
|
||||
|
||||
<p>
|
||||
AI_events.cpp contains all the code to handle events in the AI scripts. Most of the functions are simply stubs that
|
||||
call into AI.cpp, where the bulk of the code is. An example of that is Event_KickObstacles, which just fixes up the
|
||||
arguments and calls KickObstacles().
|
||||
|
||||
|
||||
<p>
|
||||
<b>Physics</b><br>
|
||||
The Doom 3 game code ships with the entire Doom 3 physics system. There is absolutely no physics code in the core
|
||||
engine itself. Even the LCP solvers are in idLib. The physics code is absolutely massive, but luckily you don't
|
||||
have to have a PhD in Physics to understand what most of it is doing and (more importantly) how to use it.
|
||||
|
||||
<p>
|
||||
An idPhysics object is a tool to manipulate the position and orientation of an entity. The physics object is a
|
||||
container for idClipModels used for collision detection. The physics system deals with moving these collision models
|
||||
through the world according to the laws of physics or other rules.
|
||||
|
||||
<p>
|
||||
Every idEntity has a pointer to an idPhysics object, the object can be moved around using idForces, though there
|
||||
are other ways to move it. Every frame the idEntity updates its visual model from the origin and axis information
|
||||
in the physics system.
|
||||
|
||||
<p>
|
||||
The render system has a visual model of every entity, and the physics system has a clip model of every entity
|
||||
(sometimes called combat model). A collision model can be loaded from the map model (using any surfaces marked as
|
||||
clip), or it can be generated from the render model (by default it uses all surfaces in the render model, but a
|
||||
simplified object can be created with the "<samp>textures/common/collision</samp>" material applied to it, in which
|
||||
case it uses that simplified model instead), or it can be loaded from a .cm file (created using DOOMEdit).
|
||||
|
||||
<p>
|
||||
There are multiple subclasses of idPhysics which all implement specialized types of physics. For example, doors
|
||||
use idPhysics_Parametric, rag dolls uses idPhysics_AF, etc. Most of the physics types are self explanitory,
|
||||
and all of them have a brief description at the top of the .h file.
|
||||
|
||||
<p>
|
||||
If you don't want physics to be
|
||||
run on an object, make sure the TH_PHYSICS flag is cleared (for example, when an object comes to rest). You should
|
||||
unlink the clip model if an object cannot be touched (rather than just setting the content mask to 0). This will
|
||||
speed up collision detection because it won't even visit that clip model. You should make sure there are no little
|
||||
jitters in things that could cause the physics to be run constantly on an object. There are a few console commands
|
||||
to aid in debugging physics slow downs. The most useful is probably g_showActiveEntities.
|
||||
|
||||
<p>
|
||||
<b>Anim</b><br>
|
||||
The animation system doesn't decide which animations to play (that is done in scripts), but rather it is in charge
|
||||
blending animations, lerping between frames, blending bone weights, and calling frame commands.
|
||||
|
||||
<p>
|
||||
In Doom 3, there are 4 different animation channels ("torso", "legs", "head", "eyelids") as well as a fifth pseudo
|
||||
channel ("all"). A different animation can be playing on each animation chanel simultaneously. This avoids the
|
||||
quake 2 "running while firing" problem, as well as the quake 3 "my model is in pieces" problem. There is one
|
||||
single mesh, but each animation affects a different set of bones. All of this is handled in Anim_Blend. It also
|
||||
handles blending between two completely different animations (for example when you switch between weapons).
|
||||
|
||||
<p>
|
||||
The frame commands (defined in the modelDef) are called from ServiceAnims. Every time it updates the animation, it
|
||||
sees if it passed a 'boundry' where a frame command was defined. It is actually really easy to add your own frame
|
||||
commands. You just have to add an item to the frameCommandType_t enum, then implement the case statements for it in
|
||||
AddFrameCommand and CallFrameCommands.
|
||||
|
||||
<p>
|
||||
<b>Script</b><br>
|
||||
Similar to Anim, the Script subsystem is pretty generic, and doesn't really know about Doom at all.
|
||||
The main entry point into the script system is through idProgram. There is only ever one program living in
|
||||
the system (it is a member of idGameLocal). It scans the scripts directory and compiles all the scripts
|
||||
contained therein. It holds all the function and variable information. idProgram is the only class that
|
||||
uses idCompiler. idCompiler is the Op Code generator. It uses the lexer and parser defined in idLib.
|
||||
|
||||
<p>
|
||||
To actually call a script function, create a new idThread (which should be allocated with new, not created
|
||||
on the stack). There are static functions in idThread that handle the tracking of currently active threads.
|
||||
Every thread has an idInterpreter, which contains all the stack information and instruction pointer for a
|
||||
thread. The game threads are not actual operating system threads. The way it works is the scripting system
|
||||
provides every thread a chance to run every frame. The thread runs until it gets a multi-frame event or
|
||||
encounters a pause event, such as sys.pause, sys.waitFor, or sys.wait (there's also a wait command on ai
|
||||
objects).
|
||||
|
||||
<div class="subsection">Game Utility files</div>
|
||||
|
||||
<p>
|
||||
<b>Network</b><br>
|
||||
The raw network code is still inside the engine, but Doom 3 exposes a lot of networking that previous id engines
|
||||
have not. In Doom 3 you can sculpt custom bit messages containing anything you want that are sent across the wire
|
||||
to any client you want. This is obviously a very powerful tool. The bulk of the code is in Game_network.cpp, but
|
||||
there is network code spread across almost all the game files. Two of the most important functions are
|
||||
WriteToSnapshot and ReadFromSnapshot. These two functions handle periodic updates of entities. All the clients
|
||||
are actually running the exact same game code as the server, so in theory they should never get out of sync, but
|
||||
as well all know, they do get out of sync. The snapshot mechanism will periodically snap the clients back in to
|
||||
sync with the server. There are other ways to send updates, for example client events and reliable messages, but
|
||||
those should be easy enough to figure out if you need to use them.
|
||||
|
||||
<p>
|
||||
<b>Game / GameLocal</b><br>
|
||||
idGame is the interface class for the entire game dll. It is the only thing the core engine sees. The first thing
|
||||
the engine does when it loads up a game dll is call GetGameAPI, passing it interface pointers to a bunch of internal
|
||||
system classes. This function copies the system class pointers over to global pointers in the dll, then returns
|
||||
a pointer to an idGameLocal object (which is cast to an idGame). idGameLocal is the actual implementation of the
|
||||
game interface. Since gameLocal is a global object in the game dll, a lot of really random functions ended up
|
||||
getting thrown in there. The really important functions are defined in idGame as well (such as InitFromNewMap,
|
||||
RunFrame, and Draw).
|
||||
|
||||
<p>
|
||||
MultiplayerGame defines all the multiplayer specific game code, such as keeping score and voting.
|
||||
|
||||
<p>
|
||||
<b>Pvs</b><br>
|
||||
The PVS (Potentially Visible Set) tracks what areas can be seen from what other areas. It is calculated at map load
|
||||
from the render portals. It allows the game code to determine if objects or monsters should go dormant, and is also
|
||||
used by the network code to determine which updates to send to which clients.
|
||||
|
||||
<p>
|
||||
<b>AF</b><br>
|
||||
idAF is an articulated figure helper class. It contains a pointer to an animator, which it uses to move around the
|
||||
object. It doesn't do any solving (that is all done in idPhysics_AF), but applies the solved AF positions to the
|
||||
entity model (remember, the physics model is a completely seperate system from the render system).
|
||||
|
||||
<p>
|
||||
<b>IK</b><br>
|
||||
idIK is the inverse kinematics helper class. It is currently only used by actors to keep their feet on the ground,
|
||||
but it could easily be used for more. It is used similarly to idAF.
|
||||
|
||||
<p>
|
||||
<b>PlayerIcon</b><br>
|
||||
idPlayerIcon is a helper class for drawing the lag and chat icons above the player head in multiplayer.
|
||||
|
||||
<p>
|
||||
<b>PlayerView</b><br>
|
||||
idPlayerView is a helper utility that renders the scene from the players perspective. It's where the PDA gets drawn,
|
||||
as well as where last minute effects such as screen blood splats, berserker, influence, and double vision views, and
|
||||
screen fades get handled.
|
||||
|
||||
<p>
|
||||
<b>SmokeParticles</b><br>
|
||||
The smoke particle system is used for particle effects that are constantly changing position or orientation in a
|
||||
completely non-paramentric way. An example of this is is smoke effect coming out of the
|
||||
|
||||
<p>
|
||||
<b>GameEdit</b><br>
|
||||
Ok I lied, the core engine also sees idGameEdit. This is a utility class that allows the editors (like the
|
||||
<a href="editor_af.php">AFEditor</a>) to manipulate entities while the game is running.
|
||||
|
||||
<div class="subsection">Game Entities</div>
|
||||
|
||||
Now that I've gone over the major systems that the game builds on, I can start to talk about the actual game code.
|
||||
The rest of the code I'm going to talk about is almost all derived from idEntity. These are things like doors,
|
||||
monsters, players, items, trains, triggers, lights, and a multitude of others. I think the easiest way to go over
|
||||
it is to just talk about each file one by one.
|
||||
|
||||
<p>
|
||||
<b>Entity</b><br>
|
||||
idEntity is the base class from which all entities are derived. It handles most "low level"
|
||||
maintenance functions that are common to all entities, such as spawning, thinking, running physics, binding,
|
||||
playing sounds, showing, hiding, etc.
|
||||
|
||||
<p>
|
||||
Entity.cpp also contains idAnimatedEntity, which is just an entity that has an associated animator (which can
|
||||
play animations).
|
||||
|
||||
<p>
|
||||
<b>WorldSpawn</b><br>
|
||||
The worldspawn is an entity that represents the entire level itself. The only code
|
||||
here reads some properties from the map to set up gravity and stamina, and to call the level script.
|
||||
|
||||
<p>
|
||||
<b>Camera</b><br>
|
||||
idCamera is used for objective screenshots (when the objective tool tip pops up), as well as
|
||||
for cinematic cameras. The bulk of the code deals with following the animation (defined in a md5camera class).
|
||||
Cameras can also be bound to moving entities (since any entity can be bound to any other entity).
|
||||
|
||||
<p>
|
||||
<b>SecurityCamera</b><br>
|
||||
Security cameras are used to make panning, breakable security cameras (such as the
|
||||
ones in CPU). They simply move side to side, minding their own business.
|
||||
|
||||
<p>
|
||||
<b>BrittleFracture</b><br>
|
||||
BrittleFracture is the term for any object that shatters rather spectacularly when
|
||||
it is damaged. Generally this means glass, but technically you could put any texture you want on a BrittleFracture
|
||||
object. The brittle fracture will subdivide a plane into many shards, then keep track of the links between the
|
||||
shards, so when there is sufficient damage between two shards, the link will break. The individual pieces of
|
||||
glass are run through the physics system as part of an idPhysics_StaticMulti. This makes breaking glass quite
|
||||
slow. Hacks could be done to speed it up by treating the shards as particles instead (thereby not running them
|
||||
through the physics system) but that wouldn't look quite as good.
|
||||
|
||||
<p>
|
||||
<b>Fx</b><br>
|
||||
An FX entity is a container object for <a href="fx.php">special effects</a>. This file also
|
||||
contains idTeleporter which is the teleporter destination entity.
|
||||
|
||||
<p>
|
||||
<b>Light</b><br>
|
||||
The idLight entity represents just about everything that can be done with lights: turning
|
||||
on and off, pulsating with sounds, fading in and out, etc.
|
||||
|
||||
<p>
|
||||
<b>Sound</b><br>
|
||||
idSound is like idLight but for sounds
|
||||
|
||||
<p>
|
||||
<b>Item</b><br>
|
||||
Items are things the player can pick up to get something. Weapons, health, armor, etc are
|
||||
all items. This file defines the base idItem (which is used for most things), as well as idMoveableItem
|
||||
(which is used for the armor, and a few other larger objects), idItemPowerup (invisibility, berserk, etc),
|
||||
idObjective (a metaitem that represents an objective), idVideoCDItem, idPDAItem, and idMoveablePDAItem. It
|
||||
also defines idItemRemover and idObjectiveComplete which are entities that remove items from the players
|
||||
iventory. The difference between an item and a moveable item lies in how the environment (like doors)
|
||||
react when they touch the item. For regular items, the object will go right through it, but for moveable
|
||||
items, the item will get pushed by the mover.
|
||||
|
||||
<p>
|
||||
<b>Moveable</b><br>
|
||||
An idMoveable is like a moveable item that you can't pick up. Examples are the hamburger
|
||||
that people love to punch, crates, soda cans, trash cans, trash, etc... There are two special case moveables
|
||||
defined: idBarrel and idExplodingBarrel. I hope the behaviour is obvious for those two.
|
||||
|
||||
<p>
|
||||
<b>Trigger</b><br>
|
||||
A trigger is an entity that triggers a target entity or calls a script when something happens. "something"
|
||||
depends on what kind of trigger it is. There are touch triggers for players, touch triggers for monsters,
|
||||
timer triggers, hurt triggers, fade triggers, triggers that only trigger after they have been triggered a
|
||||
certain number of times, triggers that only trigger for certain entities, etc. The main thing to keep in
|
||||
mind is whenever the trigger gets triggered, it will send an Activate event to any entities it targets.
|
||||
|
||||
<p>
|
||||
<b>Target</b><br>
|
||||
A target is used as the target of a trigger. There are about 30 different target entity types, and they do
|
||||
wildly different things, so I'm not going to mention them. Luckily most targets tend to be fairly small
|
||||
(having only an Event_Activate function), so I'd take a minute to just scan through Target.h
|
||||
|
||||
<p>
|
||||
<b>Misc</b><br>
|
||||
Misc is where we put entities that didn't really fit anywhere else. It contains things like idVacuumEntity
|
||||
and idPlayerStart. It contains about 30 entities as well, so I'm not going to go over those either.
|
||||
|
||||
<p>
|
||||
<b>AFEntity</b><br>
|
||||
An AFEntity is an entity with an associated articulated figure. It can actually be one of many different types
|
||||
of entities. Players, monsters, vehicles, chains (such as the crane), and generic dead bodies are all AF entities.
|
||||
There is an idAFEntity_Base class which contains some basic functions all AF entities share, then derived from that
|
||||
is idAFEntity_Gibbable, idAFEntity_Vehicle, idAFEntity_SteamPipe, and idAFEntity_ClawFourFingers. The AFEntity doesn't
|
||||
actually do much other than spawn and destroy the AF entity because all the real work is done in idAF, and idPhysics_AF.
|
||||
|
||||
<p>
|
||||
<pre>
|
||||
idClass
|
||||
+-idEntity
|
||||
+-idAnimatedEntity
|
||||
|-idWeapon
|
||||
|-idAFAttachment
|
||||
+-idAFEntity_Base ---- Uses idAF
|
||||
|-idAFEntity_ClawFourFingers
|
||||
|-idAFEntity_Vehicle
|
||||
| |-idAFEntity_VehicleFourWheels
|
||||
| +-idAFEntity_VehicleSixWheels
|
||||
+-idAFEntity_Gibbable
|
||||
|-idAFEntity_WithAttachedHead
|
||||
|-idAFEntity_Generic
|
||||
|-idAnimated
|
||||
+-idActor ---- Uses idIK
|
||||
|-idPlayer
|
||||
+-idAI
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
<b>Actor</b><br>
|
||||
An actor is anything that requires some amount of AI. Generally an actor has a .script associated with it, but it
|
||||
doesn't always need one (an actor with no script with just stand there and blink -- just like in real life). idActor
|
||||
is derived from idAFEntity_Gibbable.
|
||||
|
||||
|
||||
<p>
|
||||
<b>Player</b><br>
|
||||
idPlayer is... the player. It handles input handling, item handling, cinematics, animations, teleportation, and a whole
|
||||
slew of other things (roughly 8,000 lines worth). Player.cpp is also home to idInventory, which is just a helper class
|
||||
for the player's inventory.
|
||||
|
||||
<p>
|
||||
<b>Projectile</b><br>
|
||||
An idProjectile is an entity that flies through the world and causes damage to whatever it hits. Generally they are fired
|
||||
by weapons (see below) but they don't have to be. For example, the Revenant creates projectiles, but he technically
|
||||
doesn't have any weapon (the shoulder mounted rocket launchers are part of his model, and the rockects are spawned in
|
||||
script).
|
||||
|
||||
<p>
|
||||
<b>Weapon</b><br>
|
||||
An idWeapon is an entity the player holds in front of him as he runs around in the game. It may or may not shoot projectiles,
|
||||
but most of the time it does. The interesting thing about idWeapon is there is one per player rather than
|
||||
one per weapon. When the player switches weapons, it simply loads a new weapon script into the existing idWeapon.
|
||||
|
||||
<div class="subsection">The Engine Code</div>
|
||||
|
||||
Now that we've gone over a bunch of the systems you have the source code to, let's go over some systems you don't have the code for.
|
||||
|
||||
<p>
|
||||
<b>System</b><br>
|
||||
Sys is where all the operating system specific calls go. Things like locking memory and spawning threads go in here. All the
|
||||
functions and classes are defined in sys_public.h in the 'sys' folder. All of the functions accessible to the game are members
|
||||
of the idSys singleton (which you access through the global 'sys' object).
|
||||
<p>
|
||||
<b>Common</b><br>
|
||||
idCommon handles starting up and shutting down all the other systems (including the game system). It also performs error, warning, and
|
||||
debug messsage printing (it routes the message to the log file, console, early console, dedicated console, or whoever else needs it).<br>
|
||||
In the engine, the code looks something like this:
|
||||
<pre class="code">
|
||||
void main(void) {
|
||||
Sys_Init();
|
||||
common->Init();
|
||||
while (1) {
|
||||
common->Frame();
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
<b>Command System</b><br>
|
||||
idCmdSystem handles commands the user types in to any one of the consoles (in-game, dedicated, or editor). The game code can
|
||||
also pass commands directly to the command system for processing. Every frame the command system will parse out the command buffer
|
||||
and execute any waiting commands by calling the callback functions associated with the commands. For example, "quit" will call the
|
||||
Com_Quit_f callback function (which then calls common->Quit).
|
||||
|
||||
<p>
|
||||
<b>CVar System</b><br>
|
||||
idCVarSystem handles console variables. Console variables in Doom 3 are way cooler than console variables in previous engines.
|
||||
They are added to the CVar system like this:
|
||||
<pre class="code">idCVar com_showFPS( "com_showFPS", "0", CVAR_BOOL|CVAR_SYSTEM, "" );</pre>
|
||||
The constructor for idCVar will add the cvar to a static list of cvars, which will then get added to the cvar system when it starts
|
||||
up. You can then access the cvar through the instantiated object. You can also access cvars through functions in the actual cvar
|
||||
system, but this is a bit slower (because it has to do the lookup every time rather than storing it off in the cvar object).
|
||||
|
||||
<p>
|
||||
<b>File System</b><br>
|
||||
idFileSystem allows access to files. The is very abstract in that the file you request may be in the real file system, or it may
|
||||
be in the pack file system. It also may be in the mod directory or the game directory. When you request 'cheese/gouda.jpg' it will
|
||||
search the game directory, then the game pack files, then the base directory, then the base pack files. If the server is running in
|
||||
pure mode, then the file system will only check the pack files. File system tracks all files that are accessed on the server for doing
|
||||
the pure checks, it can also be set to copy mode (fs_copyfiles) to help in making builds.
|
||||
|
||||
<p>
|
||||
<b>Networking System</b><br>
|
||||
The game system really only has access to two parts of the networking system: callbacks to read/write (idGame::ClientReadSnapshot /
|
||||
idGame::ServerWriteSnapshot) and functions to send and recieve reliable messages (in idNetworkSystem). There are a few other
|
||||
functions in idNetworkSystem to get statistics like ping and packet loss.
|
||||
|
||||
<p>
|
||||
<b>Render System</b><br>
|
||||
The renderer is broken in to 3 different conceptual parts:
|
||||
<p>
|
||||
<li>The RenderWorld is very similar to a scene graph. It contains all the render models and textures in the scene arranged in some
|
||||
easy to cull fashion. It handles culling and dispatches commands to the back end.
|
||||
<p>
|
||||
<li>The back end is a heavily optimized system for rendering triangle soups. There is a seperate back end written for each major
|
||||
hardware architecture that Doom 3 supports (NV20, R300, ARB, ARB2, CG).
|
||||
<p>
|
||||
<li>The Render System manages all the render worlds (there can be more than one), and works as an entry point for the render system.
|
||||
|
||||
<p>
|
||||
<b>Sound System</b><br>
|
||||
The sound system is very similar to the render system in that there is a sound world (or two, or three) that handles all the really
|
||||
hard stuff, and the sound system just serves as a ring leader. The sound world keeps track of where all the emitters are, what state
|
||||
they are in, and where the listener is.
|
||||
|
||||
<p>
|
||||
<b>Render Model Manager</b><br>
|
||||
idRenderModelManager handles loading and freeing of render models. The models can be in a variety of file formats including BSP,
|
||||
LWO and ASE. The model manager caches the model data the first time it is requested. Every model that is going to be used for a
|
||||
level should be loaded by the model manager during level load (in between BeginLevelLoad and EndLevelLoad calls). This will ensure
|
||||
minimal disk hits during actual game play.
|
||||
|
||||
<p>
|
||||
<b>User Interface Manager</b><br>
|
||||
idUserInterfaceManager behaves exactly like the model manager, except for GUIs.
|
||||
|
||||
<p>
|
||||
<b>Declaration Manager</b><br>
|
||||
idDeclManager handles loading, caching, reading, and writing any kind of decl. It scans the directories and parses out decls, automagically
|
||||
creating the proper decl object for each type. You can register your own custom decl types with the decl manager, as well as new folders
|
||||
for it to scan. Just like the other managers, any decls that it loads should be done during the designated level load time to prevent
|
||||
unnecessary disk hits.
|
||||
|
||||
<p>
|
||||
<b>AAS file manager</b><br>
|
||||
idAASFileManager loads and frees AAS (area awareness system) files. It is the only way to get an idAASFile in the game code.
|
||||
|
||||
<p>
|
||||
<b>Collision Model Manager</b><br>
|
||||
The collision model manager is exactly like the render model manager, except for the physics system rather than the render system.
|
||||
|
||||
|
||||
<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan=2 bgcolor="#CCCCCC"><img src="images/span2.gif" style="width: 397px; height: 8px; float: left;"></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<table border=0 cellpadding=0 cellspacing=0 width=770>
|
||||
<tr>
|
||||
<td align=left class="legalese">Copyright © 2004 <a href="http://www.idsoftware.com">id software</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
</body>
|
||||
</html>
|
152
doom3/downloads.php
Normal file
|
@ -0,0 +1,152 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>id.sdk [Downloads]</title>
|
||||
<LINK REL="stylesheet" HREF="style.css">
|
||||
</HEAD>
|
||||
|
||||
|
||||
<BODY marginwidth="0" marginheight="0" topmargin="0" leftmargin="0">
|
||||
|
||||
<table border=0 cellpadding=0 cellspacing=0 style="width: 100%; height: 99px">
|
||||
<tr>
|
||||
<td style="width: 171px"><img src="images/doom.jpg" style="width: 171px; height: 99px" alt=""></td>
|
||||
<td style="background: url(images/tile.gif)">
|
||||
<table border=0 cellpadding=0 cellspacing=0 width=600>
|
||||
<tr>
|
||||
<td style="height: 19px; background: url(images/sdk.gif) no-repeat"></td>
|
||||
<td rowspan=4 align=right><img src="images/id.gif" style="width: 42px; height: 99px" alt=""></td>
|
||||
</tr>
|
||||
<tr><td style="height: 29px; background: url(images/top.jpg) no-repeat"></td></tr>
|
||||
<tr><td style="height: 27px; background: url(images/middle.gif)" class="title"> Making DOOM 3 Mods : Downloads</td></tr>
|
||||
<tr><td style="height: 24px; background: url(images/bottom.jpg) no-repeat"></td></tr>
|
||||
</table>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<table border=0 cellpadding=0 cellspacing=0 style="width: 770px">
|
||||
<tr>
|
||||
<td colspan=2 style="background: url(images/boxtop.gif);"><img src="images/span.jpg" style="width: 397px; height: 20px; float: left" alt=""></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="vertical-align: top; width: 152px; background: url(images/tileleft.gif)">
|
||||
<div class="leftMenu">
|
||||
<script src="menu.js"></script>
|
||||
</div>
|
||||
</td>
|
||||
<td class="mainContent">
|
||||
<div class="subsection">Source Code</div>
|
||||
<b>SDK 3</b>
|
||||
<p>
|
||||
Contains the game source code, expansion source code (Resurrection of Evil), maya importer source, vehicle demo, and sample Maya files
|
||||
<ul>
|
||||
<li><a href="ftp://ftp.idsoftware.com/idstuff/doom3/source/win32/D3_1.3_SDK.exe">ftp.idsoftware.com (Windows)</a><br>
|
||||
<li><a href="ftp://ftp.idsoftware.com/idstuff/doom3/source/linux/doom3-linux-1.3.1302-sdk.x86.run">ftp.idsoftware.com (Linux)</a><br>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
|
||||
<b>SDK 2</b> (old)
|
||||
<p>
|
||||
Contains the game source code, vehicle demo, and sample Maya files
|
||||
<ul>
|
||||
<li><a href="ftp://ftp.idsoftware.com/idstuff/doom3/source/win32/Doom3_SDK_2.exe">ftp.idsoftware.com (Windows)</a><br>
|
||||
<li><a href="ftp://ftp.idsoftware.com/idstuff/doom3/source/linux/doom3-linux-1.1.1282-sdk.x86.run">ftp.idsoftware.com (Linux)</a><br>
|
||||
<p>
|
||||
Mirrors<br>
|
||||
<li><a href="http://www.fileshack.com/file.x?fid=5646">File Shack</a><br>
|
||||
<li><a href="http://www.3dgamers.com/dlselect/games/doom3/thirdparty/doom3_sdk_2.exe.html">3dgamers</a><br>
|
||||
<li><a href="http://www.fileplanet.com/files/140000/146754.shtml">File Planet</a><br>
|
||||
</ul>
|
||||
|
||||
<p>
|
||||
|
||||
<b>SDK 1</b> (old)
|
||||
<p>
|
||||
Contains the game source code, and some sample Maya (ma, mb) files
|
||||
<ul>
|
||||
<li><a href="ftp://ftp.idsoftware.com/idstuff/doom3/source/win32/Doom3_SDK.exe">ftp.idsoftware.com (Windows)</a><br>
|
||||
<p>
|
||||
Mirrors<br>
|
||||
<li><a href="http://www.gamershell.com/download_7278.shtml">gamershell</a><br>
|
||||
<li><a href="http://doom3.filefront.com/file/DOOM_3_Software_Development_Kit_SDK;31586">FileFront</a><br>
|
||||
</ul>
|
||||
</ul>
|
||||
|
||||
<div class="subsection">Id software Tools / Utilities</div>
|
||||
<ul>
|
||||
<li><a href="downloads/MayaImportx86_Maya45.zip">Maya 4.5 Importer</a><br>
|
||||
<li><a href="downloads/MayaImportx86_Maya50.zip">Maya 5.0 Importer</a><br>
|
||||
<li><a href="downloads/MayaImportx86_Maya60.zip">Maya 6.0 Importer</a><br>
|
||||
</ul>
|
||||
|
||||
<div class="subsection">Other Tools / Utilities</div>
|
||||
Please note, these are completely unsupported and id software cannot be certain that any of them do what they say they do. Use at your own risk.
|
||||
<p>
|
||||
|
||||
<b>GUI Tools</b>
|
||||
<ul>
|
||||
<li><a href="http://www.splashdamage.com/files/q3font_1.52.zip">Q3Font</a><br>
|
||||
<li><a href="http://members.optusnet.com.au/~g.davies/ExportFontToDoom3/">Grant Davies ExportFontToDoom3</a> (with Source)<br>
|
||||
</ul>
|
||||
|
||||
<b>DoomEdit tools</b>
|
||||
<ul>
|
||||
<li><a href="http://www.doom3world.org/phpbb2/viewtopic.php?t=6025">DoomEdit CleanMaterials pak</a><br>
|
||||
<li><a href="http://www.doom3world.org/phpbb2/viewtopic.php?t=7276">DoomEdit CleanDefs pak</a><br>
|
||||
<li><a href="http://www.doom3world.org/phpbb2/viewtopic.php?t=7439">DoomEdit CleanSounds pak</a><br>
|
||||
<li><a href="http://www.doom3world.org/phpbb2/viewtopic.php?t=7479">DoomEdit CleanSkins pak</a><br>
|
||||
<li><a href="http://www.doom3world.org/phpbb2/viewtopic.php?t=6744">Doom 3 Editor Launcher with .PK4 Creator</a><br>
|
||||
</ul>
|
||||
<b>Model Viewers</b>
|
||||
<ul>
|
||||
<li><a href="http://www.doom3world.org/phpbb2/viewtopic.php?t=1281">der_ton's modelviewer (for MD5, ASE and OBJ)</a><br>
|
||||
<li><a href="http://www.doom3world.org/phpbb2/viewtopic.php?t=2305">KPixel's Model Viewer</a><br>
|
||||
</ul>
|
||||
<b>3dsmax</b>
|
||||
<ul>
|
||||
<li><a href="http://www.doom3world.org/phpbb2/viewtopic.php?t=3229">der_ton's MD5->3dsmax importer</a><br>
|
||||
<li><a href="http://www.doom3world.org/phpbb2/viewtopic.php?t=1914">der_ton's 3dsmax->MD5 exporter</a><br>
|
||||
<li><a href="http://www.doom3world.org/phpbb2/viewtopic.php?t=4618">BeRSeRKeR's MD5 Exporter for MAX/gmax</a><br>
|
||||
<li><a href="http://personal.telefonica.terra.es/web/codegarrofi/">Garrofi's MD5->Max importer</a><br>
|
||||
</ul>
|
||||
<b>Blender</b>
|
||||
<ul>
|
||||
<li><a href="http://www.doom3world.org/phpbb2/viewtopic.php?t=1711">der_ton's Blender->MD5 exporter</a><br>
|
||||
<li><a href="http://www.doom3world.org/phpbb2/viewtopic.php?t=6901">der_ton's MD5->Blender importer</a><br>
|
||||
</ul>
|
||||
<b>Maya</b>
|
||||
<ul>
|
||||
<li><a href="http://www.doom3world.org/phpbb2/viewtopic.php?t=6278">seith's Maya Importer</a><br>
|
||||
</ul>
|
||||
<b>Lightwave</b>
|
||||
<ul>
|
||||
<li><a href="http://www.doom3world.org/phpbb2/viewtopic.php?t=6493">Rich / Der_ton's Lightwave MD5Camera Export LScript</a><br>
|
||||
<li><a href="http://www.doom3world.org/phpbb2/viewtopic.php?t=4595">Bozo's Lightwave to MD5mesh / MD5anim Converter</a><br>
|
||||
</ul>
|
||||
<b>Xsi (SoftImage)</b>
|
||||
<ul>
|
||||
<li><a href=http://www.doom3world.org/phpbb2/viewtopic.php?p=79932">senkusha's Xsi MD5 exporter</a><br>
|
||||
</ul>
|
||||
<b>Texture Tools</b>
|
||||
<ul>
|
||||
<li><a href="http://engineering.soclab.bth.se/tools/177.aspx">Open Render Bump</a>
|
||||
<li><a href="http://www.ati.com/developer/compressonator.html">The Compressonator</a>
|
||||
<li><a href="http://developer.nvidia.com/object/nv_texture_tools.html">nVidia Texture Tools (DDS plugins)</a>
|
||||
</ul>
|
||||
|
||||
<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan=2 bgcolor="#CCCCCC"><img src="images/span2.gif" style="width: 397px; height: 8px; float: left;"></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<table border=0 cellpadding=0 cellspacing=0 width=770>
|
||||
<tr>
|
||||
<td align=left class="legalese">Copyright © 2004 <a href="http://www.idsoftware.com">id software</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
</body>
|
||||
</html>
|
BIN
doom3/downloads/D3SDK2_MayaImport_Setup.exe
Normal file
BIN
doom3/downloads/MayaImportx86.zip
Normal file
BIN
doom3/downloads/MayaImportx86_Maya45.zip
Normal file
BIN
doom3/downloads/MayaImportx86_Maya50.zip
Normal file
BIN
doom3/downloads/MayaImportx86_Maya60.zip
Normal file
BIN
doom3/downloads/fireballmod.zip
Normal file
87
doom3/editor_af.php
Normal file
|
@ -0,0 +1,87 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>id.sdk [The AF Editor]</title>
|
||||
<LINK REL="stylesheet" HREF="style.css">
|
||||
</HEAD>
|
||||
|
||||
|
||||
<BODY marginwidth="0" marginheight="0" topmargin="0" leftmargin="0">
|
||||
|
||||
<table border=0 cellpadding=0 cellspacing=0 style="width: 100%; height: 99px">
|
||||
<tr>
|
||||
<td style="width: 171px"><img src="images/doom.jpg" style="width: 171px; height: 99px" alt=""></td>
|
||||
<td style="background: url(images/tile.gif)">
|
||||
<table border=0 cellpadding=0 cellspacing=0 width=600>
|
||||
<tr>
|
||||
<td style="height: 19px; background: url(images/sdk.gif) no-repeat"></td>
|
||||
<td rowspan=4 align=right><img src="images/id.gif" style="width: 42px; height: 99px" alt=""></td>
|
||||
</tr>
|
||||
<tr><td style="height: 29px; background: url(images/top.jpg) no-repeat"></td></tr>
|
||||
<tr><td style="height: 27px; background: url(images/middle.gif)" class="title"> Making DOOM 3 Mods : The AF Editor</td></tr>
|
||||
<tr><td style="height: 24px; background: url(images/bottom.jpg) no-repeat"></td></tr>
|
||||
</table>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<table border=0 cellpadding=0 cellspacing=0 style="width: 770px">
|
||||
<tr>
|
||||
<td colspan=2 style="background: url(images/boxtop.gif);"><img src="images/span.jpg" style="width: 397px; height: 20px; float: left" alt=""></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="vertical-align: top; width: 152px; background: url(images/tileleft.gif)">
|
||||
<div class="leftMenu">
|
||||
<script src="menu.js"></script>
|
||||
</div>
|
||||
</td>
|
||||
<td class="mainContent">
|
||||
<p>
|
||||
|
||||
The Articulated Figure (AF) editor allows you to change various
|
||||
properties of the articulated figures, more commonly known as
|
||||
rag dolls.
|
||||
|
||||
<div class="subsection">The 'View' Tab</div>
|
||||
|
||||
The view tab deals with how your current test model shows up in
|
||||
the world. The items on this tab are not saved when the AF is
|
||||
saved, they are simply to aid in development.
|
||||
|
||||
<div class="subsection">The 'Properties' Tab</div>
|
||||
|
||||
<img src="editor_af_b.png" align="right">
|
||||
|
||||
The properties tab sets some generic properties that apply to the
|
||||
entire object as a whole.
|
||||
|
||||
<div class="subsection">The 'Bodies' Tab</div>
|
||||
|
||||
<img src="editor_af_c.png" align="right">
|
||||
|
||||
The bodies tab sets up the properties for each body in the AF. The
|
||||
term 'body' here means a single moveable piece, such as an arm or a
|
||||
foot. You set up the size, shape, mass, etc for each body on this tab.
|
||||
|
||||
<div class="subsection">The 'Constraints' Tab</div>
|
||||
|
||||
<img src="editor_af_d.png" align="right">
|
||||
|
||||
The constraints tab sets up the properties for joints between bodies.
|
||||
For example, you can set up the elbow joint so it can't go beyond a
|
||||
certain angle (and thus prevent it from folding backwards).
|
||||
|
||||
<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan=2 bgcolor="#CCCCCC"><img src="images/span2.gif" style="width: 397px; height: 8px; float: left;"></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<table border=0 cellpadding=0 cellspacing=0 width=770>
|
||||
<tr>
|
||||
<td align=left class="legalese">Copyright © 2004 <a href="http://www.idsoftware.com">id software</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
</body>
|
||||
</html>
|
BIN
doom3/editor_af_b.png
Normal file
After Width: | Height: | Size: 47 KiB |
BIN
doom3/editor_af_c.png
Normal file
After Width: | Height: | Size: 56 KiB |
BIN
doom3/editor_af_d.png
Normal file
After Width: | Height: | Size: 48 KiB |
162
doom3/fx.php
Normal file
|
@ -0,0 +1,162 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>id.sdk [FX]</title>
|
||||
<LINK REL="stylesheet" HREF="style.css">
|
||||
</HEAD>
|
||||
|
||||
|
||||
<BODY marginwidth="0" marginheight="0" topmargin="0" leftmargin="0">
|
||||
|
||||
<table border=0 cellpadding=0 cellspacing=0 style="width: 100%; height: 99px">
|
||||
<tr>
|
||||
<td style="width: 171px"><img src="images/doom.jpg" style="width: 171px; height: 99px" alt=""></td>
|
||||
<td style="background: url(images/tile.gif)">
|
||||
<table border=0 cellpadding=0 cellspacing=0 width=600>
|
||||
<tr>
|
||||
<td style="height: 19px; background: url(images/sdk.gif) no-repeat"></td>
|
||||
<td rowspan=4 align=right><img src="images/id.gif" style="width: 42px; height: 99px" alt=""></td>
|
||||
</tr>
|
||||
<tr><td style="height: 29px; background: url(images/top.jpg) no-repeat"></td></tr>
|
||||
<tr><td style="height: 27px; background: url(images/middle.gif)" class="title"> Making DOOM 3 Mods : FX</td></tr>
|
||||
<tr><td style="height: 24px; background: url(images/bottom.jpg) no-repeat"></td></tr>
|
||||
</table>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<table border=0 cellpadding=0 cellspacing=0 style="width: 770px">
|
||||
<tr>
|
||||
<td colspan=2 style="background: url(images/boxtop.gif);"><img src="images/span.jpg" style="width: 397px; height: 20px; float: left" alt=""></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="vertical-align: top; width: 152px; background: url(images/tileleft.gif)">
|
||||
<div class="leftMenu">
|
||||
<script src="menu.js"></script>
|
||||
</div>
|
||||
</td>
|
||||
<td class="mainContent">
|
||||
<p>
|
||||
FX decls, are relatively easy to write by hand. The hard part about fx
|
||||
files is trying to explain just what they are and how they are used. The simple
|
||||
way to think of them is as particle spawners (which is why they are listed under
|
||||
particles), but they can actually do quite a bit more. Robert originaly wrote
|
||||
the FX system because he needed a way to easily sequence special effects, mostly
|
||||
for the 'spawn in' effect. There is nothing that you can do with the FX system
|
||||
that can't be done some other way, but FX decls tend to execute faster, and tend
|
||||
to be easier to create.
|
||||
|
||||
<p>
|
||||
An FX decl is made up of one or more FX Actions. The different types of FX Actions are:
|
||||
<ul>
|
||||
<li>Spawn or modify a Light
|
||||
<li>Spawn a particle, model, or entity
|
||||
<li>Start a sound
|
||||
<li>Drop a decal
|
||||
<li>Shake the Player
|
||||
<li>Launch a projectile
|
||||
</ul>
|
||||
|
||||
When an effect starts, it will start all the FX actions after the specified delay. So
|
||||
you could spawn a blue particle immediately, start a sound after half a second,
|
||||
spawn a light after a second, spawn some more particles after 3 seconds, and fade
|
||||
out the light after 4 seconds. Which is exactly what this file does:
|
||||
|
||||
<pre class="code">
|
||||
fx fx/example {
|
||||
{
|
||||
delay 0
|
||||
duration 1.0
|
||||
particle "blue.prt"
|
||||
}
|
||||
{
|
||||
delay 0.5
|
||||
restart 0
|
||||
duration 1.0
|
||||
sound "randomsound"
|
||||
}
|
||||
{
|
||||
delay 1.0
|
||||
restart 0
|
||||
duration 5.0
|
||||
name "somelight"
|
||||
light "lights/somelight", 2, 2, 2, 500
|
||||
fadeIn 1
|
||||
}
|
||||
{
|
||||
delay 3.0
|
||||
restart 0
|
||||
duration 0.1
|
||||
particle "someparticle.prt"
|
||||
}
|
||||
{
|
||||
delay 4.0
|
||||
restart 0
|
||||
duration 5.0
|
||||
useLight "somelight"
|
||||
fadeOut 1
|
||||
}
|
||||
}
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
All effects are attached to an entity, so anything it creates (lights, particles,
|
||||
sounds, etc) start at the origin of the entity (plus whatever offset is defined).
|
||||
It's is possible to instead attach the effect to a particular joint with the
|
||||
"bindto" keyword. This should be in the "global" section outside any FX actions.
|
||||
See "skulltrail.fx" for an example.
|
||||
|
||||
<p>
|
||||
The most complicated set of effects are the ones that happen when a monster spawns
|
||||
in. That complex sequence with the lightning and sounds and lights is all done
|
||||
with fx declarations. The code simply says "create a spawn effect here." The
|
||||
specific fx that it uses is in the entityDef for the monster, and the code to
|
||||
spawn it is in monster_base.script, somewhere around line 480.
|
||||
|
||||
<p>
|
||||
<b>FX decl keywords</b>
|
||||
<table class="datatable">
|
||||
<tr><td>name <string></td><td>The name of this action</td>
|
||||
<tr><td>delay <time></td><td>How long (in seconds) after starting the effect before this action happens</td>
|
||||
<tr><td>shake <time> <amplitude> <distance> <falloff> <impulse></td><td>Shake the player around a bit. Take a look at hkwalk.fx for a good example of this.</td>
|
||||
<tr><td>ignoreMaster</td><td>Don't shake the entity this effect is attached to</td>
|
||||
<tr><td>random <min>, <max></td><td>A random time added to the delay.</td>
|
||||
<tr><td>fire <sibling></td><td>Causes the sibling action to happen when this action does. This is a way of synching two random actions. See smallsparks.fx</td>
|
||||
<tr><td>duration <time></td><td>How long the action lasts before it is killed or restarted</td>
|
||||
<tr><td>restart <bool></td><td>Set to 1 if the action starts again after the 'duration' has run out</td>
|
||||
<tr><td>fadeIn <time></td><td>Fade in the RGB of the light or model over <time> seconds</td>
|
||||
<tr><td>fadeOut <time></td><td>Fade out the light/model. Ignored if fadeIn is set, you can use 2 seperate actions (tied together with uselight) if you want a light to fade in and out.</td>
|
||||
<tr><td>offset <x>, <y>, <z></td><td>Offset from the origin of the entity (or bind point) this action is located at</td>
|
||||
<tr><td>axis <x>, <y>, <z></td><td>Axis of the model, mutually exclusive with angle</td>
|
||||
<tr><td>angle <pitch>, <yaw>, <roll></td><td>Alternate way of setting the axis of the model</td>
|
||||
<tr><td>rotate <angle></td><td>Not used</td>
|
||||
<tr><td>light <material>, <red>, <green>, <blue>, <radius></td><td>Create a light</td>
|
||||
<tr><td>noshadows</td><td>The light in this effect doesn't cast shadows</td>
|
||||
<tr><td>attachlight <light></td><td>Attach to external light (a light not defined in the effect) for fading. This is what causes all the lights to fade in/out in alphalabs 2</td>
|
||||
<tr><td>attachentity <entity></td><td>Attach to an external entity. Not actually used in Doom 3</td>
|
||||
<tr><td>launch <entity></td><td>Launches a projectile. Not actually used in Doom 3, but I suppose it could be used to create a neat mario jumping lava effect.</td>
|
||||
<tr><td>uselight <sibling></td><td>Modify the light values in a sibling action. Can be used to fade out a light that faded in earlier.</td>
|
||||
<tr><td>useModel <model></td><td>Modify the model in a sibling action. Can be used to fade out a particle in a sibling.</td>
|
||||
<tr><td>model <model></td><td>Creates (or fades in) a model</td>
|
||||
<tr><td>particle <model></td><td>Same as model</td>
|
||||
<tr><td>decal <material></td><td>Applies the specified decal to the ground (and anything else in the area)</td>
|
||||
<tr><td>size <int></td><td>Size of the decal</td>
|
||||
<tr><td>trackorigin <bool></td><td>Move around with the entity (vs stationary after spawning)</td>
|
||||
<tr><td>particleTrackVelocity</td><td>Not used</td>
|
||||
<tr><td>sound <sndshader></td><td>Start a sound (on any channel)</td>
|
||||
</table>
|
||||
|
||||
<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan=2 bgcolor="#CCCCCC"><img src="images/span2.gif" style="width: 397px; height: 8px; float: left;"></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<table border=0 cellpadding=0 cellspacing=0 width=770>
|
||||
<tr>
|
||||
<td align=left class="legalese">Copyright © 2004 <a href="http://www.idsoftware.com">id software</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
</body>
|
||||
</html>
|
BIN
doom3/images/bottom.jpg
Normal file
After Width: | Height: | Size: 14 KiB |
BIN
doom3/images/boxleft.gif
Normal file
After Width: | Height: | Size: 197 B |
BIN
doom3/images/boxtop.gif
Normal file
After Width: | Height: | Size: 231 B |
BIN
doom3/images/doom.jpg
Normal file
After Width: | Height: | Size: 31 KiB |
BIN
doom3/images/id.gif
Normal file
After Width: | Height: | Size: 1.2 KiB |
BIN
doom3/images/middle.gif
Normal file
After Width: | Height: | Size: 3.6 KiB |
BIN
doom3/images/sdk.gif
Normal file
After Width: | Height: | Size: 1.4 KiB |
BIN
doom3/images/span.jpg
Normal file
After Width: | Height: | Size: 15 KiB |
BIN
doom3/images/span2.gif
Normal file
After Width: | Height: | Size: 1.4 KiB |
BIN
doom3/images/tile.gif
Normal file
After Width: | Height: | Size: 1.4 KiB |
BIN
doom3/images/tileleft.gif
Normal file
After Width: | Height: | Size: 5.9 KiB |
BIN
doom3/images/top.jpg
Normal file
After Width: | Height: | Size: 16 KiB |
1827
doom3/index.html
Normal file
78
doom3/menu.js
Normal file
|
@ -0,0 +1,78 @@
|
|||
|
||||
var a = {
|
||||
"":"Home",
|
||||
"downloads":"Downloads",
|
||||
"contact":"Contact",
|
||||
|
||||
"__basics__":"-",
|
||||
"basics":"Mod Basics",
|
||||
"packfiles":"Pack Files",
|
||||
"declfiles":"Decl Files",
|
||||
"editor_decl":"Decl Editor",
|
||||
"commands":"Commands",
|
||||
"cvars":"Cvars",
|
||||
|
||||
"__code__":"-",
|
||||
"code":"The Code",
|
||||
|
||||
"__models__":"-",
|
||||
"modelexport":"Exporting Models",
|
||||
"models":"Model Decls",
|
||||
"skins":"Skins",
|
||||
|
||||
"__lighting__":"-",
|
||||
"lighting":"Lighting",
|
||||
"bumpmaps":"Bump Maps",
|
||||
"materials":"Materials",
|
||||
|
||||
"__afs__":"-",
|
||||
"afs":"Articulated Figures",
|
||||
"editor_af":"AF Editor",
|
||||
"walkik":"Walk IK",
|
||||
|
||||
"__sounds__":"-",
|
||||
"sounds":"Sounds",
|
||||
"editor_sound":"Sound Editor",
|
||||
|
||||
"__particles__":"-",
|
||||
"particles":"Particles",
|
||||
"editor_particle":"Particle Editor",
|
||||
"fx":"FX",
|
||||
|
||||
"__guis__":"-",
|
||||
"guis":"GUIs",
|
||||
"editor_gui":"GUI Editor",
|
||||
|
||||
"__maps__":"-",
|
||||
"maps":"Maps",
|
||||
"editor":"DOOMEdit",
|
||||
"editor_keys":"Editor Keys",
|
||||
"editor_light":"Light Editor",
|
||||
"entitydefs":"EntityDefs",
|
||||
"mapdefs":"MapDefs",
|
||||
|
||||
"__pdas__":"-",
|
||||
"pdas":"PDAs",
|
||||
"editor_pda":"PDA Editor",
|
||||
|
||||
"__script__":"-",
|
||||
"script":"Scripts",
|
||||
"script_map":"Map Scripts",
|
||||
"script_weapon":"Weapon Scripts",
|
||||
"script_ai":"AI Scripts",
|
||||
"editor_script":"Script Editor"
|
||||
}
|
||||
|
||||
for ( var i in a ) {
|
||||
if ( a[i] == "-" ) {
|
||||
document.write( "<br>" );
|
||||
continue;
|
||||
}
|
||||
if ( document.location.pathname.indexOf("/" + i + ".php") >= 0 || ( i == "" && document.location.pathname.indexOf(".php") == -1 ) ) {
|
||||
document.write( "<font color='#FFCC66'><b>" + a[i] + "</b></font><br>");
|
||||
} else if ( i == "" ) {
|
||||
document.write( " <a href=\"/\">" + a[i] + "</a><br>");
|
||||
} else {
|
||||
document.write( " <a href=\"" + i + ".php\">" + a[i] + "</a><br>");
|
||||
}
|
||||
}
|
196
doom3/modelexport.php
Normal file
|
@ -0,0 +1,196 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>id.sdk [Model Exporting]</title>
|
||||
<LINK REL="stylesheet" HREF="style.css">
|
||||
</HEAD>
|
||||
|
||||
|
||||
<BODY marginwidth="0" marginheight="0" topmargin="0" leftmargin="0">
|
||||
|
||||
<table border=0 cellpadding=0 cellspacing=0 style="width: 100%; height: 99px">
|
||||
<tr>
|
||||
<td style="width: 171px"><img src="images/doom.jpg" style="width: 171px; height: 99px" alt=""></td>
|
||||
<td style="background: url(images/tile.gif)">
|
||||
<table border=0 cellpadding=0 cellspacing=0 width=600>
|
||||
<tr>
|
||||
<td style="height: 19px; background: url(images/sdk.gif) no-repeat"></td>
|
||||
<td rowspan=4 align=right><img src="images/id.gif" style="width: 42px; height: 99px" alt=""></td>
|
||||
</tr>
|
||||
<tr><td style="height: 29px; background: url(images/top.jpg) no-repeat"></td></tr>
|
||||
<tr><td style="height: 27px; background: url(images/middle.gif)" class="title"> Making DOOM 3 Mods : Model Exporting</td></tr>
|
||||
<tr><td style="height: 24px; background: url(images/bottom.jpg) no-repeat"></td></tr>
|
||||
</table>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<table border=0 cellpadding=0 cellspacing=0 style="width: 770px">
|
||||
<tr>
|
||||
<td colspan=2 style="background: url(images/boxtop.gif);"><img src="images/span.jpg" style="width: 397px; height: 20px; float: left" alt=""></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="vertical-align: top; width: 152px; background: url(images/tileleft.gif)">
|
||||
<div class="leftMenu">
|
||||
<script src="menu.js"></script>
|
||||
</div>
|
||||
</td>
|
||||
<td class="mainContent">
|
||||
<div class="subsection">Static Models</div>
|
||||
|
||||
Getting a static model (like a trash can or a shrubery) in to the game
|
||||
is really easy. Doom 3 reads lwo (lightwave) and ase (3dsmax) files
|
||||
natively so you simply save out the model in one of those two formats
|
||||
and you can use it in the game.
|
||||
|
||||
<p>
|
||||
<strong>
|
||||
The material that is used in game is the diffuse texture specified in the model.
|
||||
</strong>
|
||||
|
||||
<p>
|
||||
The relative material name is determined by searching for "base" in the texture path.
|
||||
For example, if the texture specified in the .ase is
|
||||
"<samp>C:\Doom\base\textures\base_trim\red1.tga</samp>"
|
||||
Then it would use the material named "<samp>textures\base_trim\red1</samp>"
|
||||
|
||||
<p>
|
||||
If you are running a custom mod, then it will look for the mod name if it can't find
|
||||
"base" so "<samp>C:\Doom\jailbreak\textures\base_trim\red1.tga</samp>" would also work
|
||||
in the jailbreak mod.
|
||||
|
||||
<p>
|
||||
<strong>The path cannot have spaces in it.</strong> Doom 3 should be installed in
|
||||
"<samp>C:\Doom\</samp>" or some other place without spaces. If Doom 3 is in the
|
||||
default location of "<samp>C:\Program Files\Doom 3\</samp>" it will not work because
|
||||
of the space in "Program Files" and the space in "Doom 3"
|
||||
|
||||
<p>
|
||||
Generally speaking, as long as you keep all your assets in the final
|
||||
directory that it will be in, then you should just be able to use it
|
||||
in game without having to touch anything. Problems tend to arise if
|
||||
you edit your assets in one directory, then move them in to the base
|
||||
directory or your mod directory after you export.
|
||||
|
||||
<p>
|
||||
If you are working on a new chair, you should work
|
||||
on it in<br>
|
||||
<samp>C:\Doom3\mymod\models\mapobjects\chairs\mychair\</samp><br>
|
||||
rather than working on it in<br>
|
||||
<samp>C:\My Stuff\Models\Cool Models\Stuff For My Mod\Chair</samp><br>
|
||||
then moving to the proper directory after it's been exported.
|
||||
|
||||
<p>
|
||||
<b>Spaces in file names are bad.</b>
|
||||
|
||||
<p>
|
||||
For more information on exporting from 3dstudio max, <a href="modelexport_3dsmax.php">click here</a>
|
||||
|
||||
<div class="subsection">Animated Models</div>
|
||||
|
||||
Animated models are quite a bit more complex. The only animation system supported in
|
||||
Doom 3 is skeletal (no vertex animation like in Quake), and the only file format supported
|
||||
is .mb (Maya binary). The files have to be processed using a built in tool to convert
|
||||
the Maya files to .md5mesh and .md5anim files.
|
||||
|
||||
<p>
|
||||
<b>Note for 3dstudio max</b>: Although Doom3 does not support animated models from max
|
||||
"out of the box", the people over at <a href="http://www.Doom3World.org">Doom3World</a>
|
||||
wrote some nice importers and exporters, which you can find <a href="http://www.doom3world.org/phpbb2/viewtopic.php?t=5474">here</a>.
|
||||
|
||||
<p>
|
||||
This built in tool is 'exportModels'. By default, it will export any models that have
|
||||
been modified since the last time the command was run, but you can pass it a .def file
|
||||
and it will only export the models defined in that def file. You can speed up the exportModels
|
||||
command by using the 'g_exportMask' cvar and specifying some magic string after the export
|
||||
declaration (as we will see later). Setting "g_exportMask fred" will only export fred's
|
||||
animations, skipping all the others.
|
||||
|
||||
<p>
|
||||
You must have Maya installed on the machine that you are exporting on otherwise it won't do anything.
|
||||
|
||||
<p>
|
||||
The syntax for an export section looks complex at first, but is actually quite simple when
|
||||
you break it down into the different parts. Unlike some other declarations, the commands
|
||||
in an export block are executed as they are encountered. This means the order DOES matter.
|
||||
|
||||
<p>
|
||||
There are two systems at work when you export a file. The first is the actual exporter, this
|
||||
is the piece that does all the work. The second is what I'm going to call the 'parser'. This
|
||||
piece reads the export sections and passes the commands to the exporter for actual exportation.
|
||||
|
||||
<p>
|
||||
The parser only has 5 commands, and they are really very simple:
|
||||
|
||||
<p>
|
||||
<table class="datatable">
|
||||
<tr><th>Command</th><th>Description</th>
|
||||
<tr><td class="nobr">options [options]</td><td>
|
||||
Stores default options that will be used for all future export actions. Note that an options
|
||||
command will override any previously set options.
|
||||
</td>
|
||||
<tr><td class="nobr">addoptions [options]</td><td>
|
||||
Adds a default option to the current set of default options. This is very similar to the
|
||||
options command, but it appends rather than overwriting the current options.
|
||||
</td>
|
||||
<tr><td class="nobr">mesh <mb file> [options]</td><td rowspan="3">
|
||||
Exports a object from a .mb file. The options specified here will be appended to
|
||||
the options specified previously with "options" or "addoptions" commands.
|
||||
</td>
|
||||
<tr><td class="nobr">anim <mb file> [options]</td>
|
||||
<tr><td class="nobr">camera <mb file> [options]</td>
|
||||
</table>
|
||||
|
||||
<p>
|
||||
Here is a list of all the options along with a brief description of what they do:
|
||||
|
||||
<p>
|
||||
<table class="datatable">
|
||||
<tr><th>Option</th><th>Description</th>
|
||||
<tr><td class="nobr">-force</td><td>Ignored</td>
|
||||
<tr><td class="nobr">-game</td><td>Specify the mod name, which is where the relative paths are defined from. This should get set automatically in 1.2</td>
|
||||
<tr><td class="nobr">-rename [joint name] [new name]</td><td>Rename a joint</td>
|
||||
<tr><td class="nobr">-prefix [joint prefix]</td><td>
|
||||
If you have multiple characters/objects in your scene, you can give them each their own prefix
|
||||
so the exporter can distinguish which goes to which. Example: ZSEC_ IMP_ ENV_ </td>
|
||||
<tr><td class="nobr">-parent [joint name] [new parent]</td><td>Reparent a joint</td>
|
||||
<tr><td class="nobr">-sourcedir [directory]</td><td>Tell exporter where to get files from</td>
|
||||
<tr><td class="nobr">-destdir [directory]</td><td>Tell exporter where to put files after export</td>
|
||||
<tr><td class="nobr">-dest [filename]</td><td>Give a new name to the file you are exporting. Default will be same name as the maya file.</td>
|
||||
<tr><td class="nobr">-range [start frame] [end frame]</td><td>Frame range for what you would like to export Example: <samp>-range 1 10</samp></td>
|
||||
<tr><td class="nobr">-cycleStart [first frame of cycle]</td><td>
|
||||
Shift the cycle to start on a different frame. Example: frame 1 has left foot forward and frame 10 has right foot
|
||||
forward. So if you would like your cycle to start with right foot forward do <samp>-cycleStart 10</samp> and it will shift the cycle</td>
|
||||
<tr><td class="nobr">-scale [scale amount]</td><td>Scale up or down your character during export. Example: <samp>-scale 2</samp> will double the size of the character. Scaled up from the origin.</td>
|
||||
<tr><td class="nobr">-align [joint name]</td><td>Will align your animation to a certain bone.</td>
|
||||
<tr><td class="nobr">-rotate [yaw]</td><td>Allow you to manually rotate your animation. Example: <samp>-rotate 90</samp></td>
|
||||
<tr><td class="nobr">-nomesh</td><td></td>
|
||||
<tr><td class="nobr">-clearorigin</td><td></td>
|
||||
<tr><td class="nobr">-clearoriginaxis</td><td></td>
|
||||
<tr><td class="nobr">-ignorescale</td><td>Ignore any scales you may have on some bones.</td>
|
||||
<tr><td class="nobr">-xyzprecision [precision]</td><td>Will take even tiny movements (translations) into
|
||||
consideration if you make this # lower. Default will try and compress down the animations getting rid of tiny movements.</td>
|
||||
<tr><td class="nobr">-quatprecision [precision]</td><td>Will take even tiny movements (rotations) into
|
||||
consideration if you make this # lower. Default will try and compress down the animations getting rid of tiny movements.</td>
|
||||
<tr><td class="nobr">-jointthreshold [min joint weight]</td><td></td>
|
||||
<tr><td class="nobr">-skipmesh [name of mesh]</td><td>Allows you to skip certain models during export (can only be used by itself)</td>
|
||||
<tr><td class="nobr">-keepmesh [name of mesh]</td><td>Allows you to keep only a certain model during export (can only be used by itself)</td>
|
||||
<tr><td class="nobr">-jointgroup [group name]<br>[joint1] [joint2]...[joint n]</td><td></td>
|
||||
<tr><td class="nobr">-group [group name]</td><td>Add the list of groups to export (these don't affect the hierarchy)</td>
|
||||
<tr><td class="nobr">-keep [joint name]</td><td>Add joints that are kept whether they're used by a mesh or not</td>
|
||||
</table>
|
||||
|
||||
<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan=2 bgcolor="#CCCCCC"><img src="images/span2.gif" style="width: 397px; height: 8px; float: left;"></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<table border=0 cellpadding=0 cellspacing=0 width=770>
|
||||
<tr>
|
||||
<td align=left class="legalese">Copyright © 2004 <a href="http://www.idsoftware.com">id software</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
</body>
|
||||
</html>
|
116
doom3/modelexport_3dsmax.php
Normal file
|
@ -0,0 +1,116 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>id.sdk [Model Exporting from 3dstudio max]</title>
|
||||
<LINK REL="stylesheet" HREF="style.css">
|
||||
</HEAD>
|
||||
|
||||
|
||||
<BODY marginwidth="0" marginheight="0" topmargin="0" leftmargin="0">
|
||||
|
||||
<table border=0 cellpadding=0 cellspacing=0 style="width: 100%; height: 99px">
|
||||
<tr>
|
||||
<td style="width: 171px"><img src="images/doom.jpg" style="width: 171px; height: 99px" alt=""></td>
|
||||
<td style="background: url(images/tile.gif)">
|
||||
<table border=0 cellpadding=0 cellspacing=0 width=600>
|
||||
<tr>
|
||||
<td style="height: 19px; background: url(images/sdk.gif) no-repeat"></td>
|
||||
<td rowspan=4 align=right><img src="images/id.gif" style="width: 42px; height: 99px" alt=""></td>
|
||||
</tr>
|
||||
<tr><td style="height: 29px; background: url(images/top.jpg) no-repeat"></td></tr>
|
||||
<tr><td style="height: 27px; background: url(images/middle.gif)" class="title"> Making DOOM 3 Mods : Model Exporting from 3dstudio max</td></tr>
|
||||
<tr><td style="height: 24px; background: url(images/bottom.jpg) no-repeat"></td></tr>
|
||||
</table>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<table border=0 cellpadding=0 cellspacing=0 style="width: 770px">
|
||||
<tr>
|
||||
<td colspan=2 style="background: url(images/boxtop.gif);"><img src="images/span.jpg" style="width: 397px; height: 20px; float: left" alt=""></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="vertical-align: top; width: 152px; background: url(images/tileleft.gif)">
|
||||
<div class="leftMenu">
|
||||
<script src="menu.js"></script>
|
||||
</div>
|
||||
</td>
|
||||
<td class="mainContent">
|
||||
I'm going to go through the steps required to export a single box, but the steps
|
||||
are the exact same for more complicated geometry.
|
||||
|
||||
<p>
|
||||
<b>1: Install Doom in C:\Doom3\</b><br>
|
||||
It doesn't actually have to be there, but it has to be somewhere without any spaces.
|
||||
|
||||
<p>
|
||||
<b>2: Make a box</b><br>
|
||||
Save it as C:\Doom3\base\models\testbox\testbox.max
|
||||
|
||||
<p>
|
||||
<b>3: Make diffuse, normal, and specular textures</b><br>
|
||||
Or download them from <a href="downloads/testbox_textures.zip">here</a><br>
|
||||
Save them as:<br>
|
||||
<samp>
|
||||
C:\Doom3\base\models\testbox\testbox.tga<br>
|
||||
C:\Doom3\base\models\testbox\testbox_local.tga<br>
|
||||
C:\Doom3\base\models\testbox\testbox_s.tga<br>
|
||||
</samp>
|
||||
|
||||
<p>
|
||||
<b>4: Create a new material in 3dsmax</b><br>
|
||||
Specify those textures as the diffuse, normal, and specular maps.<br>
|
||||
Apply that material to the box.
|
||||
|
||||
<p>
|
||||
<b>5: Export the ASE</b><br>
|
||||
Click File->Export<br>
|
||||
Select ASE<br>
|
||||
Save it as C:\Doom3\base\models\testbox\testbox.ase<br>
|
||||
Be sure these options are checked:<br>
|
||||
TODO...<br>
|
||||
|
||||
<p>
|
||||
<b>6: Create the material</b><br>
|
||||
Open notepad, type the following:
|
||||
<pre class="code">
|
||||
models\testbox\testbox
|
||||
{
|
||||
diffusemap models\testbox\testbox.tga
|
||||
bumpmap models\testbox\testbox_local.tga
|
||||
specularmap models\testbox\testbox_s.tga
|
||||
}
|
||||
</pre>
|
||||
Save the file as C:\Doom3\base\materials\testbox.mtr
|
||||
|
||||
<p>
|
||||
<b>7: Test it in Doom3</b><br>
|
||||
Launch Doom3<br>
|
||||
Drop the console (<kbd>Ctrl+Alt+~</kbd>)<br>
|
||||
Type: <samp>map testmaps/test_box</samp><br>
|
||||
Type: <samp>testmodel models/testbox/testbox.ase</samp><br>
|
||||
|
||||
<p>
|
||||
If everything worked right, you should see your box right in front of you all
|
||||
lit properly with bumps and specular highlights and such. If not, check the
|
||||
console for red or yellow text, it should explain why it didn't load.
|
||||
|
||||
<p>
|
||||
If you want to import this object into a map, right-click the 2d grid in DOOMEdit,
|
||||
select "New Model..." and select the model. Sometimes it doesn't show up right
|
||||
when you do that, the fix is to his space bar to copy it, then delete the original.
|
||||
|
||||
<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan=2 bgcolor="#CCCCCC"><img src="images/span2.gif" style="width: 397px; height: 8px; float: left;"></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<table border=0 cellpadding=0 cellspacing=0 width=770>
|
||||
<tr>
|
||||
<td align=left class="legalese">Copyright © 2004 <a href="http://www.idsoftware.com">id software</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
</body>
|
||||
</html>
|
135
doom3/style.css
Normal file
|
@ -0,0 +1,135 @@
|
|||
|
||||
/* Header and Footer Styles */
|
||||
|
||||
body {
|
||||
background-color: #000;
|
||||
}
|
||||
a {
|
||||
color: black;
|
||||
}
|
||||
a:visited {
|
||||
color: black;
|
||||
}
|
||||
.leftMenu {
|
||||
vertical-align: top;
|
||||
text-align: left;
|
||||
padding: 5px;
|
||||
font-family: Arial;
|
||||
font-size: 10pt;
|
||||
}
|
||||
.leftMenu a {
|
||||
color: #A8A38E;
|
||||
text-decoration: none;
|
||||
}
|
||||
.leftMenu a:visited {
|
||||
color: #A8A38E;
|
||||
}
|
||||
.leftMenu a:hover {
|
||||
color: #FFFFFF;
|
||||
}
|
||||
|
||||
.title {
|
||||
font-family: arial;
|
||||
font-size: 10pt;
|
||||
font-weight: bold;
|
||||
color: #FFFFFF;
|
||||
text-transform: uppercase;
|
||||
vertical-align: middle;
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
.mainContent {
|
||||
padding: 0px 5px 0px 10px;
|
||||
background: #CCC url("images/boxleft.gif") repeat-y;
|
||||
vertical-align: top;
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
.legalese {
|
||||
color: #AAA;
|
||||
font-size: 8pt;
|
||||
}
|
||||
.legalese a {
|
||||
color: #AAA;
|
||||
}
|
||||
|
||||
|
||||
/* Page Styles */
|
||||
|
||||
.subsection {
|
||||
clear: both;
|
||||
background-color: #666;
|
||||
color: #FFF;
|
||||
padding: 0px;
|
||||
padding-left: 10px;
|
||||
margin-top: 1em;
|
||||
margin-bottom: 1em;
|
||||
font-size: 12pt;
|
||||
font-weight: bold;
|
||||
font-variant: small-caps;
|
||||
}
|
||||
.code {
|
||||
border: 1px groove;
|
||||
background-color: #EEE;
|
||||
font-size: 10pt;
|
||||
font-family: monospace;
|
||||
}
|
||||
samp {
|
||||
font-size: 10pt;
|
||||
font-family: monospace;
|
||||
}
|
||||
code {
|
||||
background-color: #EEE;
|
||||
font-size: 10pt;
|
||||
font-family: monospace;
|
||||
white-space: pre;
|
||||
}
|
||||
|
||||
.newspost {
|
||||
border: solid 1px black;
|
||||
border-spacing: 0px;
|
||||
border-collapse: collapse;
|
||||
width: 100%;
|
||||
}
|
||||
.newspost td {
|
||||
vertical-align: top;
|
||||
border: solid 1px black;
|
||||
margin: 2px;
|
||||
padding: 10px 4px;
|
||||
}
|
||||
.newspost th {
|
||||
text-align: left;
|
||||
padding: 2px 4px 2px 20px;
|
||||
}
|
||||
.newspost td.date {
|
||||
background-color: #CCC;
|
||||
width: 15%;
|
||||
text-align: center;
|
||||
padding: 2px 4px;
|
||||
}
|
||||
.newspost td.name {
|
||||
background-color: #CCC;
|
||||
width: 15%;
|
||||
text-align: center;
|
||||
padding: 2px 4px;
|
||||
}
|
||||
|
||||
.datatable {
|
||||
border: solid 1px black;
|
||||
border-spacing: 0px;
|
||||
border-collapse: collapse;
|
||||
}
|
||||
.datatable td {
|
||||
vertical-align: top;
|
||||
border: solid 1px black;
|
||||
margin: 2px;
|
||||
padding: 2px;
|
||||
}
|
||||
.datatable th {
|
||||
valign: top;
|
||||
margin: 2px;
|
||||
padding: 2px;
|
||||
}
|
||||
.nobr {
|
||||
white-space: nowrap;
|
||||
}
|
158
doom3/visportals.php
Normal file
|
@ -0,0 +1,158 @@
|
|||
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
||||
<HTML>
|
||||
<HEAD>
|
||||
<TITLE>id.sdk [Vis Portals]</title>
|
||||
<LINK REL="stylesheet" HREF="style.css">
|
||||
</HEAD>
|
||||
|
||||
|
||||
<BODY marginwidth="0" marginheight="0" topmargin="0" leftmargin="0">
|
||||
|
||||
<table border=0 cellpadding=0 cellspacing=0 style="width: 100%; height: 99px">
|
||||
<tr>
|
||||
<td style="width: 171px"><img src="images/doom.jpg" style="width: 171px; height: 99px" alt=""></td>
|
||||
<td style="background: url(images/tile.gif)">
|
||||
<table border=0 cellpadding=0 cellspacing=0 width=600>
|
||||
<tr>
|
||||
<td style="height: 19px; background: url(images/sdk.gif) no-repeat"></td>
|
||||
<td rowspan=4 align=right><img src="images/id.gif" style="width: 42px; height: 99px" alt=""></td>
|
||||
</tr>
|
||||
<tr><td style="height: 29px; background: url(images/top.jpg) no-repeat"></td></tr>
|
||||
<tr><td style="height: 27px; background: url(images/middle.gif)" class="title"> Making DOOM 3 Mods : Vis Portals</td></tr>
|
||||
<tr><td style="height: 24px; background: url(images/bottom.jpg) no-repeat"></td></tr>
|
||||
</table>
|
||||
</td>
|
||||
</tr>
|
||||
</table>
|
||||
<table border=0 cellpadding=0 cellspacing=0 style="width: 770px">
|
||||
<tr>
|
||||
<td colspan=2 style="background: url(images/boxtop.gif);"><img src="images/span.jpg" style="width: 397px; height: 20px; float: left" alt=""></td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td style="vertical-align: top; width: 152px; background: url(images/tileleft.gif)">
|
||||
<div class="leftMenu">
|
||||
<script src="menu.js"></script>
|
||||
</div>
|
||||
</td>
|
||||
<td class="mainContent">
|
||||
Here is a simple donut map 8 portals in it. When this level is compiled, it creates 8 areas. Those areas are numbered 1-8 in the screenshot below.
|
||||
|
||||
<p>
|
||||
<img src="visportals/pdas_2dedit.png">
|
||||
|
||||
<p>
|
||||
|
||||
When Doom 3 renders the level, it first renders the area the view is in then it flows through all visible portals
|
||||
rendering each area it encounters. In this example, it would render area 3, then it would render areas 2 and 5, then areas 1 and 8,
|
||||
then maybe areas 4 and 7.
|
||||
|
||||
<p>
|
||||
|
||||
If a level has no vis portals in it, there is only one area so the entire level is rendered every frame.
|
||||
|
||||
<p>
|
||||
|
||||
The renderer determines visibility between areas by doing unions of the screen space rectangles between the areas. The following
|
||||
in-game screenshots should make that statement a little easier to understand.
|
||||
|
||||
<p>
|
||||
|
||||
<img src="visportals/pdas_ingame_step1.png">
|
||||
<br>
|
||||
<img src="visportals/pdas_ingame_step2.png">
|
||||
<br>
|
||||
<img src="visportals/pdas_ingame_step3.png">
|
||||
<br>
|
||||
<img src="visportals/pdas_ingame_step4.png">
|
||||
|
||||
|
||||
<p>
|
||||
|
||||
<b>Walls</b>
|
||||
|
||||
<p>
|
||||
|
||||
Notice how the renderer only uses the portals for determining visibility, it does not use geometry at all. If you have a wall in between
|
||||
two portals, it will still render what's on the other side of the wall unless there is another portal in between to divide the room into
|
||||
two areas.
|
||||
|
||||
<p>
|
||||
|
||||
<img src="visportals/walls_dont_block1.png"><img src="visportals/walls_dont_block2.png">
|
||||
|
||||
<p>
|
||||
|
||||
<b>Doors</b>
|
||||
|
||||
<p>
|
||||
|
||||
If a vis portal is placed inside a door, the door will automatically close the portal when the door is closed. You can do the same
|
||||
thing manually through func_portal entities (these are handy for complex doors like airlocks).
|
||||
|
||||
<p>
|
||||
|
||||
<b>Batches</b>
|
||||
|
||||
<p>
|
||||
|
||||
|
||||
The downside to portals is that they create extra triangles and extra batches. Video cards are set up to handle a small number of batches
|
||||
with a large number of triangles per batch. All the triangles in a single area with the same texture are put into a batch. When you create
|
||||
a vis portal, it splits the geometry, and adds more batches. This is normally not a problem unless you have a lot of areas with only a hand
|
||||
full of triangles in them.
|
||||
|
||||
<p>
|
||||
|
||||
<b>Testing</b>
|
||||
|
||||
<p>
|
||||
|
||||
|
||||
To test the visibility in your own map, use the following cvars:
|
||||
<pre>
|
||||
r_showTris 2
|
||||
r_useScissor 0
|
||||
r_showPortals 1
|
||||
</pre>
|
||||
|
||||
<p>
|
||||
|
||||
<b>Scissors</b>
|
||||
|
||||
<p>
|
||||
|
||||
To further improve rendering speeds, the Doom 3 engine utilized scissors when rendering areas through a portal. These scissors prevent
|
||||
geometry outside the portal rectangle from being drawn by the video card. This is not a magic cure however, because the data is still
|
||||
being sent to the video card, it's just that the video card is ignoring it.
|
||||
|
||||
<p>
|
||||
If you do not set r_useScissor 0 then you will not see the full extents of what is being rendered. You will only see what the video card is
|
||||
actually drawing. Remember, just because your video card is throwing away the geometry doesn't mean it's free. Your CPU still has to waste
|
||||
time sending the data to the video card. This is a very slow process. You don't want your computer to waste time sending a lot of data to
|
||||
the graphics card just to have it thrown away.
|
||||
|
||||
<p>
|
||||
Here is the same scene with scissors enabled:
|
||||
<p>
|
||||
|
||||
<img src="visportals/pdas_ingame_scissors.png">
|
||||
|
||||
<p>
|
||||
|
||||
<b>Remember, always test your portals with scissors disabled!</b>
|
||||
|
||||
<br>
|
||||
</td>
|
||||
</tr>
|
||||
<tr>
|
||||
<td colspan=2 bgcolor="#CCCCCC"><img src="images/span2.gif" style="width: 397px; height: 8px; float: left;"></td>
|
||||
</tr>
|
||||
</table>
|
||||
|
||||
<table border=0 cellpadding=0 cellspacing=0 width=770>
|
||||
<tr>
|
||||
<td align=left class="legalese">Copyright © 2004 <a href="http://www.idsoftware.com">id software</a></td>
|
||||
</tr>
|
||||
</table>
|
||||
</body>
|
||||
</html>
|
BIN
doom3/visportals/pdas_2dedit.png
Normal file
After Width: | Height: | Size: 13 KiB |
BIN
doom3/visportals/pdas_ingame_scissors.png
Normal file
After Width: | Height: | Size: 242 KiB |
BIN
doom3/visportals/pdas_ingame_step1.png
Normal file
After Width: | Height: | Size: 186 KiB |
BIN
doom3/visportals/pdas_ingame_step2.png
Normal file
After Width: | Height: | Size: 246 KiB |
BIN
doom3/visportals/pdas_ingame_step3.png
Normal file
After Width: | Height: | Size: 246 KiB |
BIN
doom3/visportals/pdas_ingame_step4.png
Normal file
After Width: | Height: | Size: 247 KiB |
BIN
doom3/visportals/walls_dont_block1.png
Normal file
After Width: | Height: | Size: 5.3 KiB |
BIN
doom3/visportals/walls_dont_block2.png
Normal file
After Width: | Height: | Size: 5.7 KiB |
BIN
images/d3.gif
Normal file
After Width: | Height: | Size: 30 KiB |
BIN
images/q4.gif
Normal file
After Width: | Height: | Size: 30 KiB |
BIN
images/splashbottom.jpg
Normal file
After Width: | Height: | Size: 36 KiB |
BIN
images/splashleft.gif
Normal file
After Width: | Height: | Size: 3.5 KiB |
BIN
images/splashright.gif
Normal file
After Width: | Height: | Size: 4.2 KiB |
BIN
images/splashtop.jpg
Normal file
After Width: | Height: | Size: 33 KiB |
56
index.html
|
@ -1,50 +1,22 @@
|
|||
<html class=" izkfixau idc0_329"><head>
|
||||
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
|
||||
<link rel="stylesheet" type="text/css" href="idDevNet_files/banner-styles.css">
|
||||
<link rel="stylesheet" type="text/css" href="idDevNet_files/iconochive.css">
|
||||
|
||||
<html>
|
||||
<head>
|
||||
<title>idDevNet</title>
|
||||
</head><script src="idDevNet_files/inject.js"></script>
|
||||
<body topmargin="0" text="white" marginwidth="0" marginheight="0" leftmargin="0" bgcolor="black">
|
||||
</head>
|
||||
<body bgcolor="black" text="white" marginwidth="0" marginheight="0" topmargin="0" leftmargin="0">
|
||||
|
||||
<center>
|
||||
|
||||
<br>
|
||||
|
||||
<table width="812" cellspacing="0," cellpadding="0," border="0,">
|
||||
<tbody><tr><td colspan="4"><img src="idDevNet_files/splashtop.jpg" border="0"></td></tr>
|
||||
<tr><td><img src="idDevNet_files/splashleft.gif" border="0"></td>
|
||||
<td><img src="idDevNet_files/d3.gif" alt="DOOM3" border="0"></td>
|
||||
<td><img src="idDevNet_files/q4.gif" alt="QUAKE4" border="0"></td>
|
||||
<td><img src="idDevNet_files/splashright.gif" border="0"></td></tr>
|
||||
<tr><td colspan="4"><img src="idDevNet_files/splashbottom.jpg" border="0"></td></tr>
|
||||
</tbody></table>
|
||||
<br>
|
||||
<h2>Coming soonish - hopefully.</h2>
|
||||
|
||||
<table border=0, cellspacing=0, cellpadding=0, width=812>
|
||||
<tr><td colspan=4><img src="images/splashtop.jpg" border="0"></td></tr>
|
||||
<tr><td><img src="images/splashleft.gif" border="0"></td>
|
||||
<td><a href="/doom3/"><img src="images/d3.gif" border="0" alt="DOOM3"></a></td>
|
||||
<td><a href="/quake4/"><img src="images/q4.gif" border="0" alt="QUAKE4"></a></td>
|
||||
<td><img src="images/splashright.gif" border="0"></td></tr>
|
||||
<tr><td colspan=4><img src="images/splashbottom.jpg" border="0"></td></tr>
|
||||
</table>
|
||||
</center>
|
||||
|
||||
|
||||
|
||||
</body></html>
|
||||
<!--
|
||||
FILE ARCHIVED ON 13:43:52 Aug 01, 2008 AND RETRIEVED FROM THE
|
||||
INTERNET ARCHIVE ON 05:28:10 Apr 09, 2021.
|
||||
JAVASCRIPT APPENDED BY WAYBACK MACHINE, COPYRIGHT INTERNET ARCHIVE.
|
||||
|
||||
ALL OTHER CONTENT MAY ALSO BE PROTECTED BY COPYRIGHT (17 U.S.C.
|
||||
SECTION 108(a)(3)).
|
||||
-->
|
||||
<!--
|
||||
playback timings (ms):
|
||||
RedisCDXSource: 0.584
|
||||
load_resource: 78.881
|
||||
exclusion.robots.policy: 0.258
|
||||
captures_list: 192.553
|
||||
CDXLines.iter: 19.308 (3)
|
||||
LoadShardBlock: 161.355 (3)
|
||||
PetaboxLoader3.datanode: 152.75 (4)
|
||||
PetaboxLoader3.resolve: 56.026
|
||||
exclusion.robots: 0.269
|
||||
esindex: 0.016
|
||||
-->
|
||||
</body>
|
||||
</html>
|