Doom3 and the 'unified lighting model'.

[Circastes]

I just read through the UE3 radiosity thread, and found it hilarious that only the first page or so dealt with UE3. The rest was a debate about where Doom3 uses a unified lighting model or not, with our good friend Scali picking at technicalities in order to play down Doom3's technical achievement, for whatever reason, and T2k taking the opportunity to once again prove to us that as a Half-Life 2 fan, he feels intimidated by Doom3.

Now, I hope to clear this up with everyone's help.
Scali, the fan and grate lights are light shaders and not lightmaps. I think it's important to demarcate because a light shader is essentially a mapped obstruction of a real-time light, while lightmaps are mapped lights, period. I am also confused as to how a decision on behalf of the artists can possibly qualify as representative of engine features. Light grates, floor grates and fan shadows can easily cast stencil shadows if you give them a little geometry so the engine knows where the object's boundaries are. Instead of doing this, Tim Willits and co. used simple shaders for the fan's (for example) actual entity, threw a projected light in front of it, and applied the appropriate shader to the light. This not only made the Doom3 campaign look better at times, but saved on net stencil calculations in particular scenes (the magnitude being tenfold with respect to light grates, such as the one that covers the entire room after the crane-and-toxic-barrels 'problem'). If I empathise with respect to level designers, I find that's a pretty good move.

It is entirely possible to recreate Doom3 with no lighting optimizations (not hacks) such as this whatsoever.

As for the odd mention of Doom3's engine not being 'anything special', I challenge someone to show me a fully-functional engine that's robust enough to be sold on a commercial market which equals or outdoes Doom3 and at the same frame rate. No one mention FarCry, because the lighting model pales in comparison to Doom3 when you run indoors, and I feel what was seen of Doom3 outdoors was more amazing than what we've seen from FarCry in the way it gave a true 3D representation of scale.

I'm a big Doom3 fan, but I don't aim to put Doom3 above the rest simply because it was that way for me, but rather aim to give credit where it's due.

 

[Scali]

Scali, the fan and grate lights are light shaders and not lightmaps. I think it's important to demarcate because a light shader is essentially a mapped obstruction of a real-time light, while lightmaps are mapped lights, period.

Excuse me, but to me a lightmap is exactly that, a map (aka texture) with light. In Doom3 these maps are projected, rather than statically mapped on the geometry, like in Quake. But they're still pre-generated.
A shader is one of them programmable thingies, I don't think a texture can qualify as a shader in any way.

As for the odd mention of Doom3's engine not being 'anything special', I challenge someone to show me a fully-functional engine that's robust enough to be sold on a commerical market which equals or outdoes Doom3 and at the same frame rate.

The one used in 3DMark03 pretty much adheres to this description, I believe.

For the rest, too much has been said on this topic already, you just proved my point once again by starting yet another thread on the issue.
I suggest this thread to be closed.

 

[T2k]

Scali, the fan and grate lights are light shaders and not lightmaps. I think it's important to demarcate because a light shader is essentially a mapped obstruction of a real-time light, while lightmaps are mapped lights, period.

Excuse me, but to me a lightmap is exactly that, a map (aka texture) with light. In Doom3 these maps are projected, rather than statically mapped on the geometry, like in Quake. But they're still pre-generated.
A shader is one of them programmable thingies, I don't think a texture can qualify as a shader in any way.

 

[Colourless]

Um...the grates are projected textures aren't they... not light maps....

 

[JF_Aidan_Pryde]

It is possible to recreate Doom3 with no lighting optimizations (not hacks) such as this whatsoever.

I think this nails it.

And it's a total slippery slope to say: "Well then you can recreate any engine without hacks." No you can't. It simply will be too slow.

 

[Scali]

And it's a total slippery slope to say: "Well then you can recreate any engine without hacks." No you can't. It simply will be too slow.

What makes Doom3 any different?
The main reason why grates use projected lightmaps is because stencilshadows perform extremely badly on things like prison bars and grates and such.
So basically Doom3 is no different. It uses hacks because you can't get it fast enough without hacks. Which was my point.

 

[Circastes]

Scali, the fan and grate lights are light shaders and not lightmaps. I think it's important to demarcate because a light shader is essentially a mapped obstruction of a real-time light, while lightmaps are mapped lights, period.

Excuse me, but to me a lightmap is exactly that, a map (aka texture) with light. In Doom3 these maps are projected, rather than statically mapped on the geometry, like in Quake. But they're still pre-generated.
A shader is one of them programmable thingies, I don't think a texture can qualify as a shader in any way.

As for the odd mention of Doom3's engine not being 'anything special', I challenge someone to show me a fully-functional engine that's robust enough to be sold on a commerical market which equals or outdoes Doom3 and at the same frame rate.

The one used in 3DMark03 pretty much adheres to this description, I believe.

For the rest, too much has been said on this topic already, you just proved my point once again by starting yet another thread on the issue.
I suggest this thread to be closed.

Surely you see the difference between projecting a light with a shader and concretely editing texture information via a map that increases RGB magnitude within a certain radius? Walking in front of the projected light shader will cast a stencil shadow - in the case of Doom3 - over the light shader's target area, and moving the light shader backwards and forwards will increase or decrease the shader's resulting circumference and definition - that is, it's completely dynamic. Also, the resolution of the shader is determined by the resolution of the image associated with the shader, and not the surface it's projected onto, because the surface is not being manipulated in any way.
Obvious differences, obvious need for demarcation.

With your reference to the Battle of Proxycon in 3DMark03, this demonstration fails to even come close the detail level of Doom3, thanks in most part to it's average lighting algorithm, while running at ridiculously low frame rates:
http://www.ixbt.com/video2/images/gffx/gffx-3dm03-g2-2.jpg

We all know we can run far more complicated scenes than that in Doom, with at least twice the frames.

EDIT: Sorry, card used was a 5800U.

 

[vrecan]

is anyone other then me sick of hearing the exact same retarded debate in like 15 threads? In the past few weeks this seems to be all thats comming up... GET OVER IT!

 

[Scali]

Surely you see the difference between projecting a light with a shader and concretely editing texture information via a map that increases RGB magnitude within a certain radius? Walking in front of the projected light shader will cast a stencil shadow - in the case of Doom3 - over the light shader's target area, and moving the light shader backwards and forwards will increase or decrease the shader's resulting circumference and definition - that is, it's completely dynamic.

You are fully aware of the fact that stencilshadows do not depend on a shader (at least not in Doom3, they are done on the CPU), and that they can be generated from any point (only point, no other shapes)? In short, they have nothing to do with any lighting calculations. Just feed the routine that generates shadowvolumes a mesh and the position of a lightsource (the aforementioned point), and it works.

Also, you are fully aware of the fact that the map is completely static, and therefore the relative position of light and geometry that is precalced in the map have to remain static, or else it will not work?
In fact, I believe I have seen one point in Doom3 (I believe in the CPU labs) where a fan with light is pointing up and the fan is rotating the other way than the projected shadow.

With your reference to the Battle of Proxycon in 3DMark03, this demonstration fails to even come close the detail level of Doom3, thanks in most part to it's average lighting algorithm, while running at ridiculously low frame rates:
http://www.ixbt.com/video2/images/gffx/gffx-3dm03-g2-2.jpg

We all know we can run far more complicated scenes than that in Doom, with at least twice the frames.

EDIT: Sorry, card used was a 5800U.

I have seen quite other figures. First of all, the 5800U is crap in 3DMark03, and Doom3 is probably the only game where it performs well, so it is not a good average case.
Secondly, 3DMark03 uses quite a few skinned characters there (I already see 4 in the screenshot you posted, there is only a maximum of two in view at the same time in the Doom3 timedemo), and they have selfshadows enabled, unlike Doom3, and the average polycount in the characters is higher.
Thirdly, if you look at Anandtech's CPU article on Doom3 (http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2149), you will see that timedemo1 will get about 103 fps in 800x600 high quality with a 6800U, but only on the fastest of systems. It is almost completely CPU-limited.
That same 6800U will get an average of 107 fps in Battle of Proxycon, even though it has more animated characters on screen at the same time, more dynamic shadows (like selfshadows on the characters), and generally more polygons on screen, and no fillrate optimizations (scissor).
And the difference is this: it will get that speed on pretty much ANY CPU. If you search the ORB, you will find a 2000+ or so as the slowest CPU with a 6800U, and it still gets those 107 fps. And this is still in 1024x768, not 800x600.

So it's nice that you can take an extreme case on an extremely bad GPU and make a screenshot, but that's not the entire story, is it?

Another story is this: I have an 1800+ with Radeon 9600Pro. If I run the timedemo in Doom3 at 640x480 with low detail, I get 24 fps average.
If I run Battle of Proxycon in 640x480, I get 37.5 fps average.

And FYI the lighting system in Battle of Proxycon is equivalent to the one used in Doom3: per-pixel Blinn-Phong shading with diffuse and specular RGB channels, with use of normalmaps for everything.
Whether you think Doom3 looks better or not, is subjective. Fact is ofcourse that the artists have had years to tweak the artwork in Doom3, while the 3DMark03 artists probably had months. Mathematically they are pretty much equivalent anyway, so that shouldn't matter.

So basically, I don't agree with anything you say, and these are the facts to back that up.
Anyway, it's all been said before on this board in other threads, so I suppose you go and read those, and leave this one.
You are not going to convince me otherwise, and it seems that you need to research some more facts, and re-evaluate your opinion. Either way, your opinion is your opinion, and I don't care if you think Doom3 is far better than anything else, and whatever else. I don't agree, and I have explained in great detail why.
If you don't agree with that, that's your problem, stop bothering the forum with it. Just close this thread.

 

[Luminescent]

Ohhh the agony!

 

[Cat]

Once again, directional lights are also supported.

 

[Reverend]

OMG.

As Dave said once, "Doom3 is done and dusted". We have more-or-less known what its engine consisted of years ago. All other information (like some of our Q&As with JC) regarding the Doom3 engine, since John announced its basics, have been about tunings, cutbacks and really the need to have an app qualify as a game that many, many folks can play without too much complaints. Which is to say the first commercial visual representation of the Doom3-engine at work (=Doom3, the game) is nothing more than the result of requirements and common-sense approach required to create, plan, conceptualize, implement and market it by a development house. That involves a number of bullet-point items, such as "multiplayer-ability" in addition to texture artists suggestions.

We may -- most likely -- see better looking (than "Doom3", the id game) Doom3-engine-based games using modified-and-unrecognizable-from-its-original-form two years down the road from today.

Instead of focussing on "The Doom3 Engine" per se, perhaps this forum would be a better place to visit if we focus on "post Doom3-engine and the way it has affected 3D hardware designs for the future.".

I am extremely tempted to lock this thread because I know it really will not provide any interesting 3DT&HW discussions beyond the usual "what's good, what's bad, what's better" with no real knowledge about the business of coming out with a game that everybody can buy. That is the purpose of a game engine.

Do not provide me additional incentive to lock this thread.

Move on to better discussions in this particular forum.

 

[Circastes]

Surely you see the difference between projecting a light with a shader and concretely editing texture information via a map that increases RGB magnitude within a certain radius? Walking in front of the projected light shader will cast a stencil shadow - in the case of Doom3 - over the light shader's target area, and moving the light shader backwards and forwards will increase or decrease the shader's resulting circumference and definition - that is, it's completely dynamic.

You are fully aware of the fact that stencilshadows do not depend on a shader (at least not in Doom3, they are done on the CPU), and that they can be generated from any point (only point, no other shapes)? In short, they have nothing to do with any lighting calculations. Just feed the routine that generates shadowvolumes a mesh and the position of a lightsource (the aforementioned point), and it works.

Sorry, but I can't see how that could be considered a logical reply to my statement. I was pointing out the obvious differences between the conventional lightmap and the light shaders in use in Doom3. I think you've gone and pointed out the difference between stencil volumes and projected light shaders in creating shadows, which I guess is nice.

Also, you are fully aware of the fact that the map is completely static, and therefore the relative position of light and geometry that is precalced in the map have to remain static, or else it will not work?
In fact, I believe I have seen one point in Doom3 (I believe in the CPU labs) where a fan with light is pointing up and the fan is rotating the other way than the projected shadow.

You're saying the object shadow being simulated by the light shader cannot have the object move? Sure it can have the object move, but it just won't make sense. For this reason this kind of lighting was used for fans and lighting grates because they won't be translating anywhere any time soon.

With your reference to the Battle of Proxycon in 3DMark03, this demonstration fails to even come close the detail level of Doom3, thanks in most part to it's average lighting algorithm, while running at ridiculously low frame rates:
http://www.ixbt.com/video2/images/gffx/gffx-3dm03-g2-2.jpg

We all know we can run far more complicated scenes than that in Doom, with at least twice the frames.

EDIT: Sorry, card used was a 5800U.

I have seen quite other figures. First of all, the 5800U is crap in 3DMark03, and Doom3 is probably the only game where it performs well, so it is not a good average case.
Secondly, 3DMark03 uses quite a few skinned characters there (I already see 4 in the screenshot you posted, there is only a maximum of two in view at the same time in the Doom3 timedemo), and they have selfshadows enabled, unlike Doom3, and the average polycount in the characters is higher.
Thirdly, if you look at Anandtech's CPU article on Doom3 (http://www.anandtech.com/cpuchipsets/showdoc.aspx?i=2149), you will see that timedemo1 will get about 103 fps in 800x600 high quality with a 6800U, but only on the fastest of systems. It is almost completely CPU-limited.
That same 6800U will get an average of 107 fps in Battle of Proxycon, even though it has more animated characters on screen at the same time, more dynamic shadows (like selfshadows on the characters), and generally more polygons on screen, and no fillrate optimizations (scissor).
And the difference is this: it will get that speed on pretty much ANY CPU. If you search the ORB, you will find a 2000+ or so as the slowest CPU with a 6800U, and it still gets those 107 fps. And this is still in 1024x768, not 800x600.

So it's nice that you can take an extreme case on an extremely bad GPU and make a screenshot, but that's not the entire story, is it?

Another story is this: I have an 1800+ with Radeon 9600Pro. If I run the timedemo in Doom3 at 640x480 with low detail, I get 24 fps average.
If I run Battle of Proxycon in 640x480, I get 37.5 fps average.

And FYI the lighting system in Battle of Proxycon is equivalent to the one used in Doom3: per-pixel Blinn-Phong shading with diffuse and specular RGB channels, with use of normalmaps for everything.
Whether you think Doom3 looks better or not, is subjective. Fact is ofcourse that the artists have had years to tweak the artwork in Doom3, while the 3DMark03 artists probably had months. Mathematically they are pretty much equivalent anyway, so that shouldn't matter.

So basically, I don't agree with anything you say, and these are the facts to back that up.
Anyway, it's all been said before on this board in other threads, so I suppose you go and read those, and leave this one.
You are not going to convince me otherwise, and it seems that you need to research some more facts, and re-evaluate your opinion. Either way, your opinion is your opinion, and I don't care if you think Doom3 is far better than anything else, and whatever else. I don't agree, and I have explained in great detail why.
If you don't agree with that, that's your problem, stop bothering the forum with it. Just close this thread.

So how is a video card limited in both situations by CPU a more accurate measure of performance? Oh wait: it's not.
There is self-shadowing in Doom3, just not on the main characters for some reason I have not been allowed privvy to, but I'd assume it'd be because of the hard stencil edges, which would make character faces look rather average in cutscenes.
I think it was a good decision to use the 5800U as representation of engine performance, because you can assume even a 9700 Pro is twice the speed, and even then that scene will only be rendered at approximately 30fps, where as Doom3 would register as 60fps constant on both cards.
Your 24fps result in the timedemo is due to the way the timedemo caches materials. Executing it a second time straight after the first will show maybe double the average framerate, because there won't be any I/O thrashing. I get upwards of 30fps on a GeForce3 at High Quality.
Now while Doom3 might be based on the Blinn-Phong method, there'd be very little resemblance between the Proxycon and Doom3 algorithms, simply because Carmack isn't so highly revered for copy and pasting reference code from an algorithm database (unlike Valve). The scene in Proxycon where the hallway is lit up in a Doom3-esque fashion which creates - not suprisingly - a scene reminiscent of Doom, but unfortunately looks really quite bad, and this is not subjective - take a screenshot of this area, compare it to any similar region in Doom3 and that's all you need to realise there's a discrepancy in favour of Doom3.

 

[Scali]

Once again, directional lights are also supported.

Duh, read the answers to the same remark in the earlier thread.
If you are clueless about how stencilshadows or lighting works, just stay out of it. Get a clue.

 

[Scali]

I am extremely tempted to lock this thread because I know it really will not provide any interesting 3DT&HW discussions beyond the usual "what's good, what's bad, what's better" with no real knowledge about the business of coming out with a game that everybody can buy. That is the purpose of a game engine.

Do not provide me additional incentive to lock this thread.

Just lock it already, and all other threads like it.
Obviously people keep bringing up the same points because they are completely clueless about the technology, so my arguments are lost on them anyway. Why don't these ignorant people just shut up instead of littering the forum like this?

 

[Scali]

So how is a video card limited in both situations by CPU a more accurate measure of performance? Oh wait: it's not.

If you are referring to Battle of Proxycon, it is not CPU limited in any of the cases I mentioned.

There is self-shadowing in Doom3, just not on the main characters for some reason I have not been allowed privvy to, but I'd assume it'd be because of the hard stencil edges, which would make character faces look rather average in cutscenes.

The reason why is not important, the result is less workload than in Battle of Proxycon.

I think it was a good decision to use the 5800U as representation of engine performance, because you can assume even a 9700 Pro is twice the speed, and even then that scene will only be rendered at approximately 30fps, where as Doom3 would register as 60fps constant on both cards.

Nonsense. You know damn well that the 5800U is a weird case, since it runs the ps1.4 shaders in 3DMark03 really slow, while Doom3 is optimized very well, both in the game itself (NVIDIA extensions), and the shader replacements in the driver. It is not representative at all for other cards like the Radeons or the NV4x line.

Your 24fps result in the timedemo is due to the way the timedemo caches materials. Executing it a second time straight after the first will show maybe double the average framerate, because there won't be any I/O thrashing.

You take me for a moron? Ofcourse I ran it multiple times and picked the best time. FYI the first time it gets about 19 fps.

I get upwards of 30fps on a GeForce3 at High Quality.

Obviously the performance depends more on the CPU than on the GPU in Doom3, unlike in 3DMark03. The brand of the CPU also seems to have a large influence, since there are brand-specific optimizations in Doom3, but only for NVIDIA.

Now while Doom3 might be based on the Blinn-Phong method, there'd be very little resemblance between the Proxycon and Doom3 algorithms, simply because Carmack isn't so highly revered for copy and pasting reference code from an algorithm database (unlike Valve).

Right, can you describe how exactly it is different from the one used eg Battle of Proxycon? I looked at the source in Doom3, but I don't see anything different. Looks like standard Blinn-Phong to me, with a LUT for the falloff function, which Carmack explained to be a precalced version of an approximation of a power function as can be implemented on NV1x in a single pass.

 

[Circastes]

I misread what you typed about the 6800U in Proxycon, sorry. Having read it again, I realise now it's advantageous to Doom3 to be CPU-limited, when delivering graphics that are truly far more intensive than Proxycon, as it's a sign of efficient GPU use, as is my ability to run a GeForce3 at High and Ultra Quality with little messing around.

The workload decrease due to no self-shadowing on characters (all other entities such as demons etc. do in fact have self-shadowing) would be completely negligible in anything other than cutscenes in Doom3. Therefore self-shadowing is in both and not a major workload-affecting factor, plus the average frame rate would hardly change in the Proxycon benchmark if self-shadowing was disabled unless there's some freak angles in which the characters shroud half themselves in darkness.

Well if the 5800U isn't a good representation, and neither is the 6800U due to CPU limitation, then perhaps your 9600 Pro is? Being disadvantaged in Doom and all because ATi are still having trouble spelling 'OpenGL' up there in Canada.

Yes, I take you for a moron.

nVIDIA-specific optimizations in Doom3 is hogwash. You know nVIDIA have actually worked on their OpenGL ICD while ATi searched for ways to increase their GPU clock speeds further without reaching silicon melting temperature.

With the Blinn-Phong, I'd like to see someone with more insight into the lighting model come on in here and inform us of the differences, because after playing through Doom and looking at Proxycon I know they exist.

 

[Reverend]

Yes, I take you for a moron.

That's it. I have learned nothing from this thread.