[Richard]

DOOM 3 has a type of light called "ambient light". Because D3 was supposed to be dark and stuff it was never used extensively in the game and perhaps the reason why this might have not been noticed. I first heard about this from id a while ago:

On ATI and geforce 5xxx (and below) cards, ambient lights will light a surface evenly (because we use a solid blue normalization cube map), but on 6xxx cards, the ambient keyword is ignored (because nvidia replaces our cube map lookup with normalization through math).

and

The 6800 has a zero cost normalize function which they are probably substituting for our normalize-with-a-cube-map method. That works on all surfaces except ambient ones where our cubemap isn't a normal cube map.

I also believe this was only introduced in the 61.32 drivers. I don't have a NV4x to test myself but recently I released a custom D3 map set outdoors which makes heavy use of this feature and I got feedback from a few people saying the level looked too dark. I was then reminded about this nVidia optimisation. The purpose of this thread is two-fold: primarily raise awareness for an issue of a specific optimisation worsening image quality and secondly a call to anyone willing to test this further. Thank you.

[wireframe]

Any chance of some screenshots that demonstrate the difference? Also, didn't Humus' tweak(s) substitute lookups with computation and could this be one area affected so that ATI products also suffer from this problem with AI on (or off as well, depending on how that is implemented)?

[Demigod]

Hmm I thought Id posted this here ages ago. I tried quite a bit to get nvidia to fix it. I have emails from ID saying they reported it.

Here is what should be shown


Here is what the 6 and 7 series show.


The 77.77 drivers fixed this for my 6600 (all I can test them on at the time). but I am using the 78.03 on my 7800gtx as it works wonders for shimmering but the ambients are broken again.

this has been a pain as Im working as a beta mapper for the darkmod (http://www.thedarkmod.com/) and without ambiants lighting evenly wont work.

As for ati. I aren't sure, Ive only tested on an x800 and 9800pro and they work fine (normal settings 5.5 5.6 drivers)

[Richard]

Originally Posted by wireframe

Also, didn't Humus' tweak(s) substitute lookups with computation and could this be one area affected so that ATI products also suffer from this problem with AI on (or off as well, depending on how that is implemented)?

Not really, this nVidia optimisation uses a FP16 normalisation unit (which no ATi card has, yet) and the visual artefact is quite noticeable, unlike Humus' tweak which at most, made specular highlights narrower because of the math.

Demigod: thanks for the comparison pics. This is worse than I was led to believe. That surface isn't just dark but completely black. No wonder nV4x users would complain my outdoors map looked dark.

[Demigod]

From playing with ambients I've found only one surface is partially lit the others receive some lighting on the bump maps but only enough to show their is a wall. I cant post Brians email here as I don't have permission but roughly he said nvidia may be substituting their normalize-with-a-cube-map method with their zero cost normalize function, as you suggested.

That email is from April; 26th

As I said they fixed the issue for the 6600 at least with 77.77 so it may be worth suggesting people try that driver or wait for nvidia to cut to op out again.

[wireframe]

I snooped around and found these cvars:

r_skipAmbient
r_skipNewAmbient

Are they related to this particular ambient lighting? Should be easy to test if you have hardware/drivers known not to have the problem and a location that would show the difference.

Is there some known location early on in the game (or on some definite part of a map) where this can be observed? I have ForceWare 77.77 and a 6800. I tried flipping the aforementioned cvars in some locations but it didn't amount to anything.

If those cvars are related to this function, what would the theories be about the "new" one?

[Demigod]

There are 2 ambient light textures you can use in the game. I think that may jusT switch them. I dont know

There is a small test level you can try here

http://demigod.starforge.co.uk/test.rar

Extract them all to your base directory, they dont interfear with any game files.

start doom open the console and type map testmap

this room should be full bright (the walls floor and roof al light evenly ) as the ambient used has no fall off. It it only lights the floors and highlights the wall then the 77.77 dont fix the problem with the 6800's just the 6600.

[wireframe]

Originally Posted by Demigod

There is a small test level you can try here

http://demigod.starforge.co.uk/test.rar

Great. That makes it easier.

this room should be full bright (the walls floor and roof al light evenly ) as the ambient used has no fall off. It it only lights the floors and highlights the wall then the 77.77 dont fix the problem with the 6800's just the 6600.

This is not happening with Forceware 77.77 and 6800 Ultra (AGP) as can be seen in this screenshot I took. Doom 3 1.3 was used.

[Richard]

Originally Posted by wireframe

I snooped around and found these cvars:

r_skipAmbient
r_skipNewAmbient

Are they related to this particular ambient lighting? <snip>

If those cvars are related to this function, what would the theories be about the "new" one?

The first disables lighting on decals, particles, etc; the second disables lighting surfaces that use fragment programs (aside from the default interaction.vfp). Thanks for the testmap Demigod, and thanks wireframe for the screenshot that makes the artefact abundantly clear.

[wireframe]

How did this issue "suddenly" come to the surface now, so long after the release of Doom 3 (and Geforce 6800)? I haven't heard of this before. It's obviously a gross rendering error.

[Gabrobot]

As far as I know Doom 3 doesn't use any ambient lighting in the game, or if it does it's not much. (I think non-directional bumpmapping requires a DX9 level video card, in which case they wouldn't have used it in Doom 3) However, as people make levels it has come to peoples attention as a very big problem. I just upgraded from a Radeon 9800 to a Geforce 6800 about a month or so ago, and a week ago found the problem when I tried lighting a test level I was doing. The main thing with ambient lights is the non-directional bump mapping which lightens all surfaces regardless of whether they're facing the light...without it, lighting well lit areas (like outdoor areas) becomes very difficult to say the least.

[Demigod]

The screen shots I posted above is from alpha labs 2. There are quite a few ambients in the game. People probably didn't notice as it is a dark game and the ambients are normally used to brighten other lit areas.

Oh and for an ambient to work properly, you turn cast shadow and bump etc off. or you get highlights where there should be none i.e. it acts like a normal light for bump etc.

As for how long it took. I posted on doom3world about this back in March, I posted it on futurmark, guru3d, nvnews and a bunch of others, I thought I had here but obviously not.

[Jawed]

Surely it's about time someone, somewhere, started ripping drivers apart to find the actual code being "injected" when shader replacements are being done.

Does this also put the lie to the idea that the 7800 series doesn't need shader replacements because it's so fast? Is this problem seen with 7800 series?

Jawed

[Demigod]

Yeah I get it on my 7800, it may just be using the 6800 opts/path here though? when I tested this on my 6600 I lose 1-2 fps at most well within driver change error margin

[Tim]

Originally Posted by Jawed

Does this also put the lie to the idea that the 7800 series doesn't need shader replacements because it's so fast? Is this problem seen with 7800 series?

Originally Posted by Demigod

The 77.77 drivers fixed this for my 6600 (all I can test them on at the time). but I am using the 78.03 on my 7800gtx as it works wonders for shimmering but the ambients are broken again.

(Bold part by me)

[Arun]

Well, the compiler automatically trying to detect where it can replace stuff by _nrm16 might be another explanation, but that seems a little bit far-fetched. I guess if they were really aggressive they could try to detect lighting vectors and then see whether they "come from a cubemap". If so, they'd replace that with _nrm16.
Still, I doubt it, no sane compiler would take that kind of risk.

Uttar

[Richard]

Btw, apparently nVidia will be fixing this in the next driver release.

[Jawed]

Will it be a global D3 engine fix or will it still "detect D3" and optimise with the NRM?

Is there a performance implication here, or is it just a case of over-enthusiastic optimisation on the part of NVidia's driver team?

Jawed

[Demigod]

Originally Posted by Mordenkainen

Btw, apparently nVidia will be fixing this in the next driver release.

Why didnt I post this here back in april.

Thanks for the info

I realy hope they do it would be so nice to have my darkmod maps light properly.

[Richard]

Originally Posted by Jawed

Will it be a global D3 engine fix or will it still "detect D3" and optimise with the NRM?

Sadly, I didn't get any specifics.

Is there a performance implication here, or is it just a case of over-enthusiastic optimisation on the part of NVidia's driver team?

I'm pretty sure there is a performance hit because their fp normalise unit is described as being "zero cost" but I don't think the hit will be noticeable since D3 doesn't make much use of ambient lights. In my custom level, where every single surface has an ambient light contribution, it might. Quake 4 is also much brighter than D3 and with outdoor areas so I'm thinking ambient lights are used much more frequently there.

I'm glad to see nVidia wants to fix this but I hope their next driver version doesn't take too long to arrive.

[Demigod]

Just though people would like to note this is fixed in the 78.05 drivers available on nvzone, they actually mention it in the release notes as a normalisation cubemap bug.

Doom3 isnt pitch black anymore

(tried this on a 6800gt and 7800gtx)

[wireframe]

Originally Posted by Demigod

Just though people would like to note this is fixed in the 78.05 drivers available on nvzone, they actually mention it in the release notes as a normalisation cubemap bug.

Doom3 isnt pitch black anymore

(tried this on a 6800gt and 7800gtx)

Cool. Tried it with same setup as used before to take the faulty screen capture in this thread with the new ForceWare 78.05 betas and it's looking fine (I think). Yay!



PS. Others reading this may want to get this new driver release as it addresses issues with Source HDR (Day of Defeat and Lost Coast).