Doom 3 rendering paths difference

[gkar1]

Doom3 isn't a game designed to make use of high precision, its a DX7 class multipass title with some frills on top.

You are joking right?

I think it's a matter of perspective.

What, in your opinion KILER, would you disagree with Dave's opinion? What are the features of Doom3 that you know, KILER?

NURBS?
Being completely done on videocard, not CPU. I have yet to see a card capable of doing it 100% in hardware. Doom 3 supports it.

I just couldn't help but laugh at this. You need to do your homework
Doom3 has really low polycounts and relies mostly in per pixel lighting to give it its "good looks".

 

[Rodéric]

I know one game engine that uses what I would call high order surfaces (by contradiction to tesselated surfaces), that works well and is impressive.
(it uses fractals and some HOS AFAIK)

You are not thinking about the Quake3 engine that uses bezier curves to create curved surfaces are you?

No, I wasn't thinking about this one, but well that's true that it fits in the description I made

I was thinking about this one:
http://www.vtales.com/game/temp/

 

[sonix666]

Doom3 has really low polycounts and relies mostly in per pixel lighting to give it its "good looks".

I have to agree on this one. Judging from the released screenshots, the polygon count is very low. While the inner part of the models looks detailed because of the bumpmapping, the edges of the models really show how low poly it is. Its really a big downsize from Unreal Tournament 2003.

But in defense of Doom 3, because of trouble they have run the demo in medium detail at E3, so the screenshots might be in medium detail mode.

 

[Tim]

No, I wasn't thinking about this one, but well that's true that it fits in the description I made

I thought so, the looking impressive part of your description made me think it was a never engine even thou the curved surfaces was pretty imppressive when it was released.

I was thinking about this one:
http://www.vtales.com/game/temp/

That looks really impressive. Another engine that uses splines is the one from Dronez:

http://www.multiplayer.it/dronez/english/featurez_tech.html#lod

It seems like splines has their place in game engines even without hardware support.

 

[BNA!]

I have to agree on this one. Judging from the released screenshots, the polygon count is very low. While the inner part of the models looks detailed because of the bumpmapping, the edges of the models really show how low poly it is. Its really a big downsize from Unreal Tournament 2003.

You can have much higher polycounts for the models, but after all they want to sell the game not only the 0.01% of people who have the latest hardware installed.
The engine works very fine with high polygon models (five figures), but you'll end up with an insane amount of silouhettes to perform shadowing and self shadowing on.
Add more than one light per scene and you'll leave out any gamer but hardcore geeks who are willing to play a 50k poly boss in a room with 6 triangles

BTW - the model in Unreal Tournament 2k3 do not have more polies (at least the ones that got released in Lightwave format).

It's just that all this very high detail displayed via the normal maps makes the hard "bizzaro" look of the polygonal characters more apparent, especially in the head area.

But in defense of Doom 3, because of trouble they have run the demo in medium detail at E3, so the screenshots might be in medium detail mode.

Only medium texutre detail I think

 

[Johnny Rotten]

Judging by current published media, more like unified darkness model with couple of spotlights. Imo Splinter Cell for instance does the lighting/shadows very well, and by current indications DoomIII will be adding nothing radically new.

As for normal maps, yeah, would be cool to have them in more widespread use, but they are no substitute for real geometry detail. Plus, properly normal-mapped games are there already.

Name me some of these properly normal mapped games please, just curious.

I'd like to hear of these as well....

 

[[maven]]

Back to the original question (which AFAIR was how do the different precisions on FX hardware affect IQ in Doom3):
My speculation is that --- as separate rendering paths for NV_extensions are used --- it will matter very little to final IQ as the accuracy can be chosen at instructions-level granularity (e.g. do the specular exponentiation in FP for accuracy but do the final blending in FX12 because it won't make a difference).

A lot of people seem to have misconceptions about the impact of using FX12 - FP16 - FP32. It's not about replacing the accuracy of all instructions but only those where necessary (which is not neccessary (or possible) on ATI's fragment shaders). This of course places an extra burden on the developer (but then again, there are so many different paths for different hardware in any game).

On the "Doom3 is nothing new" after Splinter Cell-argument (great game), I'd say that Doom3's unified approach to shadow-casting / receiving / lighting is a considerable improvement, whereas Splinter Cell places that burden on the level designer (AFAIK) and thus is sometimes inconsistent.

 

[demalion]

Something that might be relevant to image quality difference between the paths...as I brought up in the Dawn thread:

...
Light and view vectors normalized with math, rather than a cube map. On future hardware this will likely be a performance improvement due to the decrease in bandwidth, but current hardware has the computation and bandwidth balanced such that it is pretty much a wash. What it does (in conjunction with floating point math) give you is a perfectly smooth specular highlight, instead of the pixelish blob that we get on older generations of cards.
...

...

• Creates higher quality images than the original due to the normalization being done in a fragment program (dp3/rsq/mul) instead of in a normalization cubemap which the FX extensions does directly in hardware

...

The skin shader code quoted by Uttar:

!!FP1.0
# NV_fragment_program generated by NVIDIA Cg compiler
# cgc version 1.5.0001, build date Oct 15 2002  01:04:08
# command line args: -profile fp30
#vendor NVIDIA Corporation
#version 1.0.1
#profile fp30
#program main
#semantic main.skinColor_frontSpec
#semantic main.skin_norm_sideSpec
#semantic main.g_specular_colorShift
#semantic main.g_blood_texture
#semantic main.g_transmission_terms
#semantic main.g_diffuse_Cube
#semantic main.g_specular_Cube
#semantic main.g_nrmalize_Cube
#semantic main.g_dappleProjection
#semantic main.g_hilight_Cube
#semantic main.g_oiliness
#var float4 v2f.skinColor_frontSpec : $vin.TEXCOORD0 : TEXCOORD0 : 0 : 1
#var float3 v2f.worldEyeDir      : $vin.TEXCOORD2 : TEXCOORD2 : 0 : 1
#var float3 v2f.worldTanMatrixX       : $vin.TEXCOORD5 : TEXCOORD5 : 0 : 1
#var float3 v2f.worldTanMatrixY       : $vin.TEXCOORD6 : TEXCOORD6 : 0 : 1
#var float3 v2f.worldTanMatrixZ       : $vin.TEXCOORD7 : TEXCOORD7 : 0 : 1
#var float4 v2f.SkinSilouetteVec    : $vin.TEXCOORD3 : TEXCOORD3 : 0 : 1
#var samplerRECT skinColor_frontSpec :  : texunit 0 : 1 : 1
#var samplerRECT skin_norm_sideSpec  :  : texunit 1 : 2 : 1
#var samplerRECT g_specular_colorShift :  : texunit 2 : 3 : 1
#var samplerRECT g_blood_texture         :  : texunit 3 : 4 : 1
#var samplerRECT g_transmission_terms  :  : texunit 4 : 5 : 1
#var samplerCUBE g_diffuse_Cube         :  : texunit 5 : 6 : 1
#var samplerCUBE g_specular_Cube       :  : texunit 6 : 7 : 1
#var samplerCUBE g_nrmalize_Cube       :  : texunit 7 : 8 : 1
#var samplerRECT g_dappleProjection    :  : texunit 8 : 9 : 1
#var samplerCUBE g_hilight_Cube        :  : texunit 9 : 10 : 1
#var float2 g_oiliness :  :  : 11 : 1
#var half4 COL : $vout.COLOR : COLOR : -1 : 1

DEFINE LUMINANCE = {0.299, 0.587, 0.114, 0.0};
DECLARE g_oiliness;

############################################################################################
#  These two blocks slow code down 10%                                                     #
############################################################################################
TEX H0, f[TEX0], TEX1, 2D;                  # store range-compressed normal (and side spec) in H1
TEX H1, f[TEX0], TEX0, 2D;                  # store skin color in H3

MOVH H2.x, g_oiliness.y;
MULX H0.xy, H0, H2.x;
TEX H0, H0, TEX7, CUBE;

MOVH H3, f[TEX5];
DP3X H2.x, H0, H3;
MOVH H3, f[TEX6];
DP3X H2.y, H0, H3;
MOVH H3, f[TEX7];
DP3X H2.z, H0, H3;                          # H2 now contains worldNormal - extinguish

MOVH H0.xyz, f[TEX2];                       # store v2f.world_V in H1
DP3X H2.w, H0, H2;                          # H2.w = dot(Normal, View)
MULX H2.xyz,-H2, -2;                        # twice the normal
MADX H3.xyz, -H2, H2.w, H0;                 # H4 = -2*dot(H0, H2)*H2 + H0  = reflection vector.  Normal doesn't need to be fixed, because it's uniformly scaled

TEX H0.xyz, H2, TEX5, CUBE;                 # diffuse lighting
TEX H2, H2, TEX6, CUBE;                     # side specular
MULX H0.xyz, H0, H1;                        # skin diffuse*diffuse color
#MULX H2, H2, H0.w;                         # side_spec*side_spec term (H0.w is the side_spec term)
MULX H2, H2, H1.w;                          # side_spec*side_spec term (H0.w is the side_spec term)

MOVH H1.xyz, f[TEX3];                       # copy ndotv (H1.w is the spec map)
MULX H0, H0, H1.x;
MADX H0, H2, H1.y, H0;                      # diffuse + side_spec (H2 avail)

TEX H2, f[TEX2], TEX9, CUBE;                # fetch hilight
TEX H3, H3, TEX6, CUBE;                     # fetch direct specular
MULX H2.xyz, H2, H1.y;                      # hilight by facing ratio
MULX H2.xyz, H2, H1.x;
MULX H3, H3, H1.w;                          # spec*spec_map
MULX H3, H3, 0.02;                          # scale specular
MOVH H3.w, g_oiliness.x;
MULH H3, H3, H3.w;                  # scale the oiliness
MADX H2.xyz, H2, 0.7, H3;                   # 0.7*hilight + direct spec

ADDX H0, H2, H0;                            # diffuse specs and hilight
#MADX o[COLH], H0, H1.x, H2.w;              # add haze
ADDX o[COLH], H0, H2.w;                     # add haze
END


# End of program

I think this is directly pertinent, and I expect that looking at large surfaces might display the difference.



An aside regarding the remark just before the instructions: I'm not sure if it is referring to the two following instructions (why not just say "these two instructions"?), the two following "blocks" of instructions (why be concerned about their performance when they seem to be critical to the functioning of the shader?), the two instructions that are remarked with "#" in the code (this makes sense to me in a "programmer shorthand" way, if "blocks" means "things that are blocked"), or something else that isn't included or I just don't recognize. Any thoughts? Depending on which it is, it might be worthwhile to cover it in the performance speculation threads.

 

[kyleb]

first off a guess on the main subject; sense the shaders being used are also designed to be rendered on old fixed point hardware could it simply be that doing so at a higher precision simply has little effect?

also, the "nurbs" in question are actually bezier patches as Tim mentioned above. while the two can look the same they differ both functionally and mathematically; and in q3 they can also be handled by the t&l unit if available.

lastly, splinter cell's lighting and shadowing is damn cool, but it was mostly done with smoke and mirrors. doom3's lighting will have a consistency to it that would be impossible to accomplish within splinter cell.

 

[Xmas]

also, the "nurbs" in question are actually bezier patches as Tim mentioned above. while the two can look the same they differ both functionally and mathematically; and in q3 they can also be handled by the t&l unit if available.

Handled?... well, yes, hardware T&L can of course handle CPU-tessellated Bézier patches (like any other triangles). But it can't tessellate them.

 

[K.I.L.E.R]

I just couldn't help but laugh at this. You need to do your homework
Doom3 has really low polycounts and relies mostly in per pixel lighting to give it its "good looks".

As scary it sounds, you do have a point. Take a look at the shot of the lost souls. They look like cubes.

 

[kyleb]

true, but i imagine the things move so damn fast that how square their heads are is of little concern when you play. also, from the screenshots i have seen i am sure they used bezier patches in the level geometry just like quake3.

also Xmas, are you sure there is nothing special about the way the curves are handled with t&l? i was just going by what i heard quite a few years back and all i managed to find on google about it was a few mentions here and there in benchmarks and tweak guides. i swear i heard from fairly reliable sources that Carmack managed some way to offload the patches onto the t&l unit. the geforce256 was touted as the only card able to really turn things up due to that, however in light of current events i suppose it could well have just been a bunch of dishonest marketing hype. :?

 

[Saem]

IIRC, the P10 can do everything on GPU and with less passes.

 

[AndrewM]

All that the geforce256 gave you was higher throughput of triangles, which meant that you could increase the subdivisions of the patches. I cant remember exactly which cvars they were to do that. It didnt give a significantly better look.

Doom3 will not use beziers (except in the map editing possibly, but meh).

 

[BNA!]

As scary it sounds, you do have a point. Take a look at the shot of the lost souls. They look like cubes.

Hey be fair - it's more like they're diamond shaped

 

[K.I.L.E.R]

As scary it sounds, you do have a point. Take a look at the shot of the lost souls. They look like cubes.

Hey be fair - it's more like they're diamond shaped

Can you image that in 2 years time after Doom 3 is released that the latest systems will be running the game so fast and it will still have floating diamonds to cope with instead of nice round heads.

 

[BNA!]

Can you image that in 2 years time after Doom 3 is released that the latest systems will be running the game so fast and it will still have floating diamonds to cope with instead of nice round heads.

If Doom3 goes down the same path with the mod community as other id game engines we'll see amazing work which by far surpasses any system spec id sofware did design Doom3 for.

I guess the diamond shape of the lost souls wont bother me when they're flying all around me while casting nice shadows all over

BTW - keep your eyes open for an interesting announcement regarding a game franchise (got canned a few years ago, but I'm sure everybody will go ohh ahh) eventually utilizing the Doom3 engine

 

[Marc]

Hi,

Do you know if it will be possible to force partial precision (FP16) on the ARB2 Doom III path - and not only via the NV30 path ?

 

[AzBat]

BTW - keep your eyes open for an interesting announcement regarding a game franchise (got canned a few years ago, but I'm sure everybody will go ohh ahh) eventually utilizing the Doom3 engine

Team Fortress 2?

EDIT: Though Duke Nukem Forever is a possibility too.

Tommy McClain

 

[Joe DeFuria]

EDIT: Though Duke Nukem Forever is a possibility too.

Blasphemy!

DNF hasn't been cancelled...it'll be done "when it's done!?"

Though there is another 3DRealms title / franchise that was in fact canned that might be a possibility: Prey. (Of the never-got-pff-the-ground "Talon Brave" franchise.)