Carmack on low polies on models and other things

[Reverend]

Instead of posting a reply to this thread where I said I received an email reply from JC, I'm starting a new one.

I'd asked JC three specific questions. Here are his answers :

Regarding the seemingly low-poly models (from the screenshots), shadow volume lighting and how they relate to his engine. I said that his engine may slow down if higher polies are used and if ATI's TruForm may help out :

The game characters are between 2000 and 6000 polygons. Some of the heads do look a little angular in tight zooms, so we may use some custom models for cinematic scenes.

Curving up the models with more polygons has a basically linear effect on performance, but making very jagged models with lots of little polygonal points would create far more silhouette edges, which could cause a disproportionate slowdown during rendering when they get close.

TruForm is not an option, because the calculated shadow silhouettes would no longer be correct.

Regarding higher precision rendering on a Radeon 8500 vis-a-vis a GF3/GF4Ti. I stated the obvious difference (like JC didn't know it, bleh!) in this aspect between the two and how, during combining, the 8500 allows for better dynamics in lighting. The question was if this would be an influence in how DOOM3 would look depending on the board used :

At the moment, it has no impact. The DOOM engine performs some pre modulation and post scaling to support arbitrarily bright light values without clamping at the expense of dynamically tossing low order precision bits, but so far, the level designers aren't taking much advantage of this. If they do (and it is a good feature!), I can allow the ATI to do this internally without losing the precision bits, as well as saving a tiny bit of speed.

Regarding his publicly-stated (but somewhat veiled) "complaint" (re GF3/GF4Ti vs 8500) about multiple passes based on the number of texture accesses he needs (7, as he stated) and that although the 8500 should, in theory/based-on-specs, be faster but somehow the GF3/GF4Ti is "consistently" faster even with 2 or 3 passes (compared to the single one on a 8500). My question was whether the 8500 may have a problem in terms of latency even if its single shader does all the work (bandwidth savings accepted as well) :

No, latency should not be a problem, unless they (JC's talking about ATI's 8500) have mis-sized some internal buffers. Dividing up a fixed texture cache among six textures might well be an issue, though. It seems like the nvidia cards are significantly faster on very simple rendering, and our stencil shadow volumes take up quite a bit of time.

Several hardware vendors have poorly targeted their control logic and memory interfaces under the assumption that high texture counts will be used on the bulk of the pixels. While stencil shadow volumes with zero textures are an extreme case, almost every game of note does a lot of single texture passes for blended effects.

I have more questions for JC (based on his replies, solely) but I will wait a day before sending them off to him in case some of you also have some questions for him... I will wait a day and include whatever (good and reasonable, as I deem them to be) questions you folks may have... and hope he replies to me again! Questions such as "Do you have a NV30?" (he doesn't, or didn't leading up to E3, btw ) or "If you have a NV30, how does it compare to the R300?" will be skipped.

 

[Doomtrooper]

Very cool...JC's coming around

I have a question for Doom 3 Rev..

Q: Will Doom 3 have specific optimizations for different cards, a 'Nvidia' and 'ATI' preset to take advantage of each cards strengths/weakness.

 

[CHHAS]

Has JC commented on Parhelia yet ? I don't remember seeing it, but I'd like to hear his thoughts.

 

[Althornin]

Q: Will Doom 3 have specific optimizations for different cards, a 'Nvidia' and 'ATI' preset to take advantage of each cards strengths/weakness.

Considering this quote from Rev's interview, i'd say yes

If they do (and it is a good feature!), I can allow the ATI to do this internally without losing the precision bits, as well as saving a tiny bit of speed.

 

[demalion]

Perhaps some of you can answer these, but pass them on to JC if no one does and you think they are applicable.

1) I don't understand why Truform is a concern...what does it matter if the model is a bit better looking and less "jaggy" looking than the shadow? Won't this already be the case with bump mapping?

2) How simple will using Displacement mapping instead of Bump mapping be? From my position of ignorance, it seems it should be fairly "drop in" replaceable (with perhaps some sort of "amplitude" adjustment) since the Bump maps would already be designed to give detail from any angle...

3) Can we expect support for 2) to ship in the Game? My question here is that the big mention seems to be Dot 3 Bump mapping, while a part has already been announced with Displacement mapping...and I'm wondering why no comments have come forth indicating a link between Doom III and this feature that would appear to be directly applicable?

4) Was that wall and pipe break through truly dynamic, or purely pre-calculated scripted? I.e., is such deformation dynamic in the game? If it is, I'm just curious if a vertex program was used for that?

5) Could we get a spew of some technical jargon for some of the lighting and shading effects we can expect to be used fairly commonly throughout the game? I'm just wondering if we'll see some of the things we've been seeing in demos finally put to extensive use, i.e., Gloss maps, or even Fresnel maps?

 

[Kristof]

Several hardware vendors have poorly targeted their control logic and memory interfaces under the assumption that high texture counts will be used on the bulk of the pixels. While stencil shadow volumes with zero textures are an extreme case, almost every game of note does a lot of single texture passes for blended effects.

Interesting... keep an eye on the PowerVR download pages we should be able to illustrate the impact of increased stencil usage soon

 

[Colourless]

Just one question from me:

Are lighting falloff calculations done per pixel? If not how do you get around problems with lights being over large triangles?

To demalion:

John Carmack has said in the past the he doesn't do things so new cards look better. He only does things so new cards will run faster. Therefore, the chances of displacement mapping being used is unlikely.

Regardless, I'd still want to hear from him about it.

-Colourless

 

[nggalai]

1) I don't understand why Truform is a concern...what does it matter if the model is a bit better looking and less "jaggy" looking than the shadow? Won't this already be the case with bump mapping?

Three words:

shadow volumes overhead?

ta,
.rb

P.S. I am not too sure, about it, though. Using a shadow buffer rather than stencil shadowing, fillrate shouldn't be an issue any longer (unless you use point sources, probably). Hmm.rb

 

[Geeforcer]

Yeah, since P10 and Parhelia are the only next-generation accelerators announced so far, it would be nice to get his take on them. Something along the lines of his NV20/R200 .plan write-ups.

 

[MfA]

Self shadowing would get fucked up.

 

[Dave Baumann]

Yes, ask him his thought on the P10 architecture - I would assume this is the closest thing to the type of 3D chip he's been calling for for a long time; lets find out if he's interested by it. Some comments on what he thinks about the development of OpenGL2.0 might be good as well.

 

[Reverend]

Some good questions... oh, and see my edited original post btw.

Here's another "eek"

 

[demalion]

1) I don't understand why Truform is a concern...what does it matter if the model is a bit better looking and less "jaggy" looking than the shadow? Won't this already be the case with bump mapping?

Three words:

shadow volumes overhead?

ta,
.rb

P.S. I am not too sure, about it, though. Using a shadow buffer rather than stencil shadowing, fillrate shouldn't be an issue any longer (unless you use point sources, probably). Hmm.rb

Well, he said:

The game characters are between 2000 and 6000 polygons. Some of the heads do look a little angular in tight zooms, so we may use some custom models for cinematic scenes.

Curving up the models with more polygons has a basically linear effect on performance, but making very jagged models with lots of little polygonal points would create far more silhouette edges, which could cause a disproportionate slowdown during rendering when they get close.

TruForm is not an option, because the calculated shadow silhouettes would no longer be correct.

It is my understanding of the bold text that is the root of my question.

 

[LeStoffer]

Basic question: Carmack said that ATI next gen chip (R300) have the ideal features for Doom III.

Please ask him whether he would sum up the ideal features for this awesome engine. (but don't ask him in a way where he would have to sum up R300 featues and break a NDA!)

 

[demalion]

Just one question from me:

Are lighting falloff calculations done per pixel? If not how do you get around problems with lights being over large triangles?

To demalion:

John Carmack has said in the past the he doesn't do things so new cards look better. He only does things so new cards will run faster. Therefore, the chances of displacement mapping being used is unlikely.

Regardless, I'd still want to hear from him about it.

-Colourless

I understand you are only trying to provide clarification to me personally, but it seems to me that quote is completely non-applicable to Doom III. If it WAS indeed a comment about Doom III, could you give me a link so I can see the context? As it stands, that seems directly the opposite of what the focus of Doom III is.

 

[pcchen]

Regarding to use Truform with volumetric shadow, since the CPU does not have access to the generated vertices, it can not compute the shadow volume. If you want use vertex shader to generate shadow volume, Truform will still have problem with it.

Use the original model for shadow volume with a Truform model is not an option. Although in many situation it will look good, but in some cases it can be very wrong.

Another method is to use CPU to generate Truform models. IMHO it is still too costly on current generation CPUs.

 

[ram]

1) I don't understand why TruForm is not an option, because the calculated shadow silhouettes would no longer be correct.

It is my understanding of the bold text that is the root of my question.

Yea, and MfA gave the answer. Their self-shadowing does not work any more with truform, as the self-shadows are calculated based on the low poly data.

 

[cybamerc]

Dunno if these are too specific:

1. What was the average and minimum framerate of the E3 demo running on the R300?

2. He mentioned that the R300 beat a "very high speed GF4" in every test but was it vastly superior or just slighty. How fast was this GF4 (assuming it isn't Nvidia's next refresh)?

3. How much of an impact has the early nature of the R300 hardware and drivers had on performance (roughly speaking, not asking for details)? What about the engine itself - any major performance issues left that need to be fixed?

4. He once mentioned that the GF3 would run Doom 3 at 30 fps. At what settings and are the 30 fps average or minimum? What about CPU performance?

5. What is more important to run Doom 3? Strong CPU and vertex processing performance or a fast and flexible renderer?

And finally, just out of general interest.

6. Has he had a chance to look at the GameCube hardware (as a follow-up to his comments on consoles at last QuakeCon)? If so what does he think of it (thinking about framebuffer performance and number of TEV stages vs. CPU performance and lack of programmable T&L)?

 

[Reverend]

2. He mentioned that the R300 beat a "very high speed GF4" in every test but was it vastly superior or just slighty. How fast was this GF4 (assuming it isn't Nvidia's next refresh)?

I can answer that here and now - it is a currently available GF4Ti, the R300 is not significantly faster than a GF4Ti at default settings but takes a larger lead when "anisotropic filtering" (as the term applies to the R300 and the GF4Ti's individual, and therefore different, implementations) is used.

Carmack isn't too concerned about "relatively unimportant extras" like a hardware's anisotropic filtering and/or FSAA, as expected of most any developer.

 

[nggalai]

MfA, pcchen,

thanks for your answers. MUCH clearer, now.

ta,
.rb

P.S. Rev: good work.rb