from raduffy's .plan file (who uses those things still!?)
http://www.webdog.org/cgi-bin/finger.plm?id=313
http://www.webdog.org/cgi-bin/finger.plm?id=313
July.26.2004
------------
I've seen quite a few posts in the forums about "Ultra" quality and why we don't set this by default out of the box. I thought I would clarify a few of the reasons and also take the time to mention some of the hardware and software we found incredibly useful during the development of DOOM 3.
To put things in perspective, most production levels in DOOM 3 contain more media assets than all of Quake 3: Arena. When we started working on the memory foot print, our goal was a 256MB system. In most cases loading up an area of the game on a 256MB system works fine, the problems arise when you start to transition from one area to the next ( successive map loads ). Memory fragmentation starts to really work against us and it ultimately made it just not feasible for a reasonable play experience to support 256MB.
Two basic options make up the quality levels, sound diversity and image fidelity.
Sound diversity is effectively how many sounds we support per sound shader for a given "sound". There may be for instance, 7 different "bullet striking the wall" sounds for a given bullet. In low quality, we only use one sound for this vs randomly choosing between one of the seven available. When we started on memory optimization, most levels used between 80 and 100 megabytes of sound data. We made the choice to move to .OGG for quite a few sounds which effectively removed the problem for us.
Image fidelity is dependent on what quality level we load the textures at.
In Ultra quality, we load each texture; diffuse, specular, normal map at full resolution with no compression. In a typical DOOM 3 level, this can hover around a whopping 500MB of texture data. This will run on current hardware but obviously we cannot fit 500MB of texture data onto a 256MB card and the amount of texture data referenced in a give scene per frame ( 60 times a second ) can easily be 50MB+. This can cause some choppiness as a lot of memory bandwidth is being consumed. It does however look fantasticand it is certainly playable on high end systems but due to the hitching that can occur we chose to require a 512MB Video card before setting this automatically.
High quality uses compression ( DXT1,3,5 ) for specular and diffuse and no compression for normal maps. This looks very very close to Ultra quality but the compression does cause some loss. This is the quality that for instance the PC Gamer review was played in.
Medium quality uses compression for specular, diffuse, and normal maps. This still looks really really good but compressing the normal maps can produce a few artifacts especially on hard angled or round edges. This level gets us comfortably onto 128MB video cards.
Low quality does everything medium quality does but it also downsizes textures over 512x512 and we downsize specular maps to 64x64 in this mode as well. This fits us onto a 64MB video card.
One thing of note on the normal map compression is that generally speaking if you DXT a normal map you get really crappy results. NVIDIA hardware supports palettized compression which yields good compression and normal maps retain hard and round edges really well. Unfortunately this compression does a poor job in other cases and you end up getting splotchy areas. ATI does not support the palettized compression so we needed a better solution. ATI had done some research on various methods of normal map compression and we ended swapping the red and alpha ( which is zero in the case of a normal map ) channels. This effectively allows the compression to do a much better job and is just one extra instruction in the fragment program to move the alpha channel into the red channel. The bottom line on what happens on each card is as follows.
All modern NVIDIA and all ATI hardware use the compressed normal maps in Medium and Low qualities with the swizzled components.
NV10/20 hardware ( GF4MX and GF3 ) uses palettized normal maps in Medium and Low qualities.
Another question I have had multiple emails about, yes the game is capped at 60fps for normal game play. For render demos, like what was used for the HARD OCP stuff, we run those at full tilt which is why you will see > 60fps.
For the curious, here is a list of software/hardware we found useful during the development of DOOM 3.
Incredibuild by Xoreax.
Visual Assist by Whole Tomato Software
Alienbrain by Avid ( formerly NXN )
Visual Studio by Microsoft
DOOM 3 was developed mostly on Dell and/or Alienware computers. Falcon also sent us a kick ass system that has been Tim's primary play system through most of the project.
The art team used a wide variety of tools ( they probably use other stuff too but this is what comes to mind )
Maya
Lightwave
ZBrush
3D Max
Photoshop
We saw a few bumps in the road during the project, we had a multiple ( simultaneous ) drive failure in our primary development server which effectively trashed the raid system and was not recoverable. This resulted in building a two IDE drive raid system on a Saturday morning so the team could keep working. So all of DOOM 3 development was housed in an old dev system with a $79 RAID card driving two 100GB drives for about a week. The end result of this was we went ahead and built two identical RAID 1/0 systems ( about a half a terabyte each ). This has been the configuration for the last 18 months or so.
We made the move to Alienbrain about two thirds into the project. It was a big change for everyone as no one but the programmers were used to having to "check something out" to work on it. Overall this was a big win for the project as it centralized everything into one application from an asset/code standpoint. Alienbrain like any major software system has a few gotchas but has performed very well and sustained our RAID running entirely out of drive space multiple times.
I hope everyone enjoys the game.
