AQ2World.com

SoLiDuZ wrote: got a radeon 8500 here d3 put it on low and the graphics are still stunning in my oppinion.

Den wrote:Yes you can ? pre-order it from the states

Humus wrote:
I picked up Doom3 today and let be begin by saying it's a kickass game so far. A few minuses like weapon reload (which I find add nothing to a game, except annoyance, so I don't know why many devs keep adding it to their games), but overall much above my expectations.

Anyway, to the fun part, exploring the technology.
I think I've found the source of why this game runs comparably slow on ATI hardware vs. nVidia at the moment, and found a solution to the problem.

First, open your doom3\base folder. Doubleclick on the pak000.pk4 file. In the "window can't open this file .. .bla bla" dialog, go on and associate the file with an app like WinRar. With this file open in WinRar, go to the glprogs directory in the file. In there you'll find the shaders. The interaction.vfp file seems to be the main rendering shader. Altering this shader to output a constant color turns most objects into that constant color, except for stuff like computer screens etc.

So doubleclick the interaction.vfp file to open it (you may have to associate the .vfp extension with a text editor like notepad or wordpad first since we're going to edit the file). Scroll down to the fragment shader. You'll find these rows:

PARAM	subOne = { -1, -1, -1, -1 };
PARAM	scaleTwo = { 2, 2, 2, 2 };

PARAM specExp = { 16, 0, 0, 0 };

# perform a dependent table read for the specular falloff
TEX	R1, specular, texture[6], 2D;

# perform a dependent table read for the specular falloff
# TEX	R1, specular, texture[6], 2D;
POW	R1, specular.x, specExp.x;

Save the file and close your text editor. WinRar will ask if you want to update the file in the archive, select yes. Close WinRar and enjoy about 40% higher performance in Doom3. Haven't done extensive testing yet, but my performance went from 34fps in 1280x1024 to 48fps.

Conclusion and discussion:
I don't want to complain about Carmack's work, I still consider him to be the industry leader in graphics engines. Though when I read the shader it striked me how many texture accesses it did compared to the relatively short shader, even for stuff that could just as well be done with math for a small cost in instructions. Using a dependent texture lookup for POW evaluation makes a lot of sense for R200 level hardware due to instruction set limits, but for R300 and up it's much better to just spend the three cycles it takes to evaluate POW with math instead of risking texture cache trashing with a dependent texture read, which may be much more costly, especially since the access pattern in this case will be far from linear. Also, using math improves the quality too, even though it may not be very noticable in this game.

I should point out though that I'm not sure if the constant specular factor 16 that I chose is the one that the game uses, so output may be slightly different, but if this solution will be worked into the game in a future patch, then this is easily configurable by the game so that there won't be a difference, except a lot faster.

An interesting follow-up discussion may be why this dependent texture lookup is much slower on our hardware than on nVidia. Maybe there's an architectural difference that's to blame, or maybe something else? The main point here though is that this should be good enough proof that ATI hardware can run Doom3 just as good if not better than nVidia, and that we can pass on all the "ATI suck in OpenGL", "ATI's drivers suck" etc. into the trashcan where it belongs.

PARAM specExp = { 8, 0, 0, 0 }; 

POW	R1, specular.x, specExp.x;

MAD_SAT R1, specular, 4.0, -3.0;

Replacing the POW with POW_SAT (or the previous DP3 with DP3_SAT which might be a more logical place considering what the code is doing, but anyway) seems to fix the white pixel problem. To really work it would need some code from ID to pass the wanted specular exponent in constant as mentioned before. The white pixels were a result of de-normalization in the normal map, which is made worse by having the map compressed (thus looking worse on medium and low quality settings than high), and pixels getting over 1.0 bright highlights in corner cases. The texture lookup does saturation (clamping texture coordinates) as well so these should be equal in function, assuming the specular is just a power function as it seems to be. If any, the math version does the operation more accurately and thus might show aliasing in the normal map more visibly.

Interestingly the shader also uses cubemap for normalizing the light vector for diffuse lighting but math for normalizing half vector for specular lighting. The reason probably is that the code seems to be geared towards cards that have lower math performance (read: FX cards) and trades texture lookups for math ops. For specular the lookup is simply too inaccurate and causes blobby looking highlights so it has to be done with math. In retrospect this is kind of sad and having a separate nv3x path that does texture lookups and a proper math using ARB2 path would have been better for both current ATI (and NV40) cards and even better for future cards where math power is growing much faster than texture bandwidth.