Doom 3 Engine incapable of custom fragment programs?

Well, this is pretty interesting... Here's an email I got from Brian Harris, replying to a question about the Cg and ARB2 path's.

Brian Harris of id Software to Ash Eassa via Email said:
You wouldn't be able to do either. The Cg path was only set up to work
with the default interaction shader (which is what does all the lighting
equations). There are two kinds of shaders in the ARB2 path, the first
is the interaction shader I was just talking about (interaction.vfp).
The other kind is a special effect shader that is applied after the
scene is rendered (such as heat haze and glass wobbles). You can find
the interaction shader and all the sfx shaders in the 'glprogs' folder
in pak000.pk4

- Brian

Wow, this is extremely interesting! Thoughts?
 
My Question to Brian said:
Regarding the Cg path, does this mean that one couldn't write any of their own
custom fragment programs (such as special effects etc..) in Cg, or that one just could not write any different light/surface interaction shaders for
specified materals? How about the ARB2 path? Could one write their own shaders in assembly in this case?
 
John should've just removed the Cg path. It's useless, regardless of whatever limited ways it is supposed to work in/with.

All that matters is the "ARB2" path. For the public and for the IHVs.
 
The short answer is no. Someone took the time to write a greyscale transform for the player model.
 
WRT the topic, D3 is capable of custom fragment programs.

If you mean "D3 is incapable of custom fragment programs written in a high level shader language" that's not really news; we've pretty much known this at least since July 2004 when Robert Duffy wrote "We don't do anything in DOOM 3 using Cg but we have support for it ( though I am not sure how much it has been tested lately and that is not a guarantee it will work)." And even before that, JC himself had stated in his .plan that only _the next engine after DOOM_ would use a high level shader language.

If you mean "D3 is incapable of custom light interaction fragment programs for individual materials" it's not news either, I believe crytec posted a mail convo with an id guy asking this very same thing.

But, nice to know the rest of the id guys are back from their mini-holiday.
 
Mordenkainen said:
WRT the topic, D3 is capable of custom fragment programs.

If you mean "D3 is incapable of custom fragment programs written in a high level shader language" that's not really news;
Meh, you can always compile a shader using Cg and load it in.
 
Chalnoth said:
Mordenkainen said:
WRT the topic, D3 is capable of custom fragment programs.

If you mean "D3 is incapable of custom fragment programs written in a high level shader language" that's not really news;
Meh, you can always compile a shader using Cg and load it in.

No argument there; I've talked to a couple of people who were working on Cg shaders for D3, I'm just pointing out to XX that he shouldn't raise his fist to the heavens for the apparent lack of support for a high level shading language in D3. ;)
 
Thing is, Carmack said that he implimented a Cg interface with the marterials system...

Did he lie?

Chalnoth said:
Mordenkainen said:
WRT the topic, D3 is capable of custom fragment programs.

If you mean "D3 is incapable of custom fragment programs written in a high level shader language" that's not really news;
Meh, you can always compile a shader using Cg and load it in.

So does that mean Doom 3 Engine can have basically the same functionality as an engine with HLSL or Cg?

Also Robert Duffy said that support was in there, but they didn't use it for Doom 3, the GAME. Does that mean the engine supports it?

Also, it seems that the Cg path doesn't work with the game but it works in the engine...or something like that.

Finally, could someone tell me if Doom 3's shader interface is as good/almost as good/shit compared to a DX9 game?
 
XxStratoMasterXx said:
So does that mean Doom 3 Engine can have basically the same functionality as an engine with HLSL or Cg?
Not necessarily. You compile Cg to an existing fragment program specification. In the case of Doom 3, it would have to be ARB_fragment_program, which has no support for branching.
 
XxStratoMasterXx said:
Thing is, Carmack said that he implimented a Cg interface with the marterials system... Did he lie?

He didn't update his .plan in two years. He could have decided a high level shader language wasn't necessary for D3 between then and when D3 was released. But again, we've known Cg wasn't "recommended" if you will when working with D3 from Robert's reply from before D3 was released.

Also Robert Duffy said that support was in there, but they didn't use it for Doom 3, the GAME. Does that mean the engine supports it?

Robert said "( though I am not sure how much it has been tested lately and that is not a guarantee it will work)". I think it's pretty clear.

Finally, could someone tell me if Doom 3's shader interface is as good/almost as good/shit compared to a DX9 game?

What do you mean by "interface"? You can create shaders in a high level shader language and then compile it to ARB asm as Ostol pointed out and you use that in-game (or code it directly as asm).

If by interface you mean IDE, then use RenderMonkey or whatever and output to ARB. What is the big deal?

Would it be better to have them as GLSL (for instance)? Sure, that way drivers handle how best to have them fit the individual hardware limits. Is it necessary for D3's needs and D3's dozen instruction-count shaders? Not really.

Oh, and if you think JC is somehow against high level shader languages you should read the last two paragraphs of this: http://finger.planetquake.com/plan.asp?userid=johnc&id=16040
 
Mordenkainen said:
http://finger.planetquake.com/plan.asp?userid=johnc&id=16040


Just noticed this in there as well:

The most expedient sounding option was to just use the Nvidia
extensions that they implement, NV_vertex_program and NV_register_combiners,
with seven texture units instead of the four available on GF3/GF4.

How?Wha?

Related to this?

The dev team did some research and found back doors and even a few undocumented instructions for the NV2X, allowing them to write custom shaders for the Xbox GPU which have improved performance to an exceptional level. The standard seven passes required to render a single frame in Doom III were reduced to four passes;

So it's not an openGL specific thing then?
 
Alstrong said:
The most expedient sounding option was to just use the Nvidia
extensions that they implement, NV_vertex_program and NV_register_combiners,
with seven texture units instead of the four available on GF3/GF4.

How?Wha?
He was talking about how he would write support for the 3DLabs P10 part. Since he finally settled on using ARB_fragment_program, there was no reason to bother with specific support for that hardware.

The dev team did some research and found back doors and even a few undocumented instructions for the NV2X, allowing them to write custom shaders for the Xbox GPU which have improved performance to an exceptional level. The standard seven passes required to render a single frame in Doom III were reduced to four passes;
So it's not an openGL specific thing then?
What do you mean by this? When programming for the Xbox, developers have very low-level access to the hardware, and thus can sometimes do quite a bit more than they can on a PC with similar hardware.
 
This may be really old news, But did anyone know Doom 3 engine has beta support for Nvidias implementation of HDR?

Just read this over at nvnews.

http://www.nvnews.net/vbulletin/showthread.php?t=43691


The experimental code used pbuffers, and wasn't all that well integrated with the entire system, so no, it wouldn't be completely trivial for licensees to use it. I was also using the NV40 floating point blends, so supporting ATI cards and NV30 cards would require more code to do extra passes to simulate blending.

John Carmack
 
Back
Top