For information on how to get the SDK to compile under Linux, there is a pretty handy
<ahref="https://modwiki.dhewm3.org/How_to_build_the_SDK_on_Linux">guide</a> up on <del>modwiki.net</del><ahref="https://modwiki.dhewm3.org/">modwiki.dhewm3.org</a>.
Someone asked me what exactly the numbers in com_speeds mean.
<br>
<samp>frame:100 all:15 gfr:5 rf:3 bk:6</samp>
<br>
frame is the frame number, it's just an always incrementing value.<br>
all is the milliseconds it took to render that frame (60fps is ~ 16ms)<br>
gfr is the game code<br>
rf is the render front end<br>
bk is the render back end<br>
<p>
The render front end is responsible for traversing the scene, portal and view frustum culling, shadow generation, dynamic model generation, and sorting. The back end is responsible for issuing the actual draw calls (the back end is what changes when r_renderer changes).
<p>
While I'm at it, here are what some of the other performance counters mean:
v is the number of camera views that are drawn (increases with mirrors, etc)<br>
ds is the number of draw calls sent to the video card (try to keep this low)<br>
t is the number of regular triangles (not shadow tris) / "ambient" triangles<br>
v is the number of regular verticies (not shadow) / "ambient" verticies<br>
st is the number of shadow triangles<br>
sv is the number of shadow verticies<br>
image is the amount of image data used<br>
<p>
<samp>r_showDynamic</samp><br>
Shows the number of dynamic surfaces that were regenerated this frame (light flares, particles, guis)
<p>
<samp>r_showInteractions</samp><br>
This shows the number of light/surface interactions thate were generated that frame, as well as the number of shadows that were generated. Take out your flashlight while this is set to see why the flashlight makes everything so bloody slow.
I've had a couple of people asking how exactly to run the <ahref="downloads.html">Maya importer</a>. The zip file contains a single dll "MayaImportx86.dll" that goes in the Doom 3 folder along with doom3.exe. You must have Maya installed, though it doesn't have to be running when you launch Doom 3. Type "exportModels somefile.def" where somefile.def is the name of the def file that contains your export section. For more information on the format of the export section, <ahref="modelexport.html">see this page</a>.
"In post processing shaders used in doom 3 (like heat haze) the window space fragment position (fragment.position) is multiplied by program.env[1] to convert to 0-1 range (which would be pos*[1/width,1/height]) then it's multiplied by program.env[0] which is scaling by a non-pow-2 adjust. Now I can see why this is done b/c the game resolution is usually not a power of two so it's rendered to a power of 2 texture thus this conversion needs to be done to access the correct texel. What I'm wondering is, how is env[0] computed?"
</i>
<p>
program.env[0] is calculated as <samp>{ w / Pw, h / Ph, 0, 1 }</samp> where w is the viewport width + 1, h is the viewport height + 1, Pw is the width of the uploaded texture, and Ph is the height of the uploaded texture. The 1 is added becasue an extra row and column is copied for the bilerp.
<p>
Thomas was correct that program.env[1] is calculated as <samp>{ 1 / w, 1 / h, 0, 1 }</samp>
</td></tr>
</table>
<p><tableclass="newspost">
<tr><tdclass="date">6/24/05</td>
<th>listDef</th>
</tr>
<tr><tdcolspan="2">
James writes:<br>
<i>
"I'm wondering how listDefs work in the Doom 3 engine. I've done plenty
of searching in the SDK, but can't seem to find how they are generated.
ListGUI.h is the most promising thing I've found so far, but a lot of the
lists (modsList, serverlist, etc.) don't seem to be in the SDK.
Are the lists handled in the exe?
Is there anyway to make up custom lists for use with listdefs?
If so, which commands do I use?"
</i>
<p>
Most of the lists are generated in the engine code (like the mod list, the server list, the save game list, etc) but there are a couple of
lists that are generated in the game code. All the lists in the PDA (the email list, the PDA list, the video list, the audio log list) are
generated in <samp>UpdatePDAInfo</samp> and <samp>AddGuiPDAData</samp>.
<p>
If you create a listDef called "foo" then setting "foo_item_0" with <samp>SetStateString</samp> will set the first item in the foo list.
When the list is rendered, it searches from 0 until it stops finding items. This means if you have 0, 1, and 3 set then the third item
will not be drawn (because it will see that 2 is not set and stop). You can get (and set) the index of the selected item with "foo_sel_0".
If multiple selection is supported ("multipleSel" is set to 1 in the listDef) then you can set the other selections with "foo_sel_%i" (which
works the same as the item data). Multiple columns are supported by inserting \t (the tab character) in the string (note that "tabstops" must
be set in the listDef).
</td></tr>
</table>
<p><tableclass="newspost">
<tr><tdclass="date">6/2/05</td>
<th>Heartbeat</th>
</tr>
<tr><tdcolspan="2">
There is an issue where sometimes a server will stop sending heartbeats to the master server (which causes it to drop off the list). The problem isn't major enough to warrant a new patch, but mods can fix it by putting this in <samp>idGameLocal::InitFromNewMap</samp>:
Their goal is to create a robust and complete Doom 3 editing manual. The information is contributed by community members
and can be edited by other community members. It's like an open source users manual. Head on over and contribute some
information.
</td></tr>
</table>
<p><tableclass="newspost">
<tr><tdclass="date">5/31/05</td>
<th>gameLocal.sessionCommand</th>
</tr>
<tr><tdcolspan="2">
Arne asks:<br>
<i>
"Is there a reason to sometimes copy a command to the sessionCommand array
instead of using cmdSystem->BufferCommandText() to perform any commands?"
</i>
<p>
There are only 5 valid commands that can be used with sessionCommand:<br>
<ul>
<li>map / devmap
<li>died
<li>disconnect
<li>endOfDemo
<li>game_startMenu
</ul>
<p>
"disconnect" and "endOfDemo" actually just call BufferCommandText so it doesn't really matter for those two. For the other three, you should use sessionCommand.
<p>
"map" in sessionCommand will save persistent info but "map" in BufferCommandText will not. "died" and "game_startMenu" aren't available as console commands.
</td></tr>
</table>
<p><tableclass="newspost">
<tr><tdclass="date">5/24/05</td>
<th>Doom III 1.3 released</th>
</tr>
<tr><tdcolspan="2">
It took longer than any of us had wanted, but Doom III 1.3 is there.
Below is the list of fixes and updates in the patch. Please refer to the
documentation after installation for complete changes information since
version 1.0
<p>
The files will be avaible shortly on <ahref="ftp://ftp.idsoftware.com/idstuff/doom3/">id's ftp server</a>, on <ahref="http://www.doom3.com/update.asp">doom3.com</a>
and on <ahref="http://zerowing.idsoftware.com:6969/">the tracker</a>.
<p>
The Linux version adds support for Doom III: Resurrection of Evil. See
<ahref="http://zerowing.idsoftware.com/linux/doom/">the Linux FAQ</a> for installation instructions.
<p>
We are also releasing updated SDKs for version 1.3, you can find some
documentation of the new features in <ahref="http://zerowing.idsoftware.com/linux/doom/FrontPage#head-68edbf8a1721998a8a59e91ebad1e09849f7b751">the FAQ</a>. This new SDK also has
source code for the RoE gamecode.
<p>
<b>Fixes & Updates in 1.3:</b>
<ul>
<li>PunkBuster(TM) support has been added.
<li>EAX(R) ADVANCED HD(TM) support in the sound engine contributed by
Creative Labs(R). Doom 3 base game comes with room reverb data.
<li>To utilize EAX(R) ADVANCED HD(TM) in Doom 3, you must have 100% EAX
4.0 compatible sound card. Please refer to your sound card
manufacturer for details on whether or not your sound card supports EAX 4.0.
<li>Sound Blaster(R) Audigy(R) 2 users who wish to utilize the new EAX 4.0
feature in Doom 3 should download the latest Creative Beta Drivers for
the card released on April 5th, 2005. Not using these drivers may result
in game instability while using EAX 4.0.
<li>Server provides .pk4 file download URLs (http/ftp), client has
internal download.
<li>New class of .pk4 files: 'addon paks' are only referenced when the map
is loaded in.
<li>.pk4 downloads and addon paks come with a number of fixes to the 'pure
server mode' filesystem code.
<li>Fixed ragdoll bounciness.
<li>Fixed how Doom 3 detects LAN client vs. Internet clients.
<li>LZW compression of render demos.
<li>Fixed command line parameter passing.
<li>Added a QuakeIII-style graph of the connection quality for network clients
controlled with net_clientLagOMeter cvar
displays a graph of how much the client predicts ahead of the server
note that you can change the minimum predict ahead of a client by
setting net_clientPrediction
</ul>
Changes relevant to mod developers (SDK):
<ul>
<li>Added UploadImage to idRenderSystem interface. This lets the user blit
images to the renderer.
<li>Supports fs_game_base; this lets you base a mod off base game + d3xp +
your own content.
<li>Most of the download redirection is handled in the game code, and can
be extended.
</ul>
Linux specific:
<ul>
<li>ALSA device opened non-blocking to avoid hangs.
</ul>
</td></tr>
</table>
<p><tableclass="newspost">
<tr><tdclass="date">4/27/05</td>
<th>binary.conf, visportals, and 1.3</th>
</tr>
<tr><tdcolspan="2">
I've seen quite a few mods being released without a binary.conf file. <b>Always include a
binary.conf file when you release a mod with an updated gamex86.dll!</b> The format is quite simple, it's
a single character indicating which operating system the dll is for. 0 for windows, 1 for mac, 2 for Linux.
In 1.1 and 1.2 it doesn't matter a whole lot because the windows version will load the dll anyway, but in
1.3, the dll will only be loaded from a pak file where there exists a binary.conf file and the number matches
the operating system. If it can't find a binary.conf file, it will load the dll from base. This is probably
not what you want.
<p>
A bunch of people have asked me for some clarification on how exactly vis portals work. I put up a brief guide
You can also do some additional checks, for example you can test the exact class name by throwing in this check:
<preclass="code">
if ( idStr::Cmp( ent->GetClassname(), "flickeringlight" ) == 0 ) {
}
</pre>
</td></tr>
</table>
<p><tableclass="newspost">
<tr><tdclass="date">02/17/05</td>
<th>idCollisionModelManager::LoadModel</th>
</tr>
<tr><tdcolspan="2">
Chris asks,<br>
<i>"If one attempts to load a modelname that has no collision model, does LoadModel just
load a default model, or does it load nothing and set some value on the cmHandle_t to
reflect an error, like -1?"</i>
<p>
idCollisionModelManager::LoadModel will load the surfaces of the render model as a
collision model if a .cm file doesn't exist for that model and <b>none</b> of the surfaces in
the model have SURF_COLLISION set. Of course render models can have a <b>lot</b> of polys, and
generally make crappy collision models, so I highly suggest always using a cm or a collision
surface.
<p>
idCollisionModelManager::LoadModel will return 0 in the following conditions:
<ul>
<li>If there are no more slots left (also calls common->Error)
<li>If <samp>precache</samp> is true and there is no .cm file
<li>If the render model is not .ase or .lwo
<li>If the render model doesn't exist or is invalid
</ul>
</td></tr>
</table>
<p><tableclass="newspost">
<tr><tdclass="date">02/01/05</td>
<th>Deforms</th>
</tr>
<tr><tdcolspan="2">
<tableclass="datatable">
<tr><tdclass="nobr">sprite</td><td>Deform the triangles of this surface to always face the viewer</td></tr>
<tr><tdclass="nobr">tube</td><td>Pivot a rectangular quad along the center of its long axis<br>Note that a geometric tube with even quite a few sides tube will almost certainly render much faster than this, so this should only be for faked volumetric tubes. Make sure this is used with twosided translucent shaders, because the exact side order may not be correct.</td></tr>
<tr><tdclass="nobr">flare <size></td><td>Build a translucent border that's always facing the viewer. This only works on quads (surfaces with 4 vertices). Used to make lens flares around lights.</td></tr>
<tr><tdclass="nobr">expand <amount></td><td>Expand the surface along it's normals.</td></tr>
<tr><tdclass="nobr">move <amount></td><td>Moves the surface along the X axis, mostly just for demoing the deforms. Example: <samp>deform move (time * 1)</samp></td></tr>
<tr><tdclass="nobr">turbulent <table><range><br><timeoffset><domain></td><td>Turbulently deforms the S, and T values.<br>Example: <samp>deform turbulent sinTable 0.05 (time * 1) 10</samp></td></tr>
<tr><tdclass="nobr">eyeBall</td><td>Each eyeball surface should have an separate upright triangle behind it, long end pointing out the eye, and another single triangle in front of the eye for the focus point. The texture coordinates on the eyeball surface will be deformed so that the center is lined up with the vector going from the origin triangle to the focus triangle.</td></tr>
<tr><tdclass="nobr">particle <particleDecl></td><td>Emit particles from the surface instead of drawing it.</td></tr>
<tr><tdclass="nobr">particle2 <particleDecl></td><td>Like particle, but ignores the surface area so small surfaces emit the same number of particles as large surfaces.</td></tr>
</table>
</td></tr>
</table>
<p><tableclass="newspost">
<tr><tdclass="date">01/31/05</td>
<th>Map Loading</th>
</tr>
<tr><tdcolspan="2">
When you issue a "map" command, the following process happens:<br>
<ul>
<li>Mute Sound System
<li>Run Wipe
<ul>
<li>Capture screen to "_scratch"
<li>Display "wipeMaterial" for "com_wipeSeconds" seconds.
<tr><td>editorOutput</td><td>Pipe status messages to the editor window</td></tr>
</table>
</td></tr>
</table>
<p><tableclass="newspost">
<tr><tdclass="date">01/06/05</td>
<th>What noSelfShadow does</th>
</tr>
<tr><tdcolspan="2">
The way the renderer handles noSelfShadow is it:
<ol>
<li>Renders all selfShadow objects shadows to the stencil buffer
<li>Renders all noSelfShadow objects with lighting
<li>Renders all noSelfShadow objects shadows to the stencil buffer
<li>Renders all selfShadow objects with lighting
</ol>
<p>
So basically what happens is when 'noSelfShadow' objects are rendered, their shadows haven't been rendered to the stencil buffer yet. But by the time 'selfShadow' objects are rendered, all shadows have been rendered (self and otherwise).
<p>
This means an object with 'noSelfShadow' will not cast a shadow onto a different object with 'noSelfShadow'
<p>
In other news, we're back from the holidays :)
</td></tr>
</table>
<p><tableclass="newspost">
<tr><tdclass="date">12/09/04</td>
<th>WARNING: Backwards Triangle Generated!</th>
</tr>
<tr><tdcolspan="2">
This message is generated when the optimizer is generating triangles and finds one with
a zero or negative normal. It is a fairly benign warning. Most often this happens because
the optimizer generated a degenerate triangle [a triangle with no surface area] because
of floating point error.
<P>
To put it in John's words:<br>
"This can happen reasonably when a triangle is nearly degenerate in
optimization planar space, and winds up being degenerate in 3D space."
<p>
In other news, me and others from id are going to be out of the office much of this month
due to Christmas, New Years, Chanukah, and other such holidays. Emails sent to us may not
be answered for a while.
</td></tr>
</table>
<p><tableclass="newspost">
<tr><tdclass="date">12/02/04</td>
<th>Maya Importer Source Code</th>
</tr>
<tr><tdcolspan="2">
Looks like the last installer was missing some files to compile the Maya Importer.<br>
I have put up an installer which contains only the missing files <ahref="downloads/D3SDK2_MayaImport_Setup.exe">here</a>.
</td></tr>
</table>
<p><tableclass="newspost">
<tr><tdclass="date">11/23/04</td>
<th>More Clean Pack Files</th>
</tr>
<tr><tdcolspan="2">
Eutectic is at it again, he has a clean skin pack <ahref="http://www.doom3world.org/phpbb2/viewtopic.php?t=7479">here</a>
and a clean shound shader pack <ahref="http://www.doom3world.org/phpbb2/viewtopic.php?t=7439&highlight=">here</a>.
</td></tr>
</table>
<p><tableclass="newspost">
<tr><tdclass="date">11/18/04</td>
<th>Clean def Files</th>
</tr>
<tr><tdcolspan="2">
Eutectic cleaned up all the def files, removing entities that are invalid, and providing more accurate comments
for the valid ones. You can download his pack file <ahref="http://www.pcgamemods.com/8596/">here</a>. Also,
if you missed it, he also has a clean materials pack <ahref="http://www.pcgamemods.com/7707">here</a>.
</td></tr>
</table>
<p><tableclass="newspost">
<tr><tdclass="date">11/16/04</td>
<th>SDK Version 2 -- Now With Vehicles!</th>
</tr>
<tr><tdcolspan="2">
We just packaged up a newer version of the SDK.
<p>
You can find the Windows version <ahref="ftp://ftp.idsoftware.com/idstuff/doom3/source/win32/DOOM3_SDK_2.exe">here</a><br>
The Linux version is <ahref="ftp://ftp.idsoftware.com/idstuff/doom3/source/linux/doom3-linux-1.1.1282-sdk.x86.run">here</a><br>
<p><b>Vehicles</b><br>
Be sure to read the readme.txt in the vehicles folder<br>
<p><b>Maya Importer Source</b><br>
To compile the Maya Import dll, you will need to get the Maya 4.5 or the Maya 6.0 SDK from <ahref="http://www.alias.com/">Alias</a>.
There is a note in the directory explaining where the files need to go. The project comes
set up to compile a dll for Maya 4.5. If you want to compile a dll for Maya 6.0,
instructions are in maya_main.cpp. For Maya 6.0, you will need Visual Studio 2003 or higher.
The Maya 6.0 SDK does not work with Visual Studio 2002.
<p><b>Linux Source</b><br>
TTimo put together an official release for the Linux code. The code itself is the same as windows,
but there are some different build options and an included SCons file.
<p><b>Random Fixes</b><br>
Including (but not limited to) compiling 'out the box' in Visual Studio 2003 and 2005
<p>
If you have already done significant work on a mod, I would recommend installing this to a clean
directory, then running windiff against your code base. Alternatively you could diff against the
first SDK and manually copy the changes over.
</td></tr>
</table>
<p><tableclass="newspost">
<tr><tdclass="date">11/12/04</td>
<th>Maya Importer Round-up</th>
</tr>
<tr><tdcolspan="2">
There has been a bit of confusion over the Maya importers, so to set it all
straight: You need the import dll that matches your version of Maya. If you
are running Maya 4.5 then you need the MayaImportx86.dll for Maya 4.5.
<p>
Here are import dlls for all the versions of Maya I could find:
