Different rendering paths in Doom3 -- specifics?
- Thread starter Reverend
- Start date
Check JC's Jan 29th 2003 .plan. The only differences from then is that the ARB1 path is no longer used (from Robert Duffy) and that you need to be running in the ARB2 path to see the heat haze, shockwave and the other DX9-level effects. And precision of course.
ARB is used for Matrox Parhelia and ATI R100, and maybe others. It's a fallback path for cards that can't do ARB2, and don't have special paths like R200 and NV10/20.
It's a pretty ugly thing too. Poor Matrox owners. Parhelia might as well be a DX7-level card.
It's a pretty ugly thing too. Poor Matrox owners. Parhelia might as well be a DX7-level card.
http://www.techreport.com/etc/2004q3/doom3-midlow/index.x?pg=1
Here you can see screenshots of various hardware, running the various parts.
Basically they all look very similar.
Main difference is the ARB path (on Parhelia), which just seems to have bugged lighting (didn't look right on my R3x0 either). All others look virtually the same. And ofcourse the ARB2 path has the extra heat-haze and 'wobbly' glass effects.
Here you can see screenshots of various hardware, running the various parts.
Basically they all look very similar.
Main difference is the ARB path (on Parhelia), which just seems to have bugged lighting (didn't look right on my R3x0 either). All others look virtually the same. And ofcourse the ARB2 path has the extra heat-haze and 'wobbly' glass effects.
Johnny Watson
Newcomer
mito said:
When I tried it I didn't notice any major difference in performance, though I'd suspect if anything performance would be hindered on the lower end codepaths because it's rendering more passes per light.
Pete: yeah, I only noticed it was Rev when I posted the second time. 
mito: quite the opposite. Here are my timedemo results (1024 @ high quality), first and second runs:
ARB = 33.2 | 36.1
R200 = 39.5 | 39.9
ARB2 = 37.5 | 41.0
EDIT: That's with VSYNC + triple buffering and the new 4.8 drivers.
Scali: On mine they were reasonably different. ARB was noticeably flat because of no bump mapping. R200 was also somewhat flat (I directly compared a shot between R200 and ARB2 and the surfaces are definitely different looking). The R200 path also gave me bad specular highlights, bad as in way overdone when compared to ARB2.
mito: quite the opposite. Here are my timedemo results (1024 @ high quality), first and second runs:
ARB = 33.2 | 36.1
R200 = 39.5 | 39.9
ARB2 = 37.5 | 41.0
EDIT: That's with VSYNC + triple buffering and the new 4.8 drivers.
Scali: On mine they were reasonably different. ARB was noticeably flat because of no bump mapping. R200 was also somewhat flat (I directly compared a shot between R200 and ARB2 and the surfaces are definitely different looking). The R200 path also gave me bad specular highlights, bad as in way overdone when compared to ARB2.
The different paths require and use different extensions.Reverend said:
The ARB path is just basic "fixed function" multitexture combiners, and no vertex shaders. Roughly equivalent to "DX7" hardware capabilities. I assume that it uses the ARB_texture_env_combine extension (and perhaps ARB_texture_env_dot3), though to verify it either way, I'd need to see the engine code. I probably never will
The NV10 and NV20 paths require NV_register_combiners. NV1x hardware supports only two combiner stages. NV2x hardware supports eight.
The NV20 path also uses vertex programs, specified throught the ARB_vertex_program API. These vertex programs are named base\glprogs\nv20_*.vp. They are plain text, so you can have a look for yourself.
Just for sake of completeness, the glprogs folder is in one of the paks (forgot which one, sorry), and you can extract it with any zip-compatible archiver.
It is likely be that the NV20 path also uses NV_texture_shader to do dependent reads. If it does, this would be something like "PS1.3+".
The R200 path, again, uses ARB_vertex_program, though I found only one vertex program specific to that path: base\glprogs\R200_interaction.vp. A possible explanation to this lack of vertex programs might be that the R200 path borrows the other vertex programs from the ARB2 path. It's 99% certain that this path uses ATI_fragment_shader for "pixel shading". This is roughly equivalent to "PS1.4".
The ARB2 path combines ARB_vertex_program with ARB_fragment_program, which is more or less the same thing as "PS2.x".
You can inspect these shaders by looking at the various vfp files in base\glprogs. A vfp contains both an ARB_vertex_program vertex "shader" and an ARB_fragment_program pixel "shader".
There's one shared vertex program: shadows.vp. It's quite likely that this vertex program is shared by the NV20, R200 and ARB2 paths. Shadow volume rendering doesn't require any fragment processing at all, so there is no need for a distinction.
I'd also like to add that this is just normal OpenGL programming style. R200 and NV2x have no common pixel shading API in OpenGL, so you need two paths if you want to make good use of both of these families. The NV10 and NV20 path's cannot run on R200 hardware and vice versa, because the extensions that these paths rely on are proprietary, very close to the hardware, and technically cannot be supported by the other camp.
(An R300 would be a feasible target for emulation of NV_register_combiners plus NV_texture_shader, but ATI didn't bother; I won't blame them)
The path names just reflect actual hardware, unlike e.g. the quite unfortunate path names in Far Cry.
This scheme is, to an extent, backwards compatible, because even after significant hardware changes, the vendors emulate the "old" fragment processing APIs on their new chips.
An ATI x800 can run the ARB2, R200 and ARB paths. A Geforce 6 can run the ARB2, NV20, NV10 and ARB paths.
Hope this answers your question
Try r_logFile (listCvars -help r_logFile) or glIntercept -- they complement one another.zeckensack said:I assume that it uses the ARB_texture_env_combine extension (and perhaps ARB_texture_env_dot3), though to verify it either way, I'd need to see the engine code. I probably never will
It looks as though current emulation of nv10/20 register combiners is broken (61.77).zeckensack said:
